Archive

DevBlog

Well this last month didn’t go quite the way I’d hoped! In the greater scope of the game, I’m basically now exactly where I was a month ago: The intro isn’t done, I still need to do it, and once I have it done I’ll start in on the core character animations and first chapter of the game.

Dang.

The first thing that didn’t go according to plan is that, rather than deferring polish and improvements to the shader until later, I went super hard on trying to get it working correctly now. Towards that end I spent a couple of solid weeks studying the construction of a custom render pipeline (working from this tutorial), which was tremendously educational – not just in terms of learning how to make a rendering pipeline, should I need to do so in the future, but in learning approximately how the current default settings operate and what it takes to make shadows and other effects work. In the end, I only directly applied a very narrow slice of this knowledge, but I was able to combine it with the understanding gleaned from several weeks of already tackling with shaders to finally achieve the effect I wanted

The differences between this and the screenshots I posted last week are subtle but important. The ‘fuzziness’ of the sprite edges is preserved, which is vital for this art style, it can support semitransparent sprites, and shadow casting still functions – with, overall, fairly good performance.

Other than the first week or two spend studying and perfecting the sprite shader, all of my time has been taken up by the illustrations – sort of. I’ve been finding it difficult to actually work on these illustrations, so much of the actual time has been taken up by brainstorming, hesitating, procrastinating, and getting angry at myself.

There’s a few reasons why this has been happening. My approach to work is usually to start with one thing that needs fixing or improving, and to focus entirely on that – usually, by the time I finish that I’ll have noted several other things that need to be worked on, and I’ll just keep moving on to those, one after another, until I run out of time or energy. This approach, however, doesn’t really translate to this sort of illustration work – first, I need to know where I’m going, so I spend a considerable amount of time thinking about what these illustrations would look like, what they would convey, and how they would ultimately be presented. Until I have a decent idea of that, it’s difficult to even start – but even when I know basically what the illustration is intended to be, it’s difficult for me to pick a particular point to start on. Don’t get me wrong, writing and programming aren’t trivial challenges, but the hardest for me is the vast possibility space of visual art, a space where there’s no sensation of time, where everything is simultaneous and there’s no inherent directional line.

Eventually, though, I start: And it feels good. Once I’m into it, I can improvise little visual ideas and flourishes as they come to me and slowly work to hone a visual narrative. Yet every time I begin the next day the struggle starts anew…

Also I changed the concept for the intro from 3 illustrations to 9, or 3 sets of 3. So that’s been slowing things down as well.

The most intimidating among these is one which I realized would work best if it depicted one of the areas later in the game – an area which I was not entirely sure what it looked like, certainly not enough to create an illustration. I did begin (but have never completed) a concept art of the area several years ago, and I’ve been able to work over that rough idea to create a more solid and polished version for the illustration – but, again, each time the sheer amount of precision and detail that goes into drawing something like this, not only a detailed building but a potentially extremely complex one, is intimidating – and every day it’s difficult to begin, though usually fun once I get started.

So, then, what are my current ambitions? What do I want to have done by this week, this month?

This illustration will probably take several more days of work, and the subsequent less complex illustrations will probably take a few more days. I think by the end of next week I can have these done, and can begin the timeline scripting for the intro – which will itself be very simple, and probably just a day of work. Once those are done the intro should hypothetically be basically complete and I will export a version of it and post it here for the next DevBlog… but I don’t want to get too ahead of myself, because I may need to rearrange the intro music or create other assets to smooth things out once I see how it works in practice. Nevertheless, I hope to have it done within at most two weeks. After that, as mentioned before, I’ll be tackling character animations and the first area of act 1 – as well as, perhaps, a simple menu system which I can later expand and polish to be the final menu, but will in the short term just give me a way to skip the intro I’ve made and go to whichever level I’m currently working on.

If you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

We’re at the end of the first official month of development of the current version of EverEnding. That’s a lot of qualifiers, but it’s still a milestone of sorts. Did it go well, you may ask? Did it go poorly? Kind of in-between!

Most of this month was focused on creating the intro sequence, but before I even started in on that I first wrapped up what I was working on at the end of last month, the crouching animation, even though it really doesn’t need to be done until I start on the first chapter of the game.

Once I have my teeth in a problem, I really don’t like to abandon it until I’ve solved it – a tendency which kind of backfired later on. However, having accomplished that, I started developing the different graphical elements of the intro area, making a dynamic and playable version of the first test screen which was previously just a placed static image. Here’s a comparison of what it looked like before and what it looks like now:

I started with the tree, which I’ve always liked the look of but which was cut off at the edges on this screen since I’d originally drawn it on a paper pad and ran out of space. I extended the top of the tree and added layered systems of branches, then drew several different leaf clumps which I spawn in-game using a particle system. It turns out most of these leaves aren’t actually visible from the main intro area, but I think I’ll probably pan the camera down to this area at the beginning, which will show off the leaves and branches nicely. There’s some aspects I still like better in the old version, such as the overall level of saturation and contrast on the tree and the gradient in the sky background, which I’ll probably try to bring back in as I develop these assets further.

I quickly drew the night sky background, which was mostly scribbling, and somewhat less quickly I constructed fill and edge textures for the dirt, and then built the terrain using Unity’s Spriteshape tool. I had been concerned about the quality of effect this tool would provide, but I honestly couldn’t be happier with how the ground segments turned out. A point of interest is that SpriteShape used carelessly can make the edges of the collision area misleading, so I tried to make it clear via shading what the actual collision edge of the ground surface was.

Previously the main ground area had been grassy, but I figured with the special grass particle effect I developed a short while back I might be better served by leaving it as dirt and then having the grass effect handle all the grass rendering. I may reconsider this at a later date – and the grass effect itself is surely still subject to change – but the dirt ground asset will be useful later regardless. I haven’t created any rocks to replace those in the initial version – they’re not vitally important, but I probably should, especially since I’m certain to need rock elements to place later anyway.

Probably the most time this month was spent wrestling with the rendering system. While the initial simple sprite look was appealing, I couldn’t and can’t stop thinking about how incredible it could look with some extra post-processing and shadowing effects. By copying a shader I didn’t understand well I could get these effects but only at the cost of clipping away the transparency at the edge of the sprites in a fairly hideous way, and one which will cause much more severe problems as I add more assets with transparency effects later on. I still haven’t figured out a perfect solution to this, and it’s a rabbit hole I could get in deep – after all, people build entire careers specializing in this sort of graphics programming – but I’ll probably keep pursuing it both because I think the results could be worth it and because I find this kind of work inherently interesting.

The crux of the issue is that in order to properly post-process an image with certain effects, you need to draw to the ‘depth texture’. In order to make objects draw one in front of another, you need to draw to the ‘depth/z buffer’, which it turns out is a completely different thing… And, in order to draw transparent objects, one would normally avoid drawing to either the depth texture or the z buffer, because it would overwrite information about objects behind the transparent object which you still want to draw because your object is transparent! In layman’s terms: In order to know what something should look like, the game needs to know how far away it is, but it can only know the distance of one thing at a time, so: If we’re holding a piece of semitransparent glass in front of an apple, how far away is the thing it should be drawing? Is it the distance from the glass to the camera, or is it the distance from the apple to the camera?

The only solution that seems viable to me is to set a transparency threshold: If it’s barely transparent at all, like a piece of stretched rubber, then it counts for depth, and if it’s very transparent indeed, like glass, then it doesn’t. However, just knowing this as an algorithm isn’t enough, because you still need to know how to explain to the graphics hardware what behavior you want – and that’s what I’ve been struggling with, because it has very particular ideas about what information you can feed it and how.

I’m not sure how well this problem is coming across in text, so hopefully next month I can just show you a picture of the working version to illustrate what I mean.

I also started getting sound and music implemented. Now, the intro’s sound and music needs are pretty minimal, basically just requiring one music track and one long sound effect to be played, but I started seriously considering what the music system would need to look like to handle future problems. Even in the very first playable area there’s some degree of adaptive music, and later areas have other types of dynamic music planned, from transitional segments to cross-fading alternate tracks and more as I think of them. Altogether, these represent a not-insignificant programming task – and, in Unity, requires some rather awkward queuing and loading of audio tracks. I decided that it was foolish to try to create a music system like this when there’s already incredibly powerful tools made for this specific purpose out there, so, after a quick assessment of its licensing options, I began integrating FMOD, an adaptive music system for games, into the project. This system is free for small-scale projects like this, and in addition to adaptive music provides great tools for mixing sound effects together and slight dynamic tweaking of sound parameters based on arbitrary values – so, for instance, one can not merely adapt music by creating alternate tracks, but also by bumping equalizer and filter parameters based on in-game actions. FMOD also provides an actual tool for visualizing these mixes and setting up musical transitions, which is great because manually plugging values into an XML script on my first attempt at this was a real drag.

Finally, I started considering how text was going to work. This seems like it should be a freebie – there’s some pretty standardized ways of handling text in games at this point – but, for this project, I want a sort of living storybook feel, with text appearing on the page as you encounter it. First, I needed to figure out how to just get text on the screen, which ended up being fairly easy since Unity includes TextMeshPro, a great solution for solving exactly this problem in 2d and 3d spaces. However, when text is on a background that could be any color, just black print doesn’t really cut it, so I spent quite a while looking through different fonts and rendering styles until I found a couple that worked for the two main ‘voices’ I need to have at the start of the game – though I’m still undecided whether these parts will also have voice acting.

After this I created a simple class to fade in the text over time – and then worried it should have been even simpler, since for some unfathomable reason I made it so text faded in over a set total amount of time instead of at a predictable rate, meaning it would be nearly impossible to sync up between fields of different length. As soon as I started thinking about all this, though, I started thinking about the way it should be, about what the optimal interface and feature set ought to be for a tool like this. This is a trap! This exact behavior is why I was talking in the last devblog about trying to treat this project as a series of game-jam-esque sprints, and why I said my tendency to fixate on problems once I approach them causes issues: Because this is the sort of thing you don’t do in a game jam. Not only is this a far more refined solution than is immediately needed, but trying to create it pushed me into writing code for Unity’s internal UI system again which is an invariably soul-crushing practice since getting anything done in there is such a finicky and arbitrary mess. I realized all this after a couple of days, and left this text fading in a state where it’s not quite as perfect as I would want it to be if I were selling it as a product – but is still quite sufficient for my immediate needs.

One could reasonably ask: Why focus on creating an introduction before completing any playable areas? I will preface the explanation by saying that I don’t believe this is the correct approach, and might in fact argue that it’s a very incorrect approach. Generally speaking, I would prefer to start with the core gameplay, build up playable areas, and expand out from there. However, right now I’ve already essentially created a gameplay prototype with the initial AIR version of the game: I don’t know if the gameplay is going to work on the macro level, IE will engagements with enemies be interesting and will the overall flow of play be interesting, but the prototype gameplay has been enough to convince me that the simple act of moving around the world will be satisfying. In addition to these basic gameplay systems, though, there are narrative systems – which are usually considered as an afterthought, but which also need to be developed and tested. Developing the intro will a) create a distinct chunk of the game, albeit a relatively unimportant one, b) force me to create the structure of the narrative systems, and c) create a free-standing piece that should hopefully build enthusiasm for the project – both for myself and for potential audiences.

Because I got so focused on trying to get specific tasks completed correctly, instead of merely functionally, I didn’t reach my original goal of completing the intro by the beginning of this month – but I don’t think I’m actually that far off. I had originally conceived of this beginning bit as being largely just text, but with a bit of reflection I’ve realized that would be an incredibly boring and tedious start to the game, so I now have a sequence planned where the camera slowly pans down to the intro screen, across text displays, and with cuts to certain illustrations I have yet to make. This is conceptually still pretty simple – and honestly probably doesn’t sound very exciting, described in this bare-bones manner – but should be more exciting and intriguing than just a few lines of suggestive dialogue, and I think with a deft touch could be really cool. The current intro music is almost 2 minutes long, which I’m starting to suspect may be too long to actually fit this sequence without messing up the timing – so I may also need to rewrite it to accommodate this.

Thus, to complete the intro, I need to make 3 illustrations and a couple more minor pieces of art, possibly tweak some assets, animate the camera transitions and text fade ins, add some sound effects, and then edit the music track to fit. I think all this is achievable within one week. Once this is complete I’ll start in on the first area – which, at first, will mostly be animation work while I complete and implement all of the standard character animations.

In all honesty, my mood has been all over the place recently – for obvious reasons. It’s nice to have something concrete to work on, like a ship in a bottle, while being otherwise locked in place.

If you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

Where We Were

A little bit more than a year ago – actually, almost a year and a half ago – I decided to put EverEnding on hiatus in favor of working on a series of monthly projects. This worked out for a while, but before too long I was having a harder and harder time building anything significant up by the end of the month, a harder and harder time staying motivated when it seemed like I just kept finding new ways to not make anything substantial. I quietly dropped the monthly project component of the Patreon shortly after completing the album last year – I figured it was better to not promise than to be unable to deliver.

I quietly picked EverEnding back up and started working on it around six months ago, but this time rebuilding the project in Unity. I resisted this change for a long time, mostly because when I started this project Unity’s support for 2d graphics and flexibility seemed to be insufficient for what I had in mind, seemed to present obstacles that I would struggle with and be distracted from the main work of completing the project. This was, in retrospect, the wrong choice – though I certainly would have had to struggle with Unity, the fact was I had to struggle with Flash/AIR a lot too, probably a lot more, and for less impressive results.

I’m not sure why I felt so strongly about these bad decisions, why I didn’t take a week long ago to explore what I could do in Unity and how it would compare to what I was doing already. Perhaps it was fear of having wasted my time – the result of which being, naturally, that I’ve wasted far more time. The fact is, though, that the Flash/AIR version was never what I wanted the game to be. Even before making significant progress, I had dreams of an HD version that used sprites much nicer than the inept pixel art I was forced into due to the limitations of Flash/AIR – or perhaps the limitations of my understanding, but limitations in either case.

So it’s happened. I’m remaking the game, redoing massive amounts of work, throwing away even more. It’s somewhat upsetting. It still feels like I’m stuck in slow motion, and that the shape of the project barely changes from week to week because there’s still so much work to do, but there’s one crucial difference: The game that is getting made now actually looks like what I imagined when I envisioned it.

I also walked away from the monthly project experience knowing that, though I may struggle much of the time, I can sometimes create substantial works within a month-long window. While I’d always broken the game up into chapters, I’m now considering each chapter to be a month-long (or, in some cases, 2-month or 3-month-long) project – eventually. Right now I’m still working on getting basic functionality and character animations into place, working on constructing a foundation to build off of.

If I were a stranger reading what I was writing now, I’d be rolling my eyes a bit. Of course – this time it will be different! It won’t be like last time I said I had a plan, last time I said I had deadlines to hit and last time I said I would work to have chapter 1 finished by the end of the year. I can’t help but notice, putting together the samples for this post, the long line of old samples, old components and demos, stretching all the way back to 2012 when I started it. Almost 8 years ago, now, that I’ve been working on this project. What the fuck? There’s clearly something wrong with my approach. Each year passes and I get no closer, and I repeat myself, and I repeat myself repeating myself. What can I do? How do I know this time will be different? How do I know I’ll do better, get closer, move faster?

I don’t. I can’t. I’m just doing my best, trying different angles, testing approaches, seeing what works, and hopefully getting a bit better every time. I want to finish this project – not merely to have it done, but also to feel okay about moving on to other projects. The only way to do that is to move forward, one step at a time.

Where We Are

Rather than dwell on all the things I haven’t done, or the things I’ve done incompletely or still need to do, let’s talk about some of the things I’ve done since I restarted the project. I’ve been focusing on getting foundations and special effects done so I don’t have to worry about them later: Foundations I’ve completed include collision, which I had to basically redo from the ground up because Unity’s default colliders weren’t suitable and I was no longer working off of the tile system that a lot of the old collision system was premised on, player movement which I could mostly copy from the previous project with minor tweaks, and the camera system which I was able to quickly use Unity’s Cinemachine package to make a decent version of.

Additionally, and this was the most significant challenge, I found Unity’s default animation tool MecAnim to be unsuitable for 2d animations, since the tools that provide smooth transition between different 3d animations were useless and the transitions didn’t provide a lot of the tools I was used to having from my custom animation tools from the earlier version of the project – so I built a new animation system. That is to say, I built a new system on top of Unity’s system to handle the conditional logic for playing 2d animations. The difficult part of this was learning how to modify editor windows in Unity, which uses a completely different paradigm than I was used to from working in Flash and which I had to learn a more complicated approach to than most available sample projects online use. There’s still some bugs in this tool, and probably a few features to be added, but once I complete it I will probably add it to the Unity asset store, since I expect it to be useful to others as well – though I’m not really sure yet how to make it discoverable to those who might make use of it.

These are all things that needed to be done before any significant progress in developing the game can happen. In addition, I’m still working on creating the fundamental movement animation set – those animations which will let me see the character move around in the environment and play-test in a somewhat finished way. These probably don’t technically need to be done before I can start building out the in-game environments, but if I want to pursue this series-of-vertical-slices approach to building the game they are an obvious starting point.

In addition, I’ve built a couple of special effects that are probably going to feature heavily in the project, especially early on. I’ve created a particle effect for grass blowing in the wind and a special set of shaders for a 2d water effect that will be necessary for developing the first areas of the game (examples of both of these are viewable if you click the preceding text).

Where We’re Going

In the immediate future, for the first vertical slice, I’ll need to:

  1. Player Animations:

    1. Crouching left/right
    2. Standing left/right
    3. Stopping (after run) left/right
    4. Turning left/right
    5. Rolling left/right (maybe)
  2. Version of the first area (visible in the screenshot at the top of this post) that’s not a single background image and actually contains multiple elements that can move independently of one another.

  3. Chop up the tree component and rig the branches up as kinematic springs, so that they can sway to breeze or other movement

  4. Particle effect for the surrounding chunks of stone during the intro

  5. Sound Effects:

    1. Grass footsteps

    2. Grass landing/jump

    3. Earthquake

  6. Basic menu system

    1. Volume settings music/sound
    1. Rendering settings template

    2. Control rebinding placeholder

    3. Quit game

  7. Simple music playback behavior

  8. System for displaying timed text during the intro

  9. Intro text

  10. Record VO to accompany text (maybe?)

I was going to follow this up by including a breakdown of what’s necessary for the next vertical slice of the game, being approximately 1/3rd of the first chapters of the game, but it ended up being far too much information to conveniently include here. Suffice to say the second of these vertical slices is going to be the real obstacle, and is probably best approached as a three-month project in itself – and even that’s optimistic. That being said, it’s probably the biggest hurdle and the single biggest component of the project, so future vertical slices should go faster if I can get it done. I may end up attempting to vertically slice this vertical slice to try to get it down to one or two months.

In the meanwhile, I’m going to be trying to get this list complete by the end of the month, and hope it all adds up to something close to what I’m imagining. I haven’t decided yet if I’ll release these as playable builds to patrons or just make gameplay videos or perhaps some staggered deployment of both – still considering how to actually put this project out into the world. This is all daunting to keep in mind, but I’ve at least caught the tail of what I’m trying to achieve.

If you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

For the past month, I’ve been working on my entry to the Idle Thumbs community game jam, Wizard Jam X. This is the final Wizard Jam, due to the Idle Thumbs podcast going into a long-term hiatus from which it may never awake. I really wanted to make something special for this one. I think I achieved about half of what I’d hoped to do, but I am reasonably satisfied with the result.

Without further context or explanation, I present Eight Seconds: Manipulated Through Time.

The concept of Wizard Jam is to take the title of one of the Idle Thumbs podcasts – or one of their several associated podcasts – and to make a game with the same title, which may or may not have anything whatsoever to do with its source material. Later Wizard Jams have diverged from this formula somewhat in order to keep things fresh, but I’ve always been a fan of this approach so I stuck with it. In this case, I chose the title “Manipulated Through Time”. I always find it interesting imagining to what degree we might be capable of representing time travel in video games – We have tremendous control of allowing the player to revisit everything prior to the current moment in the game, since we can freely record and play back those previous game states – but can we make it possible for them to interact with the future in a meaningful way?

Well, that’s still an interesting idea, but I wasn’t really able to robustly pursue it here because it turns out my hands were quite full with allowing the player to interact with the past – though the idea of these two interactions being equivalent is also presented. It was important to me to make it so the player interacted with that past in a meaningful way – not just as a static recording, but as something more tangible – and, in so doing, that also means that you are directly affecting your future self with the actions you’re taking now.

This is always true, just revealed a bit more explicitly here.

My original concept of the game was that every minute, time would be reversed. For each minute, you would interact with your shadow self, which was doing everything you just did but in reverse, and by so doing you would navigate puzzles and so forth. While thinking about this, I realized that in that first minute, before there was any shadow to interact with, the player would have no idea what was going on – and that even once the idea of the time reflection began to make sense, controlling your inputs precisely, with reversal in mind, for an entire minute would still be nearly impossible. The obvious solution was to shorten this feedback loop to a shorter period of time so it was more feasible to observe the results of your actions. I waffled for a while considering different time values and eventually settled on eight seconds as an appropriate length for the time loop. I also eventually ended up making variants on this time reflection idea – you’d have reflections that reversed the flow of time, or echoes that moved the same temporal direction as you but with an eight-second delay, or reflections that had an echo of their own, and so forth. This undermined the original idea of a time loop where you were interacting with yourself directly, but by the time I got to this point I’d forgotten that was the original idea – and only remembered just now, when describing it here. I included the duration into the title to make it a little bit clearer what was happening (the tutorial for a game can begin with the title!) and also had some slight visual changes with each tick and each “reversal” to add to that clarity.

Because the concept was so innately difficult to wrap one’s brain around, I tried to make the game’s other elements as simple as possible. I had some idea of physics puzzles, of raising platforms with your reflection in order to traverse them, of tossing items to yourself – and, while these aspects are not entirely absent, they’re all done within the incredible simple framework of doors, switches that open doors, and boxes that can go on switches. However, because the player can be duplicated, and because whatever the player is holding when they’re duplicated can also be duplicated, even the simplest of these can become remarkably complex in practice.

What I came to realize over the course of the project is that there’s two somewhat contradictory sets of goals at play: That which builds interesting and thought-provoking puzzles using the mechanics, and that which builds an interesting moment-to-moment experience using the mechanics. These aren’t entirely contradictory of course: The idea of a fraught cooperation with your past selves implies challenges to be surmounted, so developing the theme requires challenge and developing challenge requires use of the theme, but there are points where these impulses push me in opposite directions. For instance, a huge amount of clarity could have been added to the puzzle solving if I locked the camera into a top-down perspective and made the movement turn-based – but this would also reduce the sense of the self being reflected, and reduce your interaction to a player and a pawn rather than a player with an avatar representing that player. In this case, I made the decision to present the game in first-person early on in production before realizing these ramifications – so, in the end, it becomes more of an experience than a proper puzzle game, with most puzzles being solved by fiddling with the scenario until an answer emerges rather than actually being thought through.

When it came to the appearance of the game, I wanted something highly detailed but not necessarily realistic. I was imagining the hyper-detailed surreal scenes of Twin Peaks or the minimalist stop motion of the 1989 Oscar-winning animated short Balance, something that felt very physical and real but without any grounding in the physical limitations of reality. I ended up leaning heavily on a free (deprecated) 3d tileset called Simple Corridors – because it was free and had PBR (Physically Based Rendering) materials, which is a fancy name for including a standard set of rendering textures that approximate the appearance of real materials. I originally planned on having a few separate environments, but since I didn’t have the time or skillset to make this type of asset on my own and didn’t want to break the bank buying professional assets I ended up making every area of the game a variant on the first tutorial zone I created – which, honestly, was probably all for the better, since it added to the thematic idea of being suspended in time.

For the music, I wanted to integrate both reversed and unreversed instruments, and have it be at times unclear which was which – it was also, since timing was such a huge part of the game, an opportunity to convey the eight seconds conceit through another information channel. I could have, and perhaps should have, executed this as a static music track, but instead I created a simple adaptive music system using several separate music stems for each instrument, each being 8 or 16 seconds long and each with an assigned intensity value. Trigger volumes set the music intensity as the player progresses through the level, which randomly plays a random sample of the appropriate intensity at timed intervals – many of which are reversed versions of other samples. The basic idea of this worked really well, creating something that sounded more or less intentional and built over time – but, because Unity’s support for playing arbitrary sound samples is much less robust than it is for creating a dedicated sound emitter, I had a number of issues with controlling these sounds, from slight desyncs caused by frame timing to large variations created by the game being paused for the settings menu. Also, as I built the musical components out more the administrative overhead of managing even this relatively simple song structure became significant. It was a worthwhile experience, but I’ll likely try to integrate one of the existing middlewares for adaptive music next time I want to do something like this, just to have a proper editor at my disposal. All in all, I’m pleased but not entirely satisfied with how the musical component turned out – it sounds interesting some of the time, and seldom degrades into true cacophony, but it does sound like a slipshod implementation of the idea it represents – which it is. I decided that sound effects would just detract from the surreal experience, though, and didn’t bother with them.

Other technical difficulties emerged through the time reversal system itself, which should be a surprise to no one. Recording and playing back a character’s history is fairly trivial, but recording and playing back a history in a way that still acts on the world, and that can be acted on, is a more significant challenge. All values must be relative instead of absolute – and movement values must be relative both to the world and to the facing of the character. Partway through the project I decided to vary the levels by mirroring them and scaling them, and I hadn’t considered earlier on what effects this might have on game entities which existed within these worlds. The reflection of the player was modified by the transformation of the world it was placed in, which is thematically interesting but absolutely not my desired result. Suddenly whenever they were supposed to turn right they’d turn left, entirely because right and left had traded places in the world they were now put in. Other issues came in when I added the ability for the player and the reflections to grab and throw each other, which then created rotational feedback loops where, when the rotation of the character was recorded for the next playback, it would record both the player and the reflection’s rotation summed together. Some of these issues may still exist, though I tried to stomp out as many as I could – but even aside from the technical challenge of implementing a solution, figuring out what a solution even ought to look like was frequently a non-trivial design challenge. What does it mean to pick up or drop an item in reverse, and what effect should these actions have on the world? What degree of physical interaction between the player and their reflection enabled interesting outcomes, and what was unfeasible to implement? What was likely to break the game? I had to answer each of these, and though I ended up approaching most of these conservatively it was still an unpredictable game and prone to weird breaks which I had to take a few extra days to debug.

I’m happy with how the project turned out, but I don’t think my methodology was very good. I dropped everything to work on this, and I think the end result of that was unhealthier work habits and hours, a lack of focus, and a bunch of extra stress I probably didn’t need to deal with. Though this is the last Wizard Jam (for now?), I will likely participate in some other game jams in the future – and these tough lessons are ones I think I’d better keep in mind when I do.

If you enjoyed this project, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

Habits are helpful. Habit is a place to nail down the flapping edges of your behavior, to train consistency in yourself. But as with all points of stability, every habit rests on something else, and those things can be shaken loose. A home, a person, a job, any one of these may seem rock-solid only to roll away, and that’s when habits tend to slip. I’ve been letting habits I’m really quite fond of slip mostly from being distracted, by projects, novelties, and significant life changes both good and bad. I haven’t been writing blog posts – I’m going to be trying to do better on that score, since I think it’s good for my brain to get those thoughts out there and these posts are also the most consistent creative work I’ve produced in my life.

But okay, what about last month’s monthly project? By which I mean the month before last’s monthly project, which then expanded to become a 2-month project? It has, I guess, now further expanded to become a ?-month project.

I should probably talk a bit about what the project is before talking about how it went/is going. I decided going in that it was going to be a 2d platformer, and that for the first time I was going to seek out collaborators instead of trying to go it alone. With input from other people interested in the project it shifted into a 2d stealth platformer with some environmental interaction – think of, perhaps, a cross between the N series of games and Spelunky. Many of these elements are still, ah, a little rough around the edges, but I think the idea still has a lot of merit.

It was and is going well, but I got kind of burned out working on it — part of the idea behind these one-month projects in the first place was that they would be projects I could work full-force on and then complete and put down right around the time my enthusiasm might start to wane. This is the first such project I’ve tried to work with other people on, and I wasn’t prepared either for how that would affect this dynamic or for how busy I would be during that time period. Everyone has their own way of working, and on a freeware-type project like this everyone has a dramatically different scope of time they can bring to bear on the work.

So, right now, I don’t see any reason to rush this project to completion. I’ll be taking the next month or two to work on other monthly projects, while picking away at the most urgent tasks on the platformer as they become necessary, and then revisit the project in a couple of months to try to wrap things up.

In the meanwhile, for this month’s project I’m going to work on creating a vector drawing tool for Unity. This is something I came up against while I was building the lighting system for the 2d platformer project: Unity has very few tools for vector drawing, and those that exist are either no longer supported or aren’t very good yet. I’d like to take this opportunity to try to create a tool for creating vector graphics based off of the Flash graphics class. I’m not sure how far I want to take that approach, how full-featured it will be or what other capabilities it will encompass, but I at least have Flash (and OpenFL, the open source Flash-inspired game dev tool) to refer to for ideas and inspiration. Next month I’ll probably return to EverEnding… sort of! I’m going to try to basically port all the work I’ve done on the project into Unity and see if I can effectively use that to streamline and improve the quality of the work. It’s mostly a feasibility study/experiment. Either way, hopefully having this vector tool available will help in that process as well!

Eh well the December project didn’t really go anywhere. I can at least put some screenshots of how far I got before I decided I’d kind of messed up:

I spent a week or two planning this building layout, figuring out Pro Builder (a tool for constructing 3d objects within Unity), and picking up the basics of other tools, such as Unity’s terrain system. In the end, I was… dissatisfied. I felt like I had just the very edges of what could be an interesting environment, but Pro Builder was becoming increasingly unfriendly the more I worked on it, and small issues with the geometry got harder and harder to fix – leaving me unable to make important changes, such as adding more windows.

I then decided that I needed to be able to work on this in a more full-featured 3d environment. I don’t know whether this was a good or a bad decision, but it was definitely the beginning of the end for this project. Originally, I’d hoped to just export the model from Pro Builder into Blender, a free and very full-featured 3d editing software. Unfortunately, all of the work I’d done in texturing and detailing the environment in Pro Builder came to work against me, with every separately textured subsurface of the object exporting as a separate element. I’d hoped to just drop my old work into Blender and immediately start work again, but this proved to be unfeasible. Over the next few days I studied the basics of Blender, and I began to reconstruct the building – but it is, after all, very difficult to be enthusiastic about doing the same work twice, and my capacity for enthusiasm is inconsistent at the best of times.

At this point we were pretty close to Christmas anyway, and my attention went away from getting game work done and towards all of the preparations that came with that. After Christmas I was mostly focused on cleaning and thinking about what the next year is going to look like. I’m still thinking a lot about those things, but it’s time to start a new project…

Well, close to it anyway! I’m actually not quite done with holiday stuff, and will be traveling for the next several days. Once that’s past I’ll have all month free, and hopefully by the time I get back home I’ll have a solid idea of what I want to work on. I do have a general plan of approach, though, for what I want the next several projects to be, based on the skills I want to pick up and practice:

January: Wizard Jam. The Idle Thumbs community runs a semiannual game jam where people spend a couple of weeks making a game, usually based on the title of one of the podcasts. This community has been a great source of support for me over the last couple of years, and though I’ve participated in the Jam a couple of times I’d like to put some work into something I can really be proud of this time. I’d also like to collaborate with at least one other person.

February: 2d Platformer. I would like to spend a month putting together a simple but complete 2d platformer. The purpose of this is twofold: First, to create a game simple enough that I can focus on creating content for it, and second to gain an understanding of how 2d works in Unity. The latter is important because it’s going to determine if, when I return to work on EverEnding, I continue that project in Flash or reimplement it in Unity. Probably the former, but I want to be open to the latter.

March: Album. I miss writing music, and though these other projects will probably provide opportunity to do so I’d really like to make it the focus of my efforts for a while. There’s a slight chance I might swap this one to February, since I’d prefer to dedicate fewer days to it and more to the 2d game, all else being equal.

April: EverEnding, Chapter 1, Part 1. I think if I really focus for a month, I can create the introductory areas of EverEnding to a degree that is, if not finished quality, at least close enough that I can finish most of the rest of the game before I take another quality pass. If I hit this milestone, I’ll start regularly setting up work months like this. I really don’t want to abandon this project! But I don’t want to be okay with it taking forever either.

All in all, it’s hard to be upset with how this month went. I’m disappointed that the project didn’t turn into anything, but I’m hoping I can keep up the momentum I started in learning these 3d tools, which have generally been a weakness of mine for a long time. I learned a bit more about the danger of trying to do things the ‘right way’ as well – this has been a vulnerability of mine for a long time, of feeling bound to execute whatever I feel to be the ‘proper’ way of doing something. The proper approach, though, is the one that creates a game, and so far that seems to elude me.

Hopefully, in a month, this space will describe my new Wizard Jam game – or games? Until then, hopefully I can also manage to keep up on Problem Machine blog posts a little bit better than I’ve been managing the last couple of weeks.

The first of what will hopefully be many monthly projects is complete! This ended up being a little bit more along the lines of a prototype than a complete game, but I expect that most of them will – and it’s still quite playable for what it is, I think. Click this text or the above picture to download the game.

I learned a lot about how Unity works doing this. Starting from the incredibly basic Roll-A-Ball tutorial provided by the Unity team, I added a jump (which didn’t make it into the release version, but which I am quite pleased with nevertheless – if I end up creating a more complete and sellable version of the game it may find its way back in), then added an advanced camera and gravity beam. Most of the development time went into implementing and tweaking these effects, and I’m very pleased with the overall feel of it now, though certain aspects, such as the simple “X” beam cursor and the occasionally clumsy camera, could use improvement. The game is unfortunately still rather unoptimized – I’m unused to 3d optimization in general, and also more specifically unused to optimization in Unity, and also most of the few things I do know about optimization have to do with ensuring that the game doesn’t render things the player doesn’t need to see – which, in this game, is honestly not very many things, since movement speed can be so fast and can change very quickly the player really needs to be aware of where all the platforms are at all times. That’s one reason I wanted to make the player character reflective, so that you have some idea what’s around you even if you’re not looking in that direction. Unfortunately, because the character is reflective that means even the parts of the level you’re not looking at need to be rendered, so it really does affect the performance.

So, what did I learn from this project? What went right and what went wrong? About halfway through, I was imagining a game with approximately the same gameplay but set inside a giant office or other mundane room. This would have been difficult to do, because I have very little experience creating a realistic 3d space, so eventually I decided to make a more abstract “cyberspace” world. This helped me create a simple level quickly, since I could really just throw together whatever geometry seemed interesting without any concern as to creating textures or ensuring everything was to scale, and also allowed me to create a very open space where the player could do almost anything with the gravity beams. I knew early on that I wanted the player to be a glass sphere which shattered on hard impacts, partially inspired by Marble Madness. It took me quite a while to figure out how to create the shattering effect – I eventually found code to create something along the lines of what I needed, but had to modify it slightly but significantly to suit my purposes. I’m pleased with the final shattering effect, though it sometimes renders in ways I don’t expect.

I tend to think of music creation as coming fairly quickly and easily to me, but it was actually difficult under the time pressure of the last few days of the project. While I like the track I came up with well enough, it’s shorter and simpler and has less production work than I usually like to put into my musical work. I think it’s well suited to the game though, and I haven’t gotten tired of listening to it yet which is a good sign. The sound effects were mostly pulled from freesound.org, though I modified many of them quite significantly, mostly to make the glass sound a bit more musical when it struck or rolled.

All in all, I’m quite satisfied. It might not be the most ambitious project, it might not have a ton of content, but I do feel it offers something unique and that I have executed it to a reasonable level of quality. I may revisit this project sometime next year and try to develop it into a complete game, which would involve adding a bunch of new levels, leaderboards, and ideally some sort of head-to-head racing mode.

For December, I’d like to try to patch up a weakness of mine: The same way as P1aySpace ZER0 was an opportunity to learn Unity, I would like to take this opportunity to learn to create the kind of realistic 3d space I opted out of making for this project. I’m not sure yet what kind of game I would be setting in that environment, though I have a few ideas — first I want to plan out and construct this space, then I can see how much time I have left, during this very busy month, to build a game into it. Hopefully I will be as pleased with that project as I was with this one.

Oh, before I forget, since this game turned out quite a bit more difficult than I had initially expected it to, here are a few tips:

  1. Use the repulsor beam. Though going fast is fun and satisfying, you will almost certainly destroy yourself if you don’t use the repulsor to slow yourself down sometimes.
  2. Don’t worry if you miss a gate. Until you get down to the last couple of gates, missing one usually sets you on a trajectory to hit another. Every missed platform is an opportunity to swing around and fly in a different direction.
  3. Rapidfire the beam to climb. Once you’re holding yourself close to an edge with the beam it’s usually possible to climb or swing up, but getting there in the first place requires you to pull yourself up with the beam.

Happy rolling!