Sunday, October 13, 2013
Thursday, October 10, 2013
Wednesday, October 2, 2013
Accessibility
Today I want to talk about the main mechanic that I'm hoping makes the game I'm working on different than a lot of similar titles. While the second to second game play is indeed basically dodging obstacles that come from the right side and roll to the left, I've added a deeper element in the form of shields that the player uses as power ups. When a player is hit he loses one of his shields and gains a permanent or temporary benefit. Things like doubling any coins he collects, giving him a lightning bolt to shoot at enemies or giving him an extra hit. I'm building these power ups with combos in mind. The important thing about these shields though is that they also act as your health and each one destroyed means you can take one less hit. Once they're all gone you can technically be at your strongest but also your most vulnerable. I feel like this adds a good risk/reward element to the game that can separate people that want a casual experience (which the game is friendly towards) from people that might want something just a bit deeper.
So, then I feel like that may be a good segway into a conversation about accessibility in games. Most people think of accessibility as being able to get non-game players to play their game, but that's not where it ends. It's easy to get a non-game player to play your game (make the controls simple and intuitive) and I'd say it's even easy to design around getting a more core audience interested in your game (being that many independent game developers are core players themselves) but accessibility to me means bringing both of these together in a unified design concept. Companies like Activision-Blizzard have this idea down to a science. They create games that new players are able to access regardless of skill or knowledge of standard game concepts but are deep enough that players that want more out of their games are able to dig in for a really long time. It's one of the hardest, but perhaps one of the most profitable (both in capitol and recognition), skills a designer can look to develop if they want a long lasting and worthwhile venture. More important perhaps is that it creates a game that people remember because they decide to spend a lot of time in it. It's the reason we see so many online multiplayer games. When your opponent is another human being if you can match two people of equal skill through some sort of system (Like DOTA 2, Hearthstone and other adversarial multiplayer game's matchmaking systems) you have a sure-fire way to challenge the player without going over their head no matter the central concepts. In a single player game this is something that's harder to get right and balance for. Good examples of this in action would be the Simcity, Civilization and Final Fantasy franchises. All very accessible but very deep if the player wants to take it further. All of these have stood the test of time and for the most part (besides a few oddities in the FF series) their core components have remained very much the same.
This has turned into a sort of rant but it's because the concept is so broad and sweeping it's hard to find a single thing to talk about. The main thing to take away is that inaccessibly deep games (like Dwarf Fortress) and extremely casual game with next to no depth (like Solitaire and Bejeweled) definitely have their place in the gaming world, but like most things I feel the target should be somewhere between those two.
So, then I feel like that may be a good segway into a conversation about accessibility in games. Most people think of accessibility as being able to get non-game players to play their game, but that's not where it ends. It's easy to get a non-game player to play your game (make the controls simple and intuitive) and I'd say it's even easy to design around getting a more core audience interested in your game (being that many independent game developers are core players themselves) but accessibility to me means bringing both of these together in a unified design concept. Companies like Activision-Blizzard have this idea down to a science. They create games that new players are able to access regardless of skill or knowledge of standard game concepts but are deep enough that players that want more out of their games are able to dig in for a really long time. It's one of the hardest, but perhaps one of the most profitable (both in capitol and recognition), skills a designer can look to develop if they want a long lasting and worthwhile venture. More important perhaps is that it creates a game that people remember because they decide to spend a lot of time in it. It's the reason we see so many online multiplayer games. When your opponent is another human being if you can match two people of equal skill through some sort of system (Like DOTA 2, Hearthstone and other adversarial multiplayer game's matchmaking systems) you have a sure-fire way to challenge the player without going over their head no matter the central concepts. In a single player game this is something that's harder to get right and balance for. Good examples of this in action would be the Simcity, Civilization and Final Fantasy franchises. All very accessible but very deep if the player wants to take it further. All of these have stood the test of time and for the most part (besides a few oddities in the FF series) their core components have remained very much the same.
This has turned into a sort of rant but it's because the concept is so broad and sweeping it's hard to find a single thing to talk about. The main thing to take away is that inaccessibly deep games (like Dwarf Fortress) and extremely casual game with next to no depth (like Solitaire and Bejeweled) definitely have their place in the gaming world, but like most things I feel the target should be somewhere between those two.
Wednesday, September 25, 2013
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.
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.
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.
Saturday, May 25, 2013
Game Ideas
This blog is a record of my concepts and work on the game I'm developing. I'm new to programming, 3d art, sound design and every other element of game development save for 2d art, which I've studied personally for many years. The project I have in mind is a bit ambitious but I've been able to prove to myself I can do it by making most of the core elements in Unity in a matter of a few months with almost no programming knowledge. At the moment I am trying to develop my programming skills and I figured that would be a good time to conceptualize some of the major elements of the game as well. The idea I have is a first person shooter with light rogue like elements. To the left are a few concepts for shrines, which are going to be rare structures that may require you to fulfill some type of objective on the floor or ask you for some form of payment. In return they can unlock things like new bosses, items, guns and even new areas. I want to make sure they have strong silhouettes that are wholly unique in the world so that the player becomes curious as to what they are and what they do. I will start filling out more details on how I want the game to work as I post more concepts, but for right now that's all.
Subscribe to:
Posts (Atom)