twofordinnergame

[twofordinnergame]

Dec 24 2021 - Engine Complete

I finally did it.  I completed the rewrite from version 3 to version 4 of my game engine.  It took me a couple of years.  Yikes.  But, it's done.

I can start sharing more about my progress.  Here's a proof of life video that shows placeholder art, some lighting, room, and collision system working.  Later in the video I turn on some of the debug shapes.  There's not much in the way of gameplay here.  At this stage, other than the world and room system, I have not worked on gameplay or player skills.  It's a blank canvas.

Was it worth it?  Not sure.  The entire process from zero skills to now took me almost 7 years on and off.  I wrote 4 game engines, a custom scripting language (unused) and a set of tools in 7 years...  I certainly am very competent now in all sorts of C++ programming styles and gamedev.  But it turned out to be a gigantic undertaking and burden for someone who's only slightly perfectionist such as myself.  Hard to say if I would have been able to make good games in the same time had I chosen an off the shelf engine but this engine quest has certainly prevented me from actually producing my clumsily announced demo 3 years ago...  Version 3 and its custom scripting language was a promising engine 2 years ago but there's no contest with version 4.  My future life as a programmer/designer is greatly enhanced by the sheer power and flexibility of version 4. So, from that perspective, I have no regrets.  I can tell there will not be a need for a version 5.  Let's look at it.

About the engine.  It follows the live-coding paradigm I described in previous posts.  The game and renderer are separate DLLs.  The game is launched by a platform specific executable.  All memory is managed from the platform launcher.  Reloading DLLs does not modify that memory unless I choose to and that allows me to near live code the game without shutting it down.  The C++ style I use is very bare bones, procedural, does not rely on compiler heavy C++ features.  All code is brought under single compilation units and the resulting compilation times are near 1s for each module.  This architecture makes programming systems or gameplay a breeze.  I would often be surprised how I could to write complete systems in a day instead of a few days as I used to.  The near instant compilation keeps me in the flow and productive.

About the tools.  I have two kinds, standalone and in-engine.   The standalone tools run inside their own process and monitor my creative apps.  When I edit registered files, the tools package them into an engine ready binaries.  The engine monitors those and live-reloads them as the game runs.  This allows me to draw art or modify levels from dedicated apps and see instant changes in game.  The in-engine tools range from C++ compiler replacement facilities such as meta programming, introspection, custom preprocessor based code generation to visual debug tools, input replay for QA, etc.  These turned out to be more interesting to me.  Due to the coding style and nature of version 4, I can very easily write stuff and see results live.  For instance, just yesterday I was reluctantly looking into fixing a bug in my static light system and I had been dragging my feet there because it looked like it would take a while to nail down.  Rather than starting up gdb and do some old school code investigation (very impractical there because that room had 100s of lights), I wrote an immediate mode style bounding box sprites selected by mouse hovering system to help me identify what light exactly was playing up.  Setting those up took me less than half hour.  I could retrieve several troublesome light ids very quickly just by exploring the world with the game camera and my mouse.  Those ids set me down the right track, and I nailed down the bug quickly.  I had more fun writing the quick tool than using the traditional debugger.  This system would be reusable for other game objects in the future for which I'll want quick introspection.

On performance.  This simpler style of C++ coding makes it easier to run -O3 type compiler based optimizations.  Just by switching that on I gain a 4x CPU speed advantage in most scenarios.  I have also pushed my renderer to do much more sampling and color work than version 3 used to.  I am knowingly using way too many FBOs, essentially having a mini-photoshop like layer system.  The idea being that as I design the game, the facilities will be there should I need them with the intention of bundling things tighter once I am set on the look I'll be going for.  This kind of unduly complicated pipeline made me aware of OpenGL driver overheads and I am now very curious about AZDO style interfaces such as Vulkan but that's a rabbit hole I am not prepared to go down for some time.

Where to go next.  I would contemplate splitting logic from rendering into separate threads to speed up the QA replay facility.  Also, there's more work needed on my audio system, as I would like to have more mixing facility and logic to accomplish some dynamic music effects.

That was a long, technical post.  I am about to open a new chapter on my gamedev journey.  One where I'll be mostly focused on art, design and storytelling, the stuff that brought me here in the first place.  I actually spent the last 2 weeks just doodling until I worked up enough motivation to fix those pesky static lights ;)  I am very happy to be largely done with the engine, even though those things have a life of their own and there'll be no doubt new systems or tools I'll just feel like writing down the track.  I am very excited to be finally turning to those design and art notebooks and try to make Two for Dinner come to light.

I really appreciate your support and interest.  Here, you can have a quick look at the tip of a 7 year iceberg with this placeholder art video.  Enjoy!

Merry Christmas everyone and all the best to you all!

Claude

[twofordinnergame]

Dec 30 2019 Update

I am making progress with the new engine paltform/dll architecture.  Migrating my previous code to this new style will take a while.

Here’s what I got so far.

1. I have successfully managed a clean split between layer code (SDL2) in a barebone launcher and the game inside its own dynamic library.

2. I have a very basic custom preprocessor going.  It supports generic programming and has some basic facility for introspection.

3. The compile times are kept to a minimum through a single translation unit design for each component.

4. The memory is allocated just once by the platform, leaving the engine dll the care to manage it.

Some observations, early on:

I can see how the low compile times, if they are sustained when I migrate the bulk of the engine, render pointless the idea of scripting.

I can also imagine what a custom preprocessor can yield in terms of programming power to generate gameplay code from data.

The custom memory management makes me strangely more wasteful in my usage.  For some reason, it makes memory feel cheap not to have to ask for and delete it all the time.  So I am still to figure out best practices for that one.  It’ll come when I integrate back some of my systems, though.

Also:

I  made the transition from vim to emacs and I have learnt quite a lot in the process that may be useful to vim expats. So I might post about that at some stage.

I hope you had a merry Christmas and are enjoying a good holiday season.

[twofordinnergame]

Oct 16 2019 Engine Dev Notes

Hi,

I am going through a major rewrite of my engine.

This followed a move away from using off-the-shelf tile editors and the current attempt that I am pursuing to create custom tools to help me make Two for Dinner.

I am starting to see some positive coherent results from this effort.  I can now create multilayered auto-tiled tilemaps with basic doors and decals with minimal effort using my custom pipeline.

I am now at the crossroad of bringing scripted objects aka game objects into the world.

Up until now I have relied on a custom scripting language to do the job.  Writing a custom language from scratch with compiler and VM was no small feat. It took me months delving into arcane tools such as Flex/Bison and I learned a lot through it.  It basically consisted in a super lean bytecoded finite state machine where each entity created is only described in terms of states.  All of which can be looked up in a global states table.  The scripting language could also be used in a strictly imperative style to list a series of high level commands, the kind of stuff you’d use to describe cut scenes or cinematics.

I am very happy with this and I might still go on using it.

But I have, like a lot of people out there, heard about DLL hot loading and the golden promises of C++ live coding with live compiling and state preservation (my scripting system does not support live coding or any elaborate form of state preservation).

And so I am faced with a burning dilemma.  Should I jump straight in with working on integrating my elaborate but yet feature incomplete scripting system to continue my engine dev OR do I look seriously into DLL hot reloading?

I am going to take a little time to look into DLL hot reloading and see where that takes me.

The iterating power of live coding C++ cannot be overstated.  If it is something I can get for the engine, it will definitely pay off in terms of game logic productivity.

Cheers

Claude

[twofordinnergame]

Animated logo for Two for Dinner.

Two for Dinner is an indie game with a custom game engine, coded and designed by Claude Ronin.  

Two for Dinner is a pixel art, 2d action sidescroller, metroidvania with a rich story. 

The demo is announced for Christmas 2018.

You can find more updates on twitter.

[twofordinnergame]

Demo (or lack thereof just yet)

Just a quick note to wish you all a merry Christmas and to report that my initial target of having a demo for TFD will not be met just yet. My skills have improved over the past 4 years and my ambitions as to what the engine should accommodate have changed.

The engine has essentially taken a life of its own. It has been rewritten in large parts (e.g., collisions, graphics, tile map system) and I am still working on it. I could tentatively suggest a demo for next Christmas but I am not sure that I will deliver on that. So I wont.

I am very grateful that so many of you have found my project interesting and though I am new at social media I have enjoyed connecting with you. I will post more as the engine reaches a more satisfying level of dev and that should definitely happen in the new year.

Cheers everyone and merry Christmas.

[twofordinnergame]

Meet Otto.

This watercolor is one of 100 I painted in a mad rush of 100 nights to develop concepts for my game Two for Dinner.

I have a special connection to this one as it probably best depicts the lead character and gives visual clues as to the quest ahead.