Changes of a Cosmic Scale

I’ve reached a critical juncture in the development of my game and engine.

I’ve been developing a game for the past 15 months. It’s been a labour of love, as any indie game developer can attest to. However, recently something happened that has forced me to pivot my roadmap significantly.

Before I get to what’s happened I’d better give you some context, because I realise it is sorely lacking at this point.

A Brief History of the Project

Over two years ago I discovered how I could make the time to pursue my dream of developing (and releasing) a game. I’ve wanted to do this my whole life, and after several uncommitted attempts and a gap of at least 20 years since my last try I realised the passion to do this was burning as intensely as ever. What’s more, taking on a side project was going to save my sanity, as my 22+ year career as a programmer wasn’t letting me practice the skills I felt I needed. I love a good synergy, and here I could cover both issues by building a game.

I chose to use the Microsoft .NET stack because the bulk of my developer experience is there, and the devices I owned (phone, desktop, laptop) were all in the Windows ecosystem. My laptop was a 128Gb Surface Pro 1 (bought the day they were available) and my phone a Nokia 930 running Windows 10. Both were in fantastic condition (both operationally and aesthetically) despite almost constant usage. However the Surface was so full of development tools and SDKs there was little free space for my project or other tools I would need.

I only had very small daily periods to work on the project; my available time was daily train commutes to and from my day job. This started out as a 20 minute commute in the morning and the same in the evening, however along the way I did move house and this became two 30 minute windows that I currently enjoy. In terms of committing time to side projects this didn’t sound enough at first, and the disbelief I could be productive in such small bursts put me off for a long time. Being unable to find any other time I gave it a go, and two years later I’m amazed at how much I’ve achieved.

ASIDE I submitted a talk to present this development process at a developer conference last year but it didn’t get up unfortunately. It’s worth sharing the challenges and benefits of this process perhaps one day I’ll at least blog about it.

As a consequence of the short periods of time available and being disconnected from the network while commuting, I chose not to start with an existing game engine as I felt it the learning curve require a heavy investment in online tutorials and other online research to be productive. So I decided to build the game engine on my own from scratch as well as the game itself. I know that sounds insane, but I didn’t rush into this decision blindly; I knew it would be super tough (and more than I could imagine), so I did quite a bit of experimentation and exploratory coding before I decided it really was achievable.

I knew I would be happy with this decision as it would finally afford me the practical experiences I was craving (writing high performant, memory efficient code, and exploring previously unvisited areas of the .NET Framework), as well as allowing me to dump decades of mental pseudo-code into reality to see if my theories actually worked.

Setting My Own Expectations

Given it would take a long time to build both an engine and a game from scratch under normal working circumstances, and that I only had 40 minutes a day (20 minute sprints), I had to be realistic about time. Most game developers and studios set themselves deadline/completion dates for their games, but that just wasn’t applicable for what I was doing and how I was working. I chose to not fix a date, but to fix the quality of the game at a high level and it would take “as long as it takes” to build.

This meant I could commit to getting the design of the engine right from day one, focusing on performance, no memory leaks, and no blocking garbage collection when playing. The latter was the strongest in my mind, and I did a lot of further research to confirm what I believed was the best practice to avoid garbage collection in .NET (mostly declaring all memory use up front via object pooling). This lead to some satisfying conversations with people who were actively working on the .NET garbage collector at the time, the discovery of a memory profiling tool (BenchmarkDotNet), and a practice of regularly profiling the .NET framework to ensure my choice of code implementations in the engine code were optimal. I even blogged about that in my first blog post.

Finally, I knew that if this worked it would be the beginning of a number of games I would produce. I wasn’t expecting to make any money from this first project (being on the Windows marketplace, which is a pretty small market compared to Apple and Google) so I expected to release the result for free, with some clever ideas for monetisation that didn’t change the game dynamics. The value I would get out of this project would be very personal:

• Practicing and developing the skills I felt were missing in my current skillset (personal skills growth)
• Keeping sane at work (not trying to force personal development into my day job as it just wasn’t happening)
• Getting years of game routines out of my head and into reality (overcoming impostor syndrome)
• Expanding my knowledge of game development terminology and practices (setting myself up for future game projects)
• Finding other game developers locally and on the web that I could talk to (establishing a new social network)

Finding Support

I didn’t take that last point lightly. I knew what I was undertaking would require endurance as progress would be agonisingly slow. I back myself for mental toughness and sheer determination, but it would be foolish to take on such a project without support from others who knew what I was going through.

So I reached out to the only game developer I knew (from a meetup he presented at once), who directed me to a local community called Let’s Make Games. I started attending Playup Perth where local developers were provided space playtesting their games for review and feedback. I exchanged Twitter handles with a few local developers and made a few connections. Social media then quickly expanded my network, and even revealed video content such as the excellent vlog Just Make Game by Armitage Games.

Starting with Microsteps

My first development task was to figure out was which rendering technology to use. I wrote several tests to trial Win2D which proved more than adequate. It works great as a performant renderer (siting astride DirectX) and also provides a game loop controller managing timing complexity for fixed timestep loops (and variable if you want it). It cohabits nicely with the Universal Windows Platform (UWP) which was my target language framework.

Each new test I created established further confirmation that my stack integrated comfortably, allowing UWP gestures and touch and .NET sensor support (accelerometers and the like).

An early test - UWP gestures with Win2D rendering

These initial tests took some time but were important. I needed to be confident I wasn’t committing to a path leading to an impassible road block somewhere along the way. They also allowed to solidify my solution architecture while I explored the technology space.

Another early test - testing the performance of sprite batches in Win2D

As my tests grew in number and I learned more, the design for my game started to form in my mind. Resisting the urge to fully specify the design up front (who knew what I would discover along the way) I fleshed out about 70% of the design without committing to paper (for design agility).

I now had my base game design and practical knowledge of the technology choices I could use to build my way there. My direction was established and it was time to start moving.

One of the final tests - parallax clouds working across multiple devices with UWP

The Zodman Project (#zodproj)

After working on the project for several months my enthusiasm hadn’t waned and I had produced a surprising body of work (at least to me). Inspired by other indie devs in my social network, I decided to begin sharing my progress on social networks as well. At the time I didn’t have a blog, so I decided to use Twitter to give tweet-blogs about my work augmented by video.

With a need to relate these tweets together I realised I needed a hashtag. I decided to label all my side projects under a single banner; The Zodman Project. Zodman is the nickname/handle that has stuck with me from my gaming days way back in the 1990s, and I’ve used it prolifically as an ID across the web for all this time (using ZodmanPerth when Zodman is already taken). The #zodproj hashtag would be used to group together all my online posts about my side projects and provide some context to individual posts.

As a lover of coherent narrative, I felt it was important to start sharing progress from the beginning of the project, so my tweets started with those initial tests and proceeded in linear order. I wanted to show the body of work so far in weekly tweets until I caught up to where I was coding. I found this difficult because I had to find the time to create the video and also maintain my code so that the older tests continued to function while I coded at the bleeding edge of the project. This was particularly challenging as I continuously refactored my engine as I discovered better ways to do things.

One other challenge was the size of a tweet which only allowed 140 at the time. While this was a blessing as it brutally focussed the scope of my posts (and let the video do the talking), I started getting that nagging feeling that maybe I should bite the bullet and start blogging as well.

A Blog is Born

Following a lengthy performance investigation with PerformanceDotNet, and having to augment the way it works to concatenate multiple runs into a single report, I finally had something to share that was beyond what Twitter could suitably accommodate. It was time to get my own blog.

After scouring the web for ready-made blog services, worrying about loss of IP/data and control over layout and style, I settled on source controlled static site generation and managing deployment and hosting myself. Hexo is a static site generator that suits my commute-working style. Posts are markdown which I edit using VS Code and suits source control. It includes a local node server for testing the site locally prior to deployment. I then deploy to GitHub pages which provides hosting for a single, free, size-limited static website per account. After paying for a DNS entry and routing requests to Github, my blog was online.

I had finally created an environment to share ideas in depth the opportunity to start a game blog. However, I struggled to create the time necessary to create blog posts. It takes some time to create posts, especially when you haven’t blogged in a while and you’ve got a lot of ground to cover.

I found I wasn’t blogging because of the time required, and all the time I had available went into developing the things I wanted to blog about; Catch 22. Still, at least I was pushing my game and engine forward so I could be happy with that. I resigned myself to remain uncomfortable with falling behind in sharing my journey until I had some time to reflect on resolving the issue.

Upgrading my Development Environment

Even though things were going pretty well with development I was starting to really feel the lack of disk space was starting to hamper progress. I had been eyeing off the new Surface Pro (2017 edition, 5th generation) with envy, and when my wife’s laptop finally died it was the perfect time to change up and gift her my Surface Pro 1 (a major step up from her awful laptop at least).

I went for the basic I5 with 8Gb RAM and 256Gb disk space. I went for extra disk because of my troubles with space in the past. I expected this device would last me for the next 5 years or more, and the knowledge that in that time I would start using pre-built game engines and other tooling that would eat into the free space.

The development experience on the new machine wasn’t too different to the 1st generation to be honest, though the additional screen resolution and CPU power made a noticeable difference. The new screen doesn’t handle being in daylight on the train as well though, and I had to purchase a polarised screen protector because when I was wearing my sunglasses I couldn’t read the screen! The screen brightness isn’t as bright either and I still find it a little difficult to read.

I must say though that it’s well worth buying the new Surface Pen and nib set. The tilt control allows you to sketch with a feel almost like using a real pencil and I can’t wait to do some art with it when I can find the time.

The Game Changer

And then it happened…the big whopper; the event that would change everything. Microsoft had released a Windows 10 update that stopped my phone from working properly.

First I noticed that my Twitter app stopped scrolling after displaying about 20 posts. This was annoying as every spare moment I had would be spent looking through my feed to stay motivated by the indie dev network. I was missing out on a lot of great content and motivation.

Then I noticed my email wasn’t working to well either. I could no longer email research findings to myself for review on a desktop sometime later. The loss of this functionality made things a bit too much to bear.

I had encountered similar issues with a prior phone update, but not for such an extended period. The phone partially installs the new update (causing software quirks) but it fails and tries again at the next opportunity (my settings say to try nightly).

I waited several weeks before I decided a successful update may not be coming anytime soon. My phone version was out of support with Microsoft so they were under no obligation to correct the issue. I had no idea when the next update would come, or if it would resolve the issue; there were no guarantees the next update would not have similar issues.

The platform I was targeting was now unstable and I was forced to reconsider the approach I was taking. Without a stable platform there was no guarantee that the limited customer base that existed would still be there if I got up and running again and managed to finish my game in reasonable time.

I had a difficult choice to make. I was weighing up years of lost learning opportunities through developing the engine myself to move forward on an existing game engine that target a set of devices I didn’t own. While it took some soul searching the way forward was inconvenient yet obvious; I had to change platforms sooner than anticipated and target the Apple and/or Android market.

The event was literally a game changer.

Not a Total Loss

As sad as it was, the change did not mean I had wasted a year of development. Let’s look again at the list of things I wanted to achieve:

• Practicing and developing the skills I felt were missing in my current skillset (personal skills growth) - Success
  I learned a great deal about .NET Garbage Collection, memory management, object pooling, and using arrays in anger. My most recent refactor of the game engine (which was incomplete at the time where “the event” happened), was further proof to myself that I had an excellent handle on solution architecture and that I knew how to make the choices that would benefit working with and extending the engine.
• Keeping sane at work (not trying to force personal development into my day job as it just wasn’t happening) - Success
  I was a lot happier at work as I was no longer frustrated that opportunities to learn in areas I felt I was lacking never came. I was managing that progress on my own time, and at work I could focus on doing work to the best of my ability and having more fun.
• Getting years of game routines out of my head and into reality (overcoming impostor syndrome) - Success
  Routines such as tile maps, sprite batching, user input without compromising architecture, were amazingly cathartic to get out of my head and seeing in real life. The most enjoyable of all though was writing my own collision detection in pure geometry, not only because maths is awesome but because I love explore areas of mathematics I have never seen before. I had expanded my horizons and in doing so blew away any reason to call myself an impostor.
• Expanding my knowledge of game development terminology and practices (setting myself up for future game projects) - Success
  Because I worked as close to the metal as my framework choice allowed without fighting the language framework, I was exposed to the gnarly detail of the areas of game development I felt I needed. When I saw people using existing game engines such as Unity and Unreal and had glimpses of how they were structured, it confirmed to me I was doing things right and learning all the right things.
• Finding other game developers locally and on the web that I could talk to (establishing a new social network) - Success
  I could never have come this far if I were truly alone. While it’s been a disappointing year for socialising with local indie devs, I’ve developed relationships both in my own country and beyond. Though these relationships are new, they give me confidence that I belong among such a group of inspirational and talented people who understand what I’m going through and can support me when I’m feeling down.

The Do-Over

Overall my effort over the previous year has born substantial fruit and despite my sadness at the passing of an old friend (Windows Phone as a development platform) it can only be called a success. I now have a new direction to move in with purpose, with the benefit of it being a more densely populated market of people to potentially see my wares.

Given I no longer need to write a game engine myself, I anticipate my game will evolve more rapidly as I am liberated to focus solely on that. This should go a long way to making me feel a lot closer to the cadence at which other indie devs work, despite still only having two half-hour sprints a day available to devote. I’m hoping more rapid progress will translate into more rapid sharing of screenshots etc, and in doing so any self doubt about being an impostor will be much more infrequent.

I’ve been given a second chance to do things right so it’s important I reflect on the journey so far, reinforce what I’ve learned to myself and to consider how to be more effective this time around. The most obvious place to improve is where I have been feeling the most angst; socialising my work.

Doing it Better

Through my effort with social media so far I have discovered which channels are good for different sizes of communication and the frequency that works best on them. Where I have been previously frustrated by my inability to devote time and been blocked because I hadn’t established a channel, I now have a better understanding on how to do it better this time.

This means:

Twitter

This channel will be used to report up to the minute stuff without context, because the frequent flow of tweets itself creates the context which readers can follow (pun unintended). It should also be used to participate in community groups such as #screenshotsaturday.

I will continue to use #zodproj to flag my game tweets and aim to post more often and only with up-to-date information.

Game Blog

Now that I have created a space to blog I will use it more frequently. I’ve learned that while it is a good channel when you have more words than can be squeezed into a single tweet, it takes far too long to write posts if you leave it too long.

Just as frequent releases of software makes deploying releases easier, I’m believe more frequent posts will make blogging easier. Perhaps whenever I pass a major milestone in my development, or perhaps when I’ve passed a few minor ones, I’ll do a quick post so they don’t take too long to write. I’m looking for a sweet spot between creating my game and blogging about it.

I hope that now I’ll be using a pre-built, rich featured game engine I can focus on building the game itself, which will create a more satisfying timeline of progress and I won’t feel guilty about taking my limited time away to work on blog posts.

Final thoughts

Because of the limited time I have available it’s taken me two weeks of actual time going by to create this post. In that time I have purchased, received, and set up a new Android phone, been researching game engines for suitability to my development practices, and started learning about one in particular in more detail.

I can see I’ve got a long road of discovery ahead before I get back to being as productive as I was, but I believe this effort will rapidly increase the speed at which I deliver and I will be more creative as a result.

I look forward to posting more frequent updates in the future.