Movement

Today we're going to talk about movement. Project Spaceboat began life as a game about a viking boat flying through space and dodging UFO's. The controls were stiff, with a setup that had four lanes that the player could move to. The lane change wasn't instant and so the boat became unresponsive and unresponsive controls are one of the most heinous things I, as the designer, could have done. Luckily not a ton of development time was spent on this. I abandoned it early and quickly in favor of a more fluid control scheme. The lanes still exist, sure, because that's an easy way to spawn enemies and know precisely where they'll end up. The important thing ended up being that control would not be tied to them. Player control has improved dramatically due to this change.

Here's the original layout:

The circles on the left are terminators, objects I use to destroy spawned objects that go off of the screen. The circles on the right are spawners. The character would move on the lines created between them when the user pressed 'w' or 's' (and later touched above or below).

Really basic and simple, my thinking was that it would be better for touch devices to have as simple a control scheme as possible. But even with the keyboard's precise controls it proved frustrating. Since I was still early in development I decided on a rework of the control scheme. I kept the terminators and spawners in the lane format I had going but decided to allow the player to move anywhere they liked. So now you could click anywhere you wanted on the screen and you would have immediate feedback from your character. It felt really good.

This taught me that player control should not be removed for any reason, because if the player isn't controlling the game why are they even playing to begin with? Interactivity is what makes the medium wholly unique to others. This seems so obvious now and to anyone reading this they may be thinking that they would never make such a simple and core mistake like it, but rest assured that thinking about development and design is much easier than actually doing it. Sometimes it takes making the simple mistakes to make sure they do not show up later down the line when your projects get bigger and iteration can't happen as fast as it can with your small projects.

Scope

So, let's talk about scope. Scope in game development (or really any task that can be arbitrarily long based on what you want to put into it) means keeping something within a reasonable schedule and group of tasks that you are able to accomplish with the team you have. This is something someone new to game development might not understand at first because they have been dying to make all of their ideas become a reality and have finally decided to dive head first into the process. But it's important to try to be realistic with the constraints placed upon you. The fact of the matter is if you are just starting to develop games there is so much you will learn during the creation of your first piece that halfway through you are going to start using almost all of your time trying to saddle new knowledge into old workings. Add on top of that having not scoped out the project or solidified any game concepts beyond the 'wouldn't it be cool if' and you have a recipe for a game that is essentially incapable of getting finished.

Okay, so, now let's talk about my game. My project name was 'Loot & Shoot'. My design document was all in my head. Scope was something I want to think I at least understood but did not apply in any way. This kept me doing large amounts of work that could not be used and as a one man team doing large amounts of work that you can't use not only makes development slow down to a crawl but destroys any motivation you may have had. But, I pressed on, because I really wanted to play the game I was making. There are other FPS roguelikes out, sure, but so far not a single one has been what I'm looking for and I think that's because the scope of the project I'm looking for is far larger than what a one or two man team would be able to put out in a year or so. I'm gonna say that I think I had a lot of cool and interesting ideas for L&S, and it will be revisited, but for now I've decided to let it simmer while I learn more about and get more experience with the many required skills and tools of someone that wants to develop games.

So, what does that mean going forward? I've been working on a new project, a small iOS and Android game. Originally conceived as a game about a viking boat in space, the boat was soon back on earth and dodging whales on the ocean. This game is smaller, much smaller. There's a main menu, the main gameplay screen, a screen to buy items and a screen to unlock treasure chests (more on all of these in another post). The gameplay involves using taps anywhere on the screen to move the character around and dodge the obstacles that get in his way, or grabbing the coins to buy items from the shop. Simple. Scoping my project has led to my ability to get together an almost fully working game in a matter of a couple of months and that's not only a huge boost to morale but an undeniable proof to myself that I have improved from the development of L&S. Since the game already has a lot of stuff to show I'll be making posts twice a week documenting the progress from start to finish, starting with older assets and ideas that won't be in the final game and eventually moving to the release on iOS and Android systems.