When games become "saturated"

UPDATE [24.02.2017] As of Minecraft version 1.11.2 much what is described here does not apply anymore. For example, survival and exploration mechanics were balanced and it has become quite enjoyable for me.

---

Recently I stumbled upon an interesting comment on youtube. It was about how adding too many features may spoil a perfectly fine game. Unfortunately I didn't save the link to this comment, as I would have never thought I'd ever pick it up to create an entire post about it. As I started to see the same pattern on other games, it indeed made me think about how some games progress as a product and subject of design.


I will describe in my own words what this comment was about and give examples. Please note this post should not be taken as "you should change this immediately". This is merely an analysis/opinion people may learn from (or not).

During a game's alpha phase, it's fun to see it grow and develop, each update adding more content and creating new experiences for the player. However, after a while some games start growing beyond the point they are supposed to be growing.
This state I'm talking about is reached once the developers begin to add more and more content which "disrupts" the original idea, feeling or atmosphere of the game. To a certain degree, change is necessary and part of the development progress. However, many "disruptive" changes may result in a complete (intended or not) reinvention of existing game design, atmosphere, or experience. This is where you, as a developer, have to ask yourself whether you are still developing the game you wanted, or still making use of the atmosphere and creating experiences the game is supposed to create.

One example that was mentioned in the comment was Minecraft. I absolutely loved playing this game when I bought it in alpha, in fact I still have some ancient maps, including the first world I ever started. I still remember well when cake and sandstone was added to the game, and those little add-ons I perceived as a pleasant addition; same applies for breeding. A lot of features you can keep yourself busy with were added. But sometime during the 1.4 update, I started losing interest in this game. So what made me stop playing?

One main reason was that I simply burned out on it. The other main reason was "flawful" game design thus making me lose interest. The mistake Mojang did was adding plenty of stuff to Minecraft that - in its entirety - was difficult to unify in one game to the extent it can still be called "good design". Minecraft offers mechanics such as survival, building, mining, breeding, logic (redstone & pistons), exploration, boss fights, but it really excels at neither. Survival is easy even on hardest difficulty once you managed to build a nice shelter and get some animals or a farm (at least for "older"/adult players). Building (including redstone) gets boring after a while once you build everything you wanted to build; at least for me adding new materials will not change this on a long term. Exploration tends to be repetitive, possibly due to procedural generation. The boss fights aren't too special compared to boss fights in other games, unless you're playing with friends maybe.
In fact, I find myself lost in the amount of features I could possibly use, and I am not even using half of them, either. I realize people may have different experiences or opinions about this, however one must still question whether this is a sign of "bad" game design or not.

A while ago, with the Adventure Update Mojang added multiple features that still somewhat fit to the game (villagers, temples...). With the most recent update they added realms. While I acknowledge the importance of the former, what is the point of the latter? At least I know I'm not going to use this feature at all. The main reason I bought this game years ago was survival, mining and building. Since survival has become easier and easier with every update (breeding, farming, enchants to obtain even more gems etc.), what is the point of playing this game for someone looking for a challenge? I assume this is the reason why Minecraft mods and alternative minecraft-like voxel games are so popular.

During Minecraft's existance, more and more building blocks have been added, most blocks possessing slightly different appearances, but similar or even the same properties to existing blocks. If one block can easily be substitued with another, diversity is not substantially changed as new ones essentially do not add more functionality; other than looking pretty/different perhaps. Alpha Minecraft had a distinct look, but with all the new block types (that often don't even look good or too different to already implemented ones, i.e. stone brick) I think it kind of lost that charme it once had.
But what about texture packs? To be honest, adding texture packs only allows you to bypass the mistakes the developers are held to be accountable for; it doesn't get rid of the root of the problem, it doesn't make the original game design better (maybe better in the sense you can change the looks of it).

What makes this situation worse is that plenty of Minecraft mods exist for a wide range of purposes. For example, if you want to go crazy with factories and extended materials, you install yourself Feed The Best to enhance your crafting/building experience.
Minecraft does not need to add more features; instead it should improve the game mechanics it already utilizes. One step towards this goal would be to implement effects to food, for example. Or put more detail into the survival aspect by introducing energy, temperature, seasons. Then again, the fact that there's probably a mod for this purpose already leaves the developers in a mess.



So what we have here is a "oversaturation" of game mechanics, a lack of diversity; too many substitutes that serve the same function that - in my opinion - has changed the game's "spririt" to the negative as it matured. For further thought, you may ask yourself when the point is reached to stop adding content to your game, or when a mechanic starts changing your game to the extent it's completely reinventing it.

It seems that similar circumstances apply to the game Don't Starve; since I unfortunately did not play the recent versions I cannot really judge; but just by the looks of the new trailers, this game seem to have a similar tendency. Let's hope it will not fall victim of the oversaturation.

So developers: Do NOT over-develop your game. Once it reached a certain "feature-saturation" it is not necessary to add anything more. Focus on one or two large gameplay themes and do them well!

Critical Analysis: Space Engineers

I want to get a bit more indepth with an analysis of SpaceEngineer's gameplay. If you don't know the game, you should check it out here, it's worth it.

It is possible that in the future some aspects described in this this article will not be applicable to the game as it's being developed. To clarify, this article applies to the 01.026 update released in April 16th 2014.

You may find some of the analysis offensive; in that case, don't get me wrong - I really like this game a lot and it's absolutely promising for an indie title in early alpha; I also realize a lot of what's there is in a very unfinished state. There are multiple things that are still a bit, let's say "uneasy"; on the other hand, other aspects make a good impression, and I'd like to uncover the causes and consequences of either.


What Space Engineers does is to provide a voxel-based sandbox world where you can build, mine and survive in an asteroid field in space. It's pretty straight forward the first time you play it, especially if you are used to other voxel-based games like Minecraft.

It's possible to build space stations, large spaceships and small spaceships from various - partly functional - parts. The latter use smaller voxels (first picture) while the former two make use of voxels twice as large (second picture).

Voxel Sizes

Larger voxels are nice for large scale ships and stations. You don't need to build more voxels in order to get the same size, compared to when using a small voxel size.
However here lies another problem: you cannot pull the same level of detail on large ships as you can with small ones. Larger ones will always look very "rough" with the low voxel resolution that is being used here.

The previously mentioned effect is especially noticable in interiors. Since each voxel is as large as your character, you cannot use voxels for more subtle details. Each level of your space station/large ship thus needs to be one voxel high, plus another voxel for the floor. This causes them to look rather chunky and also limits the player in the creative process.

This effect can be decreased by providing a variety of thinner plates you can walk on that are designed for interiors, instead of using solid blocks all the time. While there are already some thinner plates in game, they are not designed to be used as floors or ceilings, but rather grates or similar.
Another possible solution is to provide something like a "brush size" for voxels instead of just scaling up small voxels: Large spacecraft/stations created with a default brushsize multiplier of 2x, while small ones with a 1x multiplier.

Where to start building?

I felt kind of "lost" constructing my spacecraft, being not too sure what to do or why. This happens to me even when already being used to the game and possessing basic knowledge of the game mechanics. I am not entirely sure of the causes for this, and I can name the following possibilities.

1. The game lacks purpose for certain types of spacecraft or ship parts, i.e. combat is not implemented yet, thus turrets and combat ships are somewhat useless for now. (You also may end up building something you don't even need as the game currently has no real focus other than building and mining. Of course this will change in the future)
2. Voxel-based construction of objects gives full control and freedom over your creations and their design, but may offer confusion as well since new players do not know where to start (or with what)
   The interesting thing is: this is something I also encountered developing a ship editor prototype that imitates voxel behavior for StareFire. I guess it's safe to say that creating interior from scratch that also has a function to serve can be very challenging.
   
   A solution for this problem can be setting up a dynamic To-Do list for each ship that lists up the minimal amount of parts required to create a spacecraft or station. Another solution can be creating large and hollow 3D frame models that allow the player to better plan out interior design. (The players could make these frames on their own with the voxel engine, however they turn out chunky due to the voxel size on large ships)
 

 

Construction in Survival 

To the left you can see an optimized version of a small miner I created in survival mode, which took me ages to create from scratch. It's also my first legit spacecraft.

Construction in survival is tricky. Moving around large amounts of ore with an extremely limited inventory capacity is not nice at all and very time consuming. AND that is just for a very small ship. Limited inventory space also prohibits you from constructing large bases and forces you to somehow build a container close to the construction site first, then store all materials there. Larger objects take an enormous amount of material to construct; which in no way you can manage to manually gather as a single person. Construction time of larger spacecraft is not easier either seeing how welding the hull parts in order to finish them takes a lot of time also. The fact that a lot of resources are required to produce hull parts in the first place makes this worse (BUT it should be noted you can adjust production rates when creating the game or editing its settings).
The situation has improved alot with the recent introduction of conveyors and pipes. You can do large bases that hook up refineries to assemblers, and assemblers to a large storage and fully automate unit production. Even unloading and loading transports or miners can be fully automated. Still, starting from scratch remains a pain in the rectal area.

Additional solutions - especially for the problem of starting from scratch - can be the introduction of a tool or small machine, like a little buggy or "wheelbarrow in space", that allows you to move around larger amounts of cargo even if you don't possess a functional spacecraft. Another solution can be to adjust the default production/mining rates.

Destruction and Damage

What I really like about this game is the fact you can virtually destroy everything. Collisions deform spacecraft and asteroids alike, asteroids struck by missiles will crumble, and failing to decently dock to your space station has the potential to damage your spacecraft (or even destroy it).

The only problem I have with this damage system is that it becomes difficult to rebuild already destroyed structures and the fact you need a lot of resources to repair it. It may be of advantage if the ship saved the destroyed parts and enables you to replace them with ease, i.e. just by reconstructing them with the welder.


Other aspects that are slightly unbalanced exist, i.e. the production of solar panels (require many resources to build and basically not even worth using if you're starting out) or the fact you're doomed once you run out of Uranium in your base reactor.
But a lot of things are to come to make this game even better than it already is. Visually it's astoundingly simple yet nice to the eyes by providing enough detail to keep you interested. The fact I rambled a lot about its flaws should not hold you from getting it if you like voxel-based sci-fi games.

Reflection

There are a few events that made me stop and think. Like recently I got my hands on an UML modelling program called Enterprise Architect during courses, and also bought the game Space Engineers.
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:

1. 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.
   
   
2. 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.
   
    
3. 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!

CamoTanks Sound Demo

A Camo Tanks sound demo is online:

Features a simple HUD, reloading, firing, and camouflage. FX used from freesound.org plus a song by me mixed in. I apologize for the horrible quality; I wanted to get a reasonable upload speeds without making the filesize explode and kind of failed.

I'm currently making improvements to the camo mechanic, later on I'll create a better AI for the static machine guns as seen in the video. Finally I intend to make an AI for tanks and infantrists as well.

What's also on my Todo List:

• Add sprite sheets instead of loading single files
• Camouflage Skins <--> Terrain Matcher. Terrain and camouflage have an average color, and based on how similar/different they are, a camo value is estimated - Currently it's hardcoded.
• implement positional sound (sound is played "globally" at the moment)
• Add powerups (later: items)
• Day/night cycles: Add a light factor to the camo mechanic. May include some kind of terrain shader as well. (I love when you wander around in the dark in a game only with a flashlight giving you some light).
• Improve AI further by making it respond to noise a target makes and its visibility
• Fix physics location not equal to graphics location

CamoTanks GUI & Sound

So here a short progress update on CamoTanks! Last week I kept myself busy with varous things, such as GUI, gameplay and the occasional bugfixes. The GUI in this game I want to keep as simple as possible, as it is more a source of information rather than interaction (interaction is only for menus). As you can see by the screenshot below, equipped weapons will be displayed on screen, and maybe I'm going to make these customizable. They are also subject of colorization as described in this article.

What also has been recently implemented by me are recoil and spread for weapons, terrain "fluidness" (determine how fast you travel on inaccessible terrain), and multiple fixes for reloading.

I also have added sound already. Implemented sounds are: steps (each terrain type = different sound!), firing, reloading, and an environment background sound. Adding sound to this game REALLY changed the entire feeling of it and it was a very exciting thing to do; to see your game come to life like this. I plan to add more various sounds to make this game even more awesome using the free sound library here (which I strongly recommend using). A video demonstrating this implementation will follow as soon as I fixed some things, i.e. performance needs to be improved and I want a semi-working interface instead of pure text first.

All in all development is going well. The code is surprisingly clean and easy to extend. I suppose this is the positive effect of target-oriented coding; aka coding to get stuff done rather than to think up modular systems (the latter I did a lot while working on StarFire and it slowed me down quite a bit).

There is a lot of stuff I yet want to implement, like adding more detail to the camouflage part by adding a "visibility" and "noise" parameter to the AI . Visibility is mainly influenced by camouflage and movement, while noise is influenced by movement only. The AI looks to the direction it hears sound, and only attacks when an actual enemy has been spotted and is not hiding behind an obstacle.

I also want to let the player mount vehicles and add some survival gameplay. Multiplayer is also planned but I need to look into this more.