Both of these things made me pondering about the future of StarFire (which is at the moment a floating point of uncertainty for multiple reasons that I will not tell in all detail now). I am considering completely recoding it and make it a shining star in the indie game scene as it was supposed to be from the start.
The aspects I reflected upon are as follows:
- Game architecture. StarFire was created to be modular. The development of it was slowed down a lot because of this additional focus on modularity. Another reason was the fact I wasn't very experienced with some parts of coding. A stark contrast to CamoTanks/CamoTactics, which is a game built on the fly (using extracted/abstracted code from the StarFire libs) and thus made huge progress in just a little less than a month.
Besides this, the game completely lacked a decent specification. This is part of the reason why I still am not entirely sure what to do with it. I roughly know what the player should be able to do in StarFire, but am not entirely sure how it can be implemented or whether it can be implemented at all. In some aspects, SpaceEngineers is very close to what StarFire is going to be. Due to this fact it's a perfect playground figuring out what game mechanics are fun (or how they need to be in order to be fun), before even prototyping them. (I should add that the idea for StarFire was born before I even knew about SpaceEngineers). Like this I think I'm slowly getting a feeling what's best for StarFire and the content I want to display with it. And this is a good thing.
- Game design. After playing Space Engineers some game mechanic parts I first wanted to add to StarFire now seem a bit unhandy/not fun enough in practice. This especially applies to gathering resources and crafting/production. On the other hand, some other game mechanics such as voxels I first didn't want to implement now seem more interesting and feasible.
I have played other voxel based games, such as 7 Days To Die or Minecraft, and despite them using voxel engines they are completely different. First off, Space Engineers, 7 Days To Die and Minecraft differ greatly in the atmosphere and experiences they produce. You will find yourself sneaking around and avoid zombies in 7DTD and run like a pansy once they spotted you; in Minecraft, you'll explore caves, enjoy farming, animal slaughtering and breeding (...this sort of sounds weird but let's just leave it at that). In SpaceEngineers, you will spend hours mining asteroids and creating spacecraft accompanied with epic orchestral music.
There are no Zombies going to tear down your house in Minecraft, there is not a chance you could tame a dog, farm, or get your house blown up in SpaceEngineers, there's no way you could build a functioning spacecraft in Minecraft with all the fancy space stuff around it.
Long story short: even using the same technology, the results can be astoundingly different.
- Workflow management. Dealing with Enterprise Architect made me realize that StarFire still had multiple architecture flaws that existed from the start. The code itself wasn't a downright mess, it was actually pretty clean and well-documented (considering I'm a bit chaotic), however, in some cases it was very inefficient. This was due to the fact I coded very "light-hearted" without any workflow tools such as an class/workflow diagram, except a TODO list and the occasional but lax diagram/sketch to depict more complex mechanisms. I made these sketches on paper, but I usually never looked at them ever again.
Sometimes I missed out a flawful architecture in one subsystem because it wasn't depicted with the entire system and all other subsystems (just a small parts of it); as a consequence, I had to invest time coding on both systems adapting them to each other in order to work. That partially also involved recoding large parts of the system. Very ineffective!
I will continue my research, keep on coding smaller games; and when I feel it's time, recode StarFire to bring it to its fullest glory!
Keine Kommentare:
Kommentar veröffentlichen