Icarus.ZERO is my personal project that I started in early 2023.
My intention was to make a playable game pushing performance and visuals to a level comparable with commercially available games. I used the Godot game engine and C#.
While the game is not finished and currently on hiatus, I did learn a lot in the process of making it and created a lot of art and code, some of which you can see here.
The individual segments show the state of the game after about one and a half years of work on it.
The last segment shows the progression of development from the beginning.
These sketches and renderings show the general atmosphere and setting of the world of my game.
I have used a combination of analog and digital sketches, as well as renderings made using Blender to establish a look and mood. The segments on this page showcase my interpretations of the setting in more detail.
Elevator pitch:
Near future earth, nascent mega corporation based space exploration, privatized espionage industry.
Humanity encounters something unspeakable in the vast depth of space.
Explore a moon lightyears away from earth with a research experiment gone wrong and experience the cosmic horror for yourself in third person.
The player character, bot and weapons were made with an emphasis on diegetic design. As much information as possible should be conveyed through the textures and assets themselves.
I limited the colors of the environments and reserved saturated colors to elements that would communicate information to the player. Turquoise and orange for the weapon modes, pink for low health or an overheated weapon and blue for interactibles.
The player's ship is a small craft that can enter and leave a planet's atmosphere on its own.
It has two compartments, a living compartment with flight controls in the front and a cargo compartment in the back. Separating them is an airlock and a bathroom module.
I aimed for a simple, yet elegant shape that does not seem totally unrealistic as a plane/spaceship combo.
Since the ship would be part of the levels and I wanted an uninterrupted transition from the inside of the ship to the exterior environment, the interior space had to actually work, including all landing gear, hatches and the access ramp.
Since the player can not actually fly the ship in the game, I included it on the main menu screen as I really liked the visual appearance of the closed ship in space.
The design of the enemies is the result of two considerations. Firstly the technological state of the universe of the game. Secondly the mysterious events of the creepy research station that the game takes place in.
The result are autonomous military drones that got corrupted by a cosmic force beyond human understanding.
Enemies have weak-points that correspond to one of the two weapon modes available to the player. They can also transform after those weak-points have been hit.
Since designing and realizing the assets takes a lot of time and effort, I tried to make the designs modular, with a base body and modular add-ons to create variety with fewer assets.
After I had come up with the areas I wanted, I needed a landscape to place them in.
I created this landscape using a heightmap generated in World Machine which was then modified to fit the locations I would need.
The first difficulty was the performance of the terrain mesh in engine. I had not yet explored the dynamic subdivision model I implemented in my Terrain Designer application, but rather statically reduced the mesh's resolution based on distance to the locations that can be visited. I also split the mesh up in slices that would allow for frustum and occlusion culling.
The next difficulty was the terrain shader. I used multiple generated texture maps and noise textures to break up the repetition of the tiling textures and also used shader code to create atmospheric effects that further enhanced the look.
This area produces the food and water that the researchers need. The towers act as vertical farms.
In the game's universe, farming is dominated by a corporation that behaves almost like a religion, so the production of food is treated as holy and monuments and temples accompany food production buildings. This allowed me to add decorative and monumental architecture to levels that are otherwise quite utilitarian. I also placed it at a higher location in the terrain to make it visible from different locations and serve as a landmark to players.
The underground segment expands on this concept further, plant seeds are stored in refrigerated coffins and livestock embryos are stored in a vault akin to a library archive. Gameplay-wise the underground connects the location to the later part of the game world in a non-obvious way.
The surface hub is the center of the research base. It is were people live and work.
This area has connections on all sides and should allow the player to explore in any direction they are interested in.
I tried to exclusively use modular assets to create all the structures in the level and even the ground itself. I also imagined how such a place would be constructed and how the components would be transported across space, so the modularity emphasizes that as well.
Daedalus is series of low orbit space stations, each with modular laboratories that can be replaced to better suit the need of the project or ejected if an experiment goes wrong.
When creating a world that lets the player explore in any direction they choose, it is difficult to have a controlled, encapsulated level that can be used to introduce game concepts to the player. To solve this, I created this space station that the player starts in. This allows me to craft a contained experience that I know the player has gone through and that I can use to introduce the game before I let the player explore freely.
The idea for such an area came early in the development but realizing it was one of the harder things to do. I like the final design very much, as it allows for a lot of flexibility in level design with the module system but also looks visually striking and unique. The appearance is a result of the functionality which enhances the result a lot in my opinion.
The landing zone area was the first area I tried to bring to a finished result. While not every part is fully finished and a lot more middle to smaller sized assets are needed, I am satisfied with the current state of the level.
I tried to use the state that the cargo area in the back is in and the assets placed there to give the player a hint as to what has happened in this place before they came.
Tiling materials were created using Substance Designer, 3D assets were textured using Substance Painter.
I used custom shader code to add variety to static assets by using the objects location as a random offset to parameters of the materials. This results in crates that have slightly different colors and soda cans of various colors, etc. Of course they still share the same textures and meshes and the variation does not require manual adjustment but can be tuned if required.
Implementing performance profiling was crucial to make my game run smoothly.
Timing functions works very similarly to how I later did it in my Terrain Designer application, every time the function gets called the duration of the call gets measured. After every frame, results are drawn into a graphic on screen that keeps overwriting the oldest entry it has. This allowed me to immediately see which functions were slow, how often they were called and which other functions they were usually called with.
By having this information I could see which parts of my code were slow and needed changing, then I could further explore why that specific part was slow. But if I did not have this real time profiler, I could only guess as to which parts of my code needed looking at.
I also added other debugging information, such as a log that shows which files were accessed and an overview of the level to show which regions are currently considered active and would have the enemies in them updated, etc.
Combined with a debug menu that lets me spawn enemies, add items, set world state and transport to other locations, I have created many useful tools for testing and debugging my game.
First Part:
The initial version focused on getting the character controller off the ground. That meant having a movable character model and a third person camera that work together.
I needed an avatar to use in the game for testing purposes so I created the little alien and set up a basic rig and animations.
I made a small test level with abstract shapes that would let me test how the character controller interacted with the level geometry. I also added basic weapon functionality at this stage as it would be a major component of the gameplay.
The next step was to create a few photorealistic assets and prepare a test scene for the visuals.
Second Part:
I assembled a test level with areas for traversal, exploration and combat.
A few prototype enemies and weapons were tested that had basic hard coded behavior.
Most prototypes chased the player in some form with delayed rotation adjustments, the result felt quite good to play around with. In particular the guided rockets were a lot of fun.
Third Part:
This segment saw further exploration and refinement of enemies.
I started to work with a navmesh and set enemies up to chase the player in a more intelligent manner, avoiding obstacles and traversing ramps to reach higher floors, etc.
I also created some procedural shaders and particels for effects that I wanted to have in the game. The first shader I made was used for the expanding sphere seen in the last picture.
Fourth Part:
After having the basic mechanics of traversal, weapons and enemies working, the next step were some interactible elements like buttons and doors.
I also took my first attempt at building a larger level with rooms and corridors and a feeling of progression.
The level had a dark and creepy atmosphere and was visually and atmospherically convincing to me. However, during gameplay it was a bit too dark and felt difficult to play. The next part will see some changes to the lighting in the world to remedy this.
Nevertheless I was very satisfied with the state of the game at this point and felt that it was going in a promising direction.
Fifth Part:
This part was focused on establishing a sample for how the final environment should look and feel. It also saw the introduction of a new type of enemy and an overhaul of the enemy AI system.
I prepared a handful of textured 3D assets and tried to set a standard for me to match with future assets.
They gave the level a sense of scale and made the simple test level feel more like a real place. I also added ambient light and some atmospheric fog to lessen the very dark shadows and contrasting image.
I liked the previous atmosphere, I had attempted to mimic how actual space looks and combine it with a scary atmosphere. In this part I weakened that feeling to improve gameplay and readability of the world for the player. I tried to achieve a balance between the two factors.
The behavior of the enemies was also reworked to use a system comprised of a state machine of behaviors per enemy and a node based decision tree for each of those behaviors.
Nodes in those trees can be made reusable and whole behaviors can be shared between enemy types.
I also started to add a few debugging features, such as visualization for movement paths and ray casts.
By introducing more sophisticated behavior to my enemies, I also started to encounter performance issues when a lot of enemies are active.
I limited the amount of active enemies using simple world division logic which I would later refine and also introduced variables that would control various factors of how often enemies could update and how many effects they could use, etc.
My solution to the performance problem was not a very complete solution at this point but rather the beginning of a few good ideas that I would expand upon in the final part.
Sixth Part:
After my proof of concept of how the environments should look and feel, I began to work on the actual world of my game.
I came up with an idea for the areas and progression and which kind of world it would be.
It took many iterations and a lot of thinking to get an interconnected, reasonably laid out world that appeared to serve the functions and needs that a research base on an unexplored planet would have, while still being playable.
The next challenge was to get the large terrain I had created to run at a good frame rate in engine and then to start designing the areas of the world.
At this point I needed some way to save the state of the world when exiting the game, so I implemented a save system and the in game menu to go along with it.
Seventh Part:
This last part took by far the longest and implements most of the features described on this web page.
The number of assets and environments in the game grew dramatically. I also learned a lot more about shaders and materials and tried to come up with clever solutions that would allow me to reuse the assets and textures I made but still create a large amount of variety.
I introduced more interactible objects in the world, such as destructible objects, rigid body bottles and cans and more specialized interactions that would be used in puzzles to open doors, etc.
The on screen presentation also saw a lot of work, I had committed to have as much of the HUD be diegetic as possible and so had to include all of the information the player would need on the player or bot models or by using screen effects.
This was also the part of development that saw significant extension of the debugging and profiling features as presented earlier on this page. These features were fundamental in pushing the presentation of the levels while understanding the capabilities of the hardware and also the effects of my code on performance.
Final Part:
This video is a showcase of the things I have achieved in little more than a year of work on the game starting from almost absolute scratch.
For the time being I have paused development on Icarus.ZERO.
I have learned many things about how to make a game and also about how to use your time efficiently. I am still interested in the world that I have created but can not continue to put so much time and effort into this project.
One day I may continue, but for now this is it. I hope you enjoyed what I shared and can learn something from it or be inspired to try and create something for yourself, it is a lot of fun! Thank you for your interest!
Design Talk:
The last video is of me presenting each section on this page and talking about my thoughts and process.
The video has chapter markers for each section, so feel free to skip to the part you are interested in.