Hermetica: ~1100 hours project short report

[dmitrijbes]

Introduction

Welcome-welcome, my dear friend-in-dev, come and join me by the fire, while I share with You my story of building Hermetica.
Hermetica is a Godot based game I have been developing for 1092 hours and I hope I can save You at least some of that time.
Let me promise to make it short or at least be sure, I will try.
A little disclaimer about me, I had zero knowledge of Godot when I started.
However, I already had medium game dev experience and overall high software dev experience, so Your millage may vary.

Download

You can download Hermetica here:
https://dmitrijbes.itch.io/hermetica

General Info

Hermetica is a game about magic craftsmanship with a deep and complex mechanics.
I wanted to create a game where magic is not just a preset of 60 similar spells, but something a player can study, develop and master.
To handle such a requirement, a dynamic world is needed. That’s why Hermetica is implemented using voxels.

Do no use voxels, unless You absolutely have to.

There are almost always better alternatives for Your gameplay, such as heightmaps, for example.
Voxels are deceptively easy to implement, but surprisingly unwieldy during gameplay implementation.
It’s not without a reason, why there are so few popular games using voxels as part of their core gameplay.
Voxels as visual aesthetic is fine, though.

Features

Some of Hermetica features You might be interested in:

• Spellcrafting based upon visual 2D state machine.

You can create a spell, which will auto-build a custom building of Your design.

• Semi-gridless voxels that can be rotated, scaled, etc.

Floating islands that can fly, be terraformed, connected, etc.

• Voxel based characters and items, including player.

Your character is Your health bar: damage to “leg” voxels will slow You down, etc.
Armor equipped is additional voxels, protecting Your “leg” voxels from damage.

Engine

Hermetica is built using Godot v3.4.4. Yeap, Godot 4 is much better, but porting is always a pain.
Nevertheless, Godot 3 is already a mature and stable engine. Not without its quirks, but any big enough project have those.
Documentation is also great and I love the community!
Working with engine is quite a joy and so my deep appreciations to creators and contributors.
Special thanks goes to Zylann, half of the issues I stumbled upon were already discussed and researched by Zylann in Godot repo issues.

Do not wait for the next tool, update, etc. Godot is perfectly good for all Your major needs as it is.

Hermetica is written primarily in GDNative C++ with some parts (UI) in GDScript.
Overall C++ experience is rough. Bindings are working, but are clunky and esoteric.
It’s often feels as if You are struggling against the engine and its design.
Lack of documentation or tutorials are also playing their part.
Guess it’s kind of a negative feedback loop. Hard to use - no one uses it - no improvements - hard to use.
Especially frustrating to see some useful code in engine sources, which is just not accessible from bindings API.
GDScript on the other hand is great! Easy and fun to work with. Not so slow as people tend to think.
It’s actually feels like language tailored specifically for Godot.

Write Your project in GDScript and optimize critical parts in GDNative if needed.

Most of the projects don’t need that kind of optimization and low level control C++ provides anyway.

Architecture

Hermetica follows a popular pattern of strict separation between abstract game data and Godot implementation of it.
Voxels are stored using a custom data structure consisting of sparse octree at the top and arrays at the bottom.
This allows to strike a balance between low space usage and fast access.
Data is stored in SQLite database and serialized dynamically during runtime.
There are several additional tools used, such as MagicaVoxel importer, etc.

Stats

Development time: 1092 h.
Days of dev: 212 d.
Median of dev per day: 5.1 h.
Upper quartile of dev per day: 7.3 h.
Lower quartile of dev per day: 3.0 h.

Technical dev inc. research: 787 h.
Game modeling and design: 179 h.
Graphic design: 38 h.
Testing: 18 h.
Additional research: 14 h.
Misc: 56 h.

Tips

Here is an arbitrary, non-exhaustive list of tips, which came to my mind:

Focus on the quickest implementation of Your MPP, Minimal Playable Prototype.

If Your game is not fun to play in small, it won’t be magically fun in large.

You don’t need perfect code, perfect art, etc. You need a working project.

Prioritize what player can see and interact with over anything else.

It doesn’t matter if each snowflake in Your game is unique, if all a player can see is a bunch of snow to shovel.

Design first, implement last.

Implementing is almost always more time-consuming than designing.
And You really don’t want to reimplement all the stuff You have already made because of a single poor design choice.

Estimate development tasks and goals, preferably in hours.

Be honest and clear in Your estimates. Evaluate and adjust Your estimates after finishing a task or goal.
It’s too easy to fool yourself that something is quicker to do than its actually is.

Decompose tasks into smaller tasks, no longer than 3 days each.

It’s too easy to spend weeks trying to improve something Your project really doesn’t need.

Final Thoughts

Although I still haven’t finished Hermetica in a scale I was hoping for, it was quite an interesting journey.
Guess that’s what it’s all about, You have to love making games, just as a process, a craft.
Because doing game dev as a business endeavor is certainly not an efficient or reliable way to spend Your time.

If you’ve come this far, Thank You for Your time reading my short report!
Feel free to write me a comment or a question, I will gladly answer those.

Best wishes in Your own journey,
Dima Beskrestnov

[O_K]

Wow, thanks for such a detailed timeframe estimation. I honestly was googling for something like that - how much time does it take to make something meaningful, not a 1hr snake tutorial, after trying with Godot, and Unity for couple past weeks.

As strange as it may sound your essay basically finally convinced me that game dev is not for me. While having strong coding background, I realized that you are right in “You have to love making games, just as a process, a craft.” - and I evidently don’t =)
1000 hours is a significant time investment, and I am clearly in the mindset of playing my “dream” game, but not really making it for so long. Thank you again for sharing your journey.

[dmitrijbes]

Thanks for the comment! Glad my wall of text was helpful)
Considering how 1k hours is on the lower side of estimates, yeah, games require a deceptively long time to make.
That’s why big projects have actual teams of devs, plans, funding, etc. It is a full-fledged software project.
Better to be mentally aware and prepared for years of work ahead, often unpaid and unsuccessful in the end.
Nevertheless, You can still create a small game in a reasonable time, if that’s what You like)
It doesn’t have to be the most complex, huge game in the world, to be enjoyable and interesting to play.

[teotigraphix]

@dmitrijbes

Not so slow as people tend to think.

It’s the Math calcs and custom graphics per frame that haunt GDScript. For the most part it is fast enough for what people use it for.

[dmitrijbes]

You’re absolutely right! Although, math and graphics are the main things games do)

[pauldrewett]

It was a pleasure to read about your game and journey, and it sounds very interesting and immersive. I too am approaching 1000 hours on my game, (I can only estimate of course), but your ‘design first, code later’ advice hit home. I’ve totally lost weeks over-engineering stuff players never notice, or ends up getting dumped when gameplay proves it pointless.

Over the months my game has metamorphosized into something very similar to the original concept but also very different. It is funny how small details can become the focus of a game without any intention on the makers part. And some bits I thought would be so important are just dwarfed.

It is very hard to fully appreciate this one:

You don’t need perfect code, perfect art, etc. You need a working project.

It is so true and I know it but I can still find myself spending days because that explosion was just not right or that movement is just not what I wanted… Only to find I ended up using none of them and the movement was dumped for a different input system. Oh well…

I also recall when I decided to explicitly static type everything (I am glad I did btw) but when I first changed it in the editor to a warning I had about 3000 warnings to clear up! What a fun weekend that was!

I had heard how being a solo dev is very, very difficult, but to be honest, it is amazing how much determination you need to get through the lord of the rings style journey!

Looking forward to seeing Hermetica evolve even further, perhaps even playing it some time. Keep sharing your progress, I would love to hear more about it!

[dmitrijbes]

Thank You for the comment!
It is fascinating to me, how a single idea can have many different implementations and all of those can be quite interesting, unique, worth trying.
But it’s also confusing, I end up asking myself, did I get it right, is this the best way to do it?
It’s like trying to solve an equation in multi-dimensional space, with 100k dimensions and not knowing how the solution or even the equation itself looks like.
Although, that’s probably why it is so fun and interesting to design and develop)
So I can totally see Your point, how even a simple concept can evolve into something completely different down the road.
Which is.. also confusing, pheheh, is that really the game I had in mind? The game I want to bring into the world?

I feel Your pain, as a person, who is also prone to over-engineering and over-designing stuff.
Hard reality check when it fails during gameplay tests.
Takes courage and honesty with yourself, to throw out things you meticulously crafted over weeks or months.
But also, I sometimes wonder, maybe it also takes courage to stick with your original design, rather than to adapt it to a general, expected form.

For me, development is not as hard, as it is long. It’s just tough to commit, considering that it will take years of your life and can easily end up being nothing.
Moreover, considering how our lifetime is limited and we only have so few chances to make it right.
I also think people in general do not know or comprehend, how much time and work even a small project requires.
Any person, who in their life completed any project, no matter how small it is, has my respect.

1000 hr is quite a lot already, have You considered making a public, playable prototype of Your game?

[pauldrewett]

@dmitrijbes

1000 hr is quite a lot already, have You considered making a public, playable prototype of Your game?

Yes, but in all honesty it scares me quite a bit. I am nearly ready for that but what if people don’t like it? I mean I hope they do, but actually putting it out there is hard. I know the next step is user testing and I am nearly there. It is a simple game compared to yours and I am still learning along the way. At the moment I am doing tutorials and just this morning I decided there is too much detail and am simplifying it, I mean people are not idiots and a power bar is a power bar, don’t have to explain that too much. So again chucking out some code I spent yesterday doing.

I gave myself six months to complete it but that period ended over a month ago. So I am behind schedule. I am giving myself an additional three months to complete so I have two months left. I try my best to get 4-5 hours a day in (more on weekends of course) but it can be exhausting, although certainly not boring.

Its why your tips resonated so much. They are spot on IMHO. I knew your first two tips perfectly well when I started this game but only experience really drives them home. On my next game those two things have been hammered into me:

Focus on the quickest implementation of Your MPP, Minimal Playable Prototype.
You don’t need perfect code, perfect art, etc. You need a working project.

Words of wisdom, easy to say “yeah, yeah, I’ve got that..” but just as easy to forget when you are in the thick of it.

[Demetrius_Dixon]

@pauldrewett

Yes, but in all honesty it scares me quite a bit. I am nearly ready for that but what if people don’t like it? I mean I hope they do, but actually putting it out there is hard.

I personally cannot wait for that day. Good and bad, I think it’s gonna change my life for the better.

What I find hard is marketing. How is a potential player supposed to try the game if they don’t know it exists? Simple, they can’t.

@pauldrewett

I try my best to get 4-5 hours a day in (more on weekends of course) but it can be exhausting, although certainly not boring.

This. Game development is never boring because crazy stuff always happens and one day is never the same (unless I’m stuck on a stubborn problem for a week. AAAHHHHHHHHH!!!) And it’s going to be even more coo coo crazy when a build is in the public. But I like crazy.

[dmitrijbes]

It’s completely normal to feel nervous about sharing things You have worked on for so long and thus care so much.
Being judged, evaluated by the public is never easy for any of us.
However, it is inevitable and crucial for the project’s success. I would recommend doing it as soon as possible. Ideally, even before development starts.
Better to go through it straight away, with all the fears, disappointment and negativity, than to do it anyway, but later on, with more time and effort already invested.
It’s not about getting it right the first time, but rather about being able to take feedback and adapt.
If it’s bad, no matter how much You will polish it, it will still be bad.
Anyway, what is more probable, is not that people won’t like it, but rather won’t pay any attention to it.
Which is, arguably, more painful and not as easy to fix, as simple critique.

4 hr per day is quite good, especially if You already have work, education, etc. going on.
Be prepared that development itself is only half of the actual project.
You will still need enough time and energy to publish, support, etc.

Phehe, yeah, although I have written those lines myself, I also tend to forget it, when I am developing.
It’s a fine balance, you need to be a perfectionist to make it good, but you also need to be a realist, to make it at all.