7DRLC2012 Postmortem
by Kyzrati on 20.3.12 , under
Now that the hectic period of "Oh my god I'm awake, that means I must be working on my 7DRL!" period is behind me, there's more time to reflect on the process and give some insight into what went on behind the scenes.
As I mentioned before, a lot of planning went into the game, but too much planning is a bad thing if it's not focused in the right direction, and the later stages were all about slimming down the game into something doable. I should've thought more about creating a simpler game from the start, then the results might show a bit more polish.
Coding
The coding itself didn't actually take very long, since almost everything except the content and some of the mechanics came straight out of X@COM. The primary modification to the core code was inserting an event manager to handle an energy-based time system, but that turned out to be incredibly simple since all I used it for was entity turns and the game clock. (To prevent a coding and testing nightmare I left out duration effects--all effects are persistent. There's still plenty of fun and strategy with the 40 unique persistent effects available by attaching utility parts.) Beyond that the game only implements a handful actions, get/drop, attach/detach, activate/deactivate, and fire.
The rest of the work was mostly in putting together data objects and data files. All my projects are very data centric, and from the large number of data files the game draws from you can see that Cogmind is no exception. Once the actions were coded and I played around with a few test objects to make sure I had the right set of parameter ranges for the data-to-be, it was just a case of filling in those ranges with entity- and item-specific values followed by some quick spreadsheet data manipulation. Only entities and items were completely redone--the rest of the data files were almost entirely copied from X@COM.
I also quickly recolored some particle effects to add more variety for the wide selection of Cogmind items (way more than X@COM...). Too bad there wasn't more time, because I really wanted to throw in some neat new visual effects. As is, there are no new projectiles/explosions, and the UI is just cookie cutter templates from X@COM. Also too bad there wasn't more time since the X@COM codebase supports so many more features that I didn't get to work on, so I had to cut them. But the "if I only had more time" list is way too long to bother going into...
Design
From the beginning, there was a lot of debate (I brainstormed the game with my brother) over whether to do the typed slot system you see in Cogmind, or an even more open-ended system where you have X number of slots and can attach anything you want. Under that system, some parts would probably have to take up multiple slots to make it work right, but it might have seemed a bit chaotic (could've been a good thing, I guess) and would've been much harder to balance (not a good thing for a short project).
Eventually the typed slots won out, and after several iterations ended up with the names Power, Propulsion, Utilities, and Weapons. Later I realized that from a gameplay standpoint the latter three conveniently correspond to your basic RPG stat triumvirate: DEX, INT, and STR. (Completely unintentional, though perhaps inevitable.) Sure enough, what slots you focus on when evolving your Cogmind design can steer you towards play styles resembling stereotypical RPG characters. With evenly distributed slots you can be a well-rounded jack of all trades, or you can emphasize one of the three main slots and rely on strategies that capitalize on your advantages: you can be a super-fast flying robot dodging bullets and whizzing past everything in your way, you can attach a variety of utilities and have a trick up your sleeve for every occasion like any good mage, or you can deck yourself out with guns, cannons, missiles, and bombs and take on everything you meet. Power is the odd man out, and you generally have as little of that as you need to implement your design.
On top of that mechanic, several other core gameplay ideas were drawn from existing games: weapon heat and an energy/ballistic weapon dichotomy from Battletech, energy/mass as resources from Supreme Commander (mass was renamed to matter), and damage types from EVE online (I started with my own list, but it looked almost identical to EVE, so I went with that one since it was somewhat simpler).
Cogmind doesn't get hungry, but there are some alternate ways to push the player through the game. Core integrity is the obvious hitpoint equivalent, and the fact that it is only replenished (and increased) each evolution means you have a finite amount of time you can spend searching for a way out depending on how well you protect your core and stay out of harm's way. By the mid- to late-game though, you have so many parts that your core rarely takes serious damage (unless you are completely overwhelmed and lose lots of parts, in which case you're probably doomed anyway). At that point system corruption takes over as a source of danger. It completely bypasses armor, and increases the game's difficulty through its negative side-effects; you're also guaranteed to be tracked down by Programmers the longer you stay in an area. There really isn't much of a purpose to stay in a map area anyway, since there is no experience given from fighting (character advancement comes from reaching new areas). The whole point is to escape, after all, though finding an exit becomes harder and harder as you near the surface. Of course you can also become a virtual Programmer yourself by outfitting yourself with their electromagnetic weapons and shocking everything else; most enemy robots are far more susceptible to EM damage than Cogmind.
Limited inventory capacity is another thought-provoking mechanic which forces the player to make difficult choices, especially when leaving an area. Even leaving something on the ground for later may not work, since a Recycler could come by and move it. As with any other mechanic though, inventory space can be manipulated through utilities if you can accept the slot/mass/upkeep costs.
Utilities are one of the game's strong points, as they reach into every part of the gameplay. An entire day was spent coding 40 different effects which, when combined with a single item-specific variable to control the degree of the effect, led to about 170 utility parts. They provide a way to affect almost any aspect of the game you choose, enabling a wide array of unique builds. If you're familiar with all the parts and choose the most effective combinations, it's not impossible to come up with a nigh-invincible build, though it would be really tough to maintain it forever since you're likely to lose an integral part of your design at some point. Such is the life of Cogmind.
Regarding Cogmind's inferior siblings, the Overmind's mindless robotic thralls, I almost went with a strictly alphabetical representation; i.e., robot ASCII are A, B, C, and so on ordered by difficulty, all the way to the fearsome Z robot, and color would differentiate classes (types). This would have worked if not for the fact that there ended up being 11 classes, half of which are harmless, which have to fit into the system, and (more importantly) a robot's letter is definitely more readily identifiable than their color. In the end, I used a single letter for each class (lower/upper case reflects size), and color to instead represent relative threat (within a given class). Name codes also hint at difficulty, allowing some comparison of robots across classes; higher = harder. Let's just say you haven't seen tough until you meet a B-99. Don't forget your Null Cannons or Point Singularity Launcher :)
Part of the brainstorming process also touched on what happens after the game story. Just yesterday the name "Cogmind 2: The Surface" ran through my mind. If you beat the game, the conclusion gives a hint showing part of what to expect should that ever come to pass.
Now I'm going to go play some of the other cool 7DRLC entries out there...
As I mentioned before, a lot of planning went into the game, but too much planning is a bad thing if it's not focused in the right direction, and the later stages were all about slimming down the game into something doable. I should've thought more about creating a simpler game from the start, then the results might show a bit more polish.
Coding
The coding itself didn't actually take very long, since almost everything except the content and some of the mechanics came straight out of X@COM. The primary modification to the core code was inserting an event manager to handle an energy-based time system, but that turned out to be incredibly simple since all I used it for was entity turns and the game clock. (To prevent a coding and testing nightmare I left out duration effects--all effects are persistent. There's still plenty of fun and strategy with the 40 unique persistent effects available by attaching utility parts.) Beyond that the game only implements a handful actions, get/drop, attach/detach, activate/deactivate, and fire.
The rest of the work was mostly in putting together data objects and data files. All my projects are very data centric, and from the large number of data files the game draws from you can see that Cogmind is no exception. Once the actions were coded and I played around with a few test objects to make sure I had the right set of parameter ranges for the data-to-be, it was just a case of filling in those ranges with entity- and item-specific values followed by some quick spreadsheet data manipulation. Only entities and items were completely redone--the rest of the data files were almost entirely copied from X@COM.
I also quickly recolored some particle effects to add more variety for the wide selection of Cogmind items (way more than X@COM...). Too bad there wasn't more time, because I really wanted to throw in some neat new visual effects. As is, there are no new projectiles/explosions, and the UI is just cookie cutter templates from X@COM. Also too bad there wasn't more time since the X@COM codebase supports so many more features that I didn't get to work on, so I had to cut them. But the "if I only had more time" list is way too long to bother going into...
Design
From the beginning, there was a lot of debate (I brainstormed the game with my brother) over whether to do the typed slot system you see in Cogmind, or an even more open-ended system where you have X number of slots and can attach anything you want. Under that system, some parts would probably have to take up multiple slots to make it work right, but it might have seemed a bit chaotic (could've been a good thing, I guess) and would've been much harder to balance (not a good thing for a short project).
Eventually the typed slots won out, and after several iterations ended up with the names Power, Propulsion, Utilities, and Weapons. Later I realized that from a gameplay standpoint the latter three conveniently correspond to your basic RPG stat triumvirate: DEX, INT, and STR. (Completely unintentional, though perhaps inevitable.) Sure enough, what slots you focus on when evolving your Cogmind design can steer you towards play styles resembling stereotypical RPG characters. With evenly distributed slots you can be a well-rounded jack of all trades, or you can emphasize one of the three main slots and rely on strategies that capitalize on your advantages: you can be a super-fast flying robot dodging bullets and whizzing past everything in your way, you can attach a variety of utilities and have a trick up your sleeve for every occasion like any good mage, or you can deck yourself out with guns, cannons, missiles, and bombs and take on everything you meet. Power is the odd man out, and you generally have as little of that as you need to implement your design.
On top of that mechanic, several other core gameplay ideas were drawn from existing games: weapon heat and an energy/ballistic weapon dichotomy from Battletech, energy/mass as resources from Supreme Commander (mass was renamed to matter), and damage types from EVE online (I started with my own list, but it looked almost identical to EVE, so I went with that one since it was somewhat simpler).
Cogmind doesn't get hungry, but there are some alternate ways to push the player through the game. Core integrity is the obvious hitpoint equivalent, and the fact that it is only replenished (and increased) each evolution means you have a finite amount of time you can spend searching for a way out depending on how well you protect your core and stay out of harm's way. By the mid- to late-game though, you have so many parts that your core rarely takes serious damage (unless you are completely overwhelmed and lose lots of parts, in which case you're probably doomed anyway). At that point system corruption takes over as a source of danger. It completely bypasses armor, and increases the game's difficulty through its negative side-effects; you're also guaranteed to be tracked down by Programmers the longer you stay in an area. There really isn't much of a purpose to stay in a map area anyway, since there is no experience given from fighting (character advancement comes from reaching new areas). The whole point is to escape, after all, though finding an exit becomes harder and harder as you near the surface. Of course you can also become a virtual Programmer yourself by outfitting yourself with their electromagnetic weapons and shocking everything else; most enemy robots are far more susceptible to EM damage than Cogmind.
Limited inventory capacity is another thought-provoking mechanic which forces the player to make difficult choices, especially when leaving an area. Even leaving something on the ground for later may not work, since a Recycler could come by and move it. As with any other mechanic though, inventory space can be manipulated through utilities if you can accept the slot/mass/upkeep costs.
Utilities are one of the game's strong points, as they reach into every part of the gameplay. An entire day was spent coding 40 different effects which, when combined with a single item-specific variable to control the degree of the effect, led to about 170 utility parts. They provide a way to affect almost any aspect of the game you choose, enabling a wide array of unique builds. If you're familiar with all the parts and choose the most effective combinations, it's not impossible to come up with a nigh-invincible build, though it would be really tough to maintain it forever since you're likely to lose an integral part of your design at some point. Such is the life of Cogmind.
Regarding Cogmind's inferior siblings, the Overmind's mindless robotic thralls, I almost went with a strictly alphabetical representation; i.e., robot ASCII are A, B, C, and so on ordered by difficulty, all the way to the fearsome Z robot, and color would differentiate classes (types). This would have worked if not for the fact that there ended up being 11 classes, half of which are harmless, which have to fit into the system, and (more importantly) a robot's letter is definitely more readily identifiable than their color. In the end, I used a single letter for each class (lower/upper case reflects size), and color to instead represent relative threat (within a given class). Name codes also hint at difficulty, allowing some comparison of robots across classes; higher = harder. Let's just say you haven't seen tough until you meet a B-99. Don't forget your Null Cannons or Point Singularity Launcher :)
Part of the brainstorming process also touched on what happens after the game story. Just yesterday the name "Cogmind 2: The Surface" ran through my mind. If you beat the game, the conclusion gives a hint showing part of what to expect should that ever come to pass.
Now I'm going to go play some of the other cool 7DRLC entries out there...
Powered by Blogger.
0 comments