The Genesis of Solaris

Solaris is the working title of a game development project currently solely developed by me. In essence, it's the result of several years of frustration over my inability to continue work on a single project to completion. Somewhat ironically, this is the largest project I've ever attempted...

The purpose of this blog

I want to take a moment before diving into this post to outline why I created this blog. Essentially, I hope that one day this blog will serve as somewhat of a time capsule for myself - not only for nostalgia, but also to serve as a learning experience, my own digital rubber ducky. Beyond that, I hope that to anyone reading this, it could eventually be a source of both entertainment and information.

If I were to ever release whatever Solaris eventually becomes, I would hope this blog would serve as a practical example of the past and future trials and tribulations of a young indie dev hoping to develop one of the many games of his dreams.

This post will stand as an outlier to most of the future posts as I want to touch on more of the past design process and foundational aspects of Solaris before moving on to my technical challenges in practical development.

What Solaris is, and where it came from

Apart from what I've already stated, Solaris is a squad based sci-fi RPG with colony aspects. The game is heavily inspired by Kenshi, an almost proof of concept technical mess with an absolutely brilliant core design. I've played 132 hours of Kenshi at the time of writing, all within about a two week span.

The game is being developed in Unity using C# and the .Net Framework, and at the time of writing it is in a very early, pre-prototype state.

Design and pre-development theory

A significant part of my attempt to develop this project to completion is the design and pre development preparation. What this practically meant for me was a full GDD (Game Design Document) which at the current moment has nearly 3000 words and 21 pages, and a follow up development brainstorm onto Trello resulting in this beautiful creation:
Trello is great for breaking things down into manageable tasks
The natural follow up is 'Has the preparation helped at all?'. The answer I can give to that question is: I honestly believe it has made a significant impact on my workflow.

The addition of the GDD, Trello, and various other small documents (Including a notes file and several draw.io flowcharts) has improved my consistency and workflow by a noticable margin, however there is the possibility that some or all of the improvement is due to my determination to finish Solaris.

As credit to the Trello, when I slow down and become distracted from my current work, going back to the Trello and looking at my current task refocuses me instantly, and sometimes even helps me re-evaluate my current method of completing that task.
The GDD has helped me keep my design vision in mind while working through my tasks, and allowed me to refer back to a detailed description of specific aspects of my vision, like how the crafting system works, or how a colony is managed.

The future

Beyond this post, I'll be writing up another post outlining the past minor milestones and difficulties for posterity. 

In the quite far future, I hope to release Solaris to the world, and to engage with people who could almost love the game as much as I do. I'm determined to one day be able to cite Solaris as one of my accomplishments, and be proud that I had gotten that far.

For now, thanks for beginning this journey with me, and I hope you stay for the ride.

Comments

Post a Comment

Popular posts from this blog

Development So Far

Image
Technical Planning Even after all the pre-development theory, I still felt like I had more planning to go. The technical planning was admittedly far less robust than the designing, consisting only of a single Draw.io flowchart with some terms that had more meaning to me than anyone else. Frankly, the use of such terms may have been a mistake. A class hierachy plan If it's not apparent, the above image is a flowchart denoting a class hierarchy and their functions in terms of interfaces. The interface names, while relatively self-descriptive, are also quite mundane and could potentially be easily forgotten. I rarely refer to the flowchart at the current moment, as my attention is consumed by the minutia of features rather than the overarching class system, however this flowchart proved incredibly useful in starting the project off on the right foot. Having an organised class hierarchy has saved me a fairly significant amount of work as far as refactoring and duplicated c
Read more

November 2019 W3: [Test_Graphics] Shader and Graphics Research

Image
I apologise for the late arrival of this blog post, the end of last week was a little bit hectic for me, and left me without time to write this up. Week 3 was all about research and learning the topics surrounding graphics and aesthetics for me. This meant lots of new information about shaders, mesh generation, volumetrics, post processing, and render pipelines. It was sometimes a little bit overwhelming, but overall a great learning experience. I feel pretty confident in saying now that I've got a basic and functional understanding of shaders and how they work, though there's always significant room for improvement. Also with this blog post comes a project name change. There are various reasons behind the decision to switch names, but (as you would know if you're here) the game now goes by the name "Project Astraeus", which I'm actually quite partial to. The Results In line with the topic of this week, the results themselves are quite shiny. I
Read more

February 2020 W4: Combat Preparation

Image
The original intention of Week 4 was to implement at the very least the functionality for attacking with melee weapons. Unfortunately, that ended up taking a back seat to some much needed refactors due to added functionality to character skills. Refactoring Skills Originally, skills were stored within a C# Dictionary containing the skill name as an enum, and the skill's data as its key. This worked fine while the skills could comfortably sit on a single line, and didn't cause any ridiculous level of clutter, though it wasn't quite compact either. New skill functionality The functionality that expanded the data structure for skills was in essence a way for character stats (Attributes) to relate directly to how a skill effects an items individual stats. There was no previous system in place to relate attributes to skills or item stats, so the introduction of this system not only opened up a lot of versatility in balancing, but also introduced an entirely new conce
Read more