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

March 2020 W1: Melee Combat

Image
While the combat is far from finished, this week has brought some significant progress, and set the baseline for how getting and using stats is handled. Implementation of more combat features over the next couple weeks should be significantly simpler. Combat progress The primary progress made this week was the implementation of basic melee combat, and its integration with the medical system. The code still needs to be refactored to be more generic, and a little cleaner for use in other types of attacks, but it's written and functional, which is the hardest part. The animation ends earlier than it should for some reason, but it's there There are still parts of what I'd consider the 'basic' implementation that have yet to be added in. An animation for blocking does not exist yet, and the automatic behaviour to fight back isn't finished. The final vision is to have a combat system that is reactive between two combatants, meaning that they would each
Read more