I have been making some pretty good progress since the last time I posted. In my last update, I was promising to talk more about the design of the rest of the game (besides weapons and enemies), and now I have such designs fleshed out, and implemented in the game! The cool thing is that I actually have way more implemented already than I'll be able to talk about in this update. There is quite a bit to cover, so I will split this into several updates.
Level Design
At first, I did not know whether I wanted the level to be hand-made and have a system where players choose their arenas, or players just pick a bunch of parameters and have a level generated for them. Going rogue-like seemed more interesting to me, so as of now, the levels in my game are procedurally generated.
Making that one decision now made my further brainstorming session more focused, as I was trying to come up with interesting ways to both generate the level, and then make the randomly generated pieces relevant to the rest of the game.
The first step to generating a level is figuring out how large the entire play-space is going to be. In the final game, the player will have a few options they can tweak that will determine how the level looks like. Right now all they have to work with is level size, and whether or not it will be narrow. Since I don't have any menus implemented, I have to change this right in the code. Once the general level size is determined, walls are placed at the extreme edges to prevent the player from escaping. This may or may not be final, as I may figure out or think of better ways of keeping the player contained inside the level.
Once the initial play-space has been created, we have our blank canvas for random generation. The play space initially was rather large, even for small maps, so I thought that spawning enemies randomly throughout the level will be kind of clumsy. After all, the player would, more or less, just randomly wander around in a huge space trying to look for something to shoot. I would imagine this to be quite boring. There would be the fact that you don't really know where the enemies would be coming from, which would make it a little tense and exciting, but it also has a potential to be frustrating. This is backed up by my own experiences in Geometry Wars 2, where enemies spawn randomly (and sometimes right on top of you) and is incredibly frustrating, especially if you have lots of points racked up, as it feels like a cheap shot. Geometry Wars could get away with this though, because their arena was rather small, and you always knew what was going on at all times. I cannot say the same for my game.
Since I wanted to slow the pace of the game down, and add in strategic elements, I need to give the player information to process that is rather reliable. This information is what they need in order to make meaningful decisions about what they are going to do, and why it makes sense. So now that I ruled out randomly spawning enemies, the next logical step is to make objects that spawn them. Given the art style of my enemies, Hives came up straight away as ideal objects that could become hubs/centers of enemy activity.
This idea of Hives fulfills many, many purposes in terms of both game design, and level design.
The Hive: Congregation of enemies.
Spawning enemies at Hives gives the overall encounters of player vs enemy more structure and gives the player that reliable information I talked about earlier. When a player sees an enemy, it sets up a certain number of expectations. The player can expect the enemy to lead them toward an enemy base for a more intense encounter. Furthermore, the player can also expect not to have to deal with enemies when they are not prepared. Since most enemies would congregate around their Hive, this gives the player their own domain, and therefore also gives the enemies their own domain as well. The player can then choose to enter a heavy encounter at their own will, rather than at the game's will. This is important, as the player has more agency over the factors that will ultimately end in their success or failure. Specifically, the player has the decision to flee if they feel like the encounter is not going their way. This gives them the opportunity to experiment with different tactics in the same stretch of playing time, rather than having to fail and start again. This makes the entire experience more forgiving in contrast to Geometry Wars, where you are constantly under assault from enemies until you can no longer keep up. The agency created by these decisions will hopefully empower the player, rather than making them feel unskilled.
The Hive: Conduit for Rewards
One question I had a difficult time answering is how do I give the player rewards? I created all of these awesome and cool weapons to use, and modifiers to go with them, but how do I give them to the player in a meaningful way?
I didn't want goodies to drop randomly from enemies, as this kind of randomness is not the good kind, where the game is withholding rewards from the player for arbitrary reasons. While this method works well enough in other shoot-em-ups, I feel like there could be a better answer for my game. Going back to what I said about reliable information, I want this game to be more tactical, and strategic. I want players to actually make logical choices, and in order for players to make meaningful choices, they have to have information. Random drops are not reliable, and therefore do not encourage the player to think beyond the short-term. These random drops would also encourage players to 'farm' enemies that would keep re-spawning to get the reward they want/need, and that is not fun, especially considering that the reward they need may not necessarily be the one that is dropped.
I thought about making enemies drop experience points, or something similar so that the player could unlock more weapons as they become more 'experienced' at destroying their foes, but this inherently has implications that I do not like. Firstly, it implies that each reward is in a linear progression in relation to other rewards. This means that whatever I unlock has to be better or more useful than what I unlocked previously. If this is not true then the progression would feel meaningless, and players would quickly lose interest. The design of the weapons and other rewards are not meant to be juxtaposed linearly. One weapon is not necessarily 'better' than another, it just provides the player with a different way to achieve the same goal. That being said, some weapons excel or fall short depending on the enemy you're fighting. So the difference here is not of scale, it is of kind.
So how do Hives solve this problem? The answer should be fairly obvious by now, as in, tie rewards to the destruction of Hives. Once the player squares off against the defenders and gets a foothold, they would then have a chance at destroying the Hive. If they are successful with the encounter, they get a reward for their troubles. This fulfills my desire to have reliable information to the player. They would know exactly what benefit the Hive offers (it would be some sort of visual display), and know exactly what they need to do to get the reward. The player's journey for the reward also thrusts them into the meat of the gameplay. This will hopefully make the entire experience fun, as reward is also now tied to challenge.
The Hive: Game Progression
Tying rewards to Hives also has a surprising positive side-effect that ties everything together. When rewards are associated with the Hives, it gives the game a more structured end-goal. This goal is conquest. Before, I did not really know or understand what my end game was going to be. Do you just run out of lives? Is there some sort of timer? Is high-score really the only way I would measure success in the game? All these solutions for an end goal did not satisfy me, until I found this one.
Since the Hives offer players rewards, I would expect players to try to gain all of them. I'll have to test this to see if its actually true once the game is playable, but for now I am running with this assumption. This is, I feel, a natural end-goal for the player to strive for. However, I did realize that once the player has gotten accustomed to the process of destroying hives, the gameplay might become more repetitive as the challenge will stagnate.
With this information in mind, I plan to add one 'super enemy' which is essentially a boss for the entire level. It only spawns once a majority of the Hives have been captured, and once it is destroyed, the game is over. This doesn't require players to tediously hunt down every single Hive, as they may have missed a few that had spawned in the corner of the map somewhere. Or the player may have felt that the benefit offered by a particular Hive just wasn't worth the effort This isn't an issue in smaller maps, but would get incredibly frustrating on the larger ones. So this being said, once a majority of the Hives have been destroyed, the player now has a clear end-goal which offers a new challenge, and refreshes the gameplay.
Next Time
In my next post, I'll talk about how the Hives actually work within the game in more detail, and explain the process the player needs to go through in order to destroy and capture Hives. Depending on how long it will take me to explain how the system works, I may also dive a little bit into enemy design. My initial ideas for enemies are no longer applicable because I changed so many things. I now have to re-design my enemies so that they fit with the rest of the game mechanics that I have implemented.
