The Boy Who Stole The Sun: DevLog, The First - Can't Stop the Movies
Can't Stop the Movies
3Jul/170

The Boy Who Stole The Sun: DevLog, The First

Photo by Nina Gorden.

The Battlestation, photo by Nina Gorden

Greetings! You have found the game development blog of The Boy Who Stole The Sun, a survival adventure game about temperature, trust, and the emotional development of a boy (also about going to magical lands and not knowing what's going on there, and then going home and not knowing what's going on there, either).

TLDR; I'm 34 and I'm a gamedev burnout survivor. I'm a husband and a father. I'm poor and indebted. I'm smart and skilled and damaged, and I'm making the game that my bruised little gamedev heart wants to make. This blog will be the record of that adventure.

My name is Seth Gorden, and I'm starting at the wrong end of the difficulty of curve for making one's first indie game. It's the passion project. The engine and tools are each hand-rolled in C++. It uses a custom software renderer. There is a custom scripting language. It has a non-trivial story and several characters. It has experimental game mechanics that aren't well established in other games I have played or created. It's the game that many veteran indie developers warn us not to make our first time at bat. It is a hard game to make. God help me, at least it's 2D.

In addition to sharing all my wrong turns and problem solving adventures, I am likely to comment a bit on my family life (wife and two kids), problems shuffling around the balance of activities in my week, and the various obstacles to feeling like a legitimate game developer (failures, burnout, impostor syndrome, all that good stuff). I love the idea of building a community around the game and around my work, but this is already manifesting more as a confessional account of my experience rather than a pitch of any kind. That's probably a little backward, but so am I. Thanks for joining me. Here we go.

A little background:
I coded all my first games on the TI-83 calculator in high school. My claim to fame there being that I was, perhaps, the only kid to have his calculator confiscated in both math classes and the math-heavy advanced chemistry class. I did manage to write my first RPG on that platform, called Walrus Hunter 5, because any name sounds funny and appropriate as a teenager. Later I learned Pascal, HTML, C++. I took a corporate job working on data processing software. I learned how to work with databases, postscript for printers, and some web coding. Later, I went to college at Full Sail University to learn game development and acquire more debt than I had ever known. Got my first job creating an arcade game called Sunday Monster Smash, which took several years to make, never went into production, and resulted a couple periods of burnout on the entire idea of game development.

In order to recover from the above, I became an oil painter, learned how to use a wacom tablet, and still hold a part-time job teaching art classes to make ends meets.

It looks neat in motion.

Title Screen with Falling Snow

This blog picks up in the middle of my return to game development as a serious endeavor. Due to the urging and support of my friends, I opened up my abandoned adventure game about six months ago. If we ignore for a moment the turmoil that is America itself and just focus on my home and personal life, I can say that my anxiety is much lower this year than it has been for several years, and with that has come focus, and the ability to see code clearly in my head. Being a visual person, this is a pretty crucial faculty to have in working order. I'm still really rusty on architectural choices in the codebase. Most of my missteps are currently in that area.

That's a good a place as any to jump into the coding discussion. So I'm about to talk about code design. Buckle up.

My most recent impossible bug was my Actor object. It served as my point of integration for visual data (how the critter looks, with references to the image and animation data), physics (how the critter moves), and script (how the critter behaves). And this served as the basis for all interactive objects in the game world.

Seemed like a good idea when I was putting it together, but it gradually became the dreaded GodClass, trying to do all the things. And I ignored several red flags that popped up as I started to use the object beyond simple tests. Or rather... it worked really well for the known goals. And then I used it for the player object. That's when things went sideways on me. The problems had to do with handling more than one source of input.

On the one hand, the Actor already had all the bits of code to update the state of the Actor based on commands from the associated script. The scripting language, in short, pipes in high-level commands like "Walk left for 1000 milliseconds" or "Play Animation[x]", or whatever. Commands are user-defined in a definition file that can be updated at any time. The command definitions are error-checked against the syntax of the language (which looks very C-like, in general), and all the scripts are checked against the language rules and the command definitions, and so on. (That was actually one of the most fun sub-projects of the engine, and I learned so much about compilers doing that work. If you are feeling brave in life, code yourself a scripting language. It will change you.)

Anyway, scripts were the primary source of input, and all code that modifies an Actor object was pretty tightly coupled to the internal command handler (are you experienced coders cringing yet?). When I hooked up the player object, which contained an Actor object, and started having the Actor deal with player input, I ran into problems that I just couldn't see clearly enough to fix in place. The on-screen results were that I could run scripts, and I could take player input, but if I ever made two objects interact (like punching or activating something) the code would would perform the action, and then neither object would return properly to its normal update loop behavior. Yay for triggering things. Boo for becoming a brick in the game world. Bad times.

Couldn't come up with any scheme for managing an Actor's internal state that would properly resolve directional and action inputs from the player and also handle the various modes relevant to scripts and command-handling. It was bad code. I was breaking the intent of the initial design of the Actor object, and more importantly... no Actor was ever going to be taking input from two sources simultaneously anyway.

Don't know what I was thinking when I tried to code to handle both. So I ripped out all input stuff and instead created an ActorCtrl interface that could be implemented for both for PlayerCtrl and ScriptCtrl. I assumed there would still be some state-management bugs to work out and that primary benefit of this change would be that I could see the code clearer if it was separated out. But most of the state bugs disappeared entirely when I took out the input handling completely out of the Actor. It's not much of an Actor anymore. It's more like a puppet now. But that's as it should be.

Coding up new behaviors a much cleaner process now. Any general behaviors now get supported by the ActorCtrl interface. Features specific to player input are in the PlayerCtrl implementation. And Script-only stuff goes in ScriptCtrl. Why didn't I think of that before? Just got rusty. Also, pretty sure anxiety corrodes the mind. Crossing that hurdle, though, was super-helpful for self-esteem and for flexing my architecture muscles again.

The latest fixes represent a critical threshold where I can say that I'm no longer just coding up the engine tools. The game is still pre-alpha, but real content is supportable now. I can code scripts and sometimes implement new behaviors in a single coding session. I have an editor for quickly putting together Actor definition files. And I have a map editor than can launch directly into the game for testing. My iteration speed is pretty solid compared to other games I've made. While the bug list is never truly empty, the game engine itself finally feels reliable.

I cannot state in mere words how much of a relief this is. The earliest
code files in my engine are dated 2011, and this engine was the third in a series of prototypes as I tried to figured out what I was making. Granted, I still had a full time job when I started putting this adventure together, and it was a piecemeal experiment. There was perhaps less pressure for it to turn into a production-oriented, quick-iteration pipeline back then. But that doesn't do much to attenuate the weight of years passing by, wishing I had a game to ship, being perpetually in a state of "almost ready to start making the game" while I chew through bugs and gradually resolve incredibly poor architectural choices.

BUT!..

The cool part is that now I have a very carefully crafted engine and tools, with the better part of six years of testing invested in it. AND it's fun to use. That's about the best I can do to articulate my current excitement level. It's maybe the most excited I've been about any software development since I was in college. This is a very good time for me.

And so my pal Andrew, who runs this website and who has been a primary supporter in my return to game development, has asked me to blog the process. I was at least half-excited and certainly half-terrified to start writing, but I do find already that I'm looking forward to discussing the details. There are so many cool facets to coding a game, and doing a tough project solo puts me on the front lines of everything. This means that even in a pre-alpha state, I have many war stories to share. My brain is already buzzing.

Getting the boy to set objects back down was its own feature.

Yay! The little guy can pick up objects now. Every bit of integrated gameplay is worth celebrating.

I will be posting at least every other week, and maybe dropping in mini-updates if there are questions about tech or the game which require more than the comments section to accommodate them.

This entry has mostly been a meet-and-greet type deal, but I felt some context would help us get acquainted. I definitely want to talk more about TheGameItself in the next entry, but if you want a sneak peak with some gifs and such, I do have a thread for the game over at the TIGSource Forums.

If you have questions, whether they be about tech, game design, or how Indie Dev Is Hard, fire away! I cannot promise to be correct, but I will be honest.

Thanks for reading this far. I already like that about you. See you in the comments section.

Posted by Seth Gorden

Comments (0) Trackbacks (0)

No comments yet.


Leave Your Thoughts!

Trackbacks are disabled.