Every month continues to be weird in new and interesting ways. I have to resign myself to getting less done during December at the best of times, what with all of the distractions of the holidays – this year, there was much less physical activity since travel was obviously not very feasible, but I still felt like I had to take a step back for a week or so and try to relax. I don’t feel very relaxed, and other recent events haven’t helped in that regard, but an attempt was made.

As I posted the last update, I’d just started digging into the idea of a ‘modifier’ sprite – one which used the sprite image to modify background pixels rather than to render an image. I built a working version of this in fairly short order – the version demonstrated last month simply used the sprite as an alpha mask to modify background layers, and while that’s still an option it can also use the luminance of each pixel or modify it by each RGB channel separately.

I’ve been thinking about the concept of RGB channels in general, and while they’re a very useful method for storing color information I do think it’s kind of a restrictive approach. If we regard a color as a vector along three orthogonal axes – which is basically what RGB color is – then we ought to be able to rotate that set of axes to define the color space any way we like. This doesn’t make any difference in terms of what colors can be represented, but it changes how those colors get represented, and what the effects of per-channel operations like the above are. I added a hue rotation slider associated with the per-channel modifier effect, so you can rotate the color channels. The effect is fascinating to watch in action, similar to the prismatic effect on the back of a CD:

Writing this, I’m now realizing under this point-in space conception that the color rotation theoretically ought to be two values along separate axes – but looking into it briefly it seems that there’s a lot of theory about how to map color into space which has demonstrated that it can be done one-dimensionally. I’ll have to research this more later, as it may provide more insight into possible interesting visual effects.

So, with the modifier shader done I had more-or-less finished my checklist of things to do with the project, and I was ready to declare the sprite shaders complete! The thrill of that lasted a few hours before I realized the staggering number of things I still had to do.

First, the question of Unity’s multiple graphics pipelines came up. This is something I hadn’t thought about at all during development, but in addition to the old ‘built-in’ pipeline that Unity has used up until now, there’s also the new ‘universal’ and ‘high-definition’ pipelines they’ve been incrementally rolling out. These are basically a disaster of mixed expectations and misguided priorities, but a lot of developers are interested in using them – and the new pipelines’ approaches to shaders, in particular the bits dealing with lighting, are significantly different. The universal render pipeline, or URP, is not especially well documented, and it took me a couple of weeks to figure out what all I needed to do to get the sprite shaders working in that environment. The high-definition render pipeline, or HDRP, is almost maliciously undocumented and I’m not sure if I’m ever going to bother to get the shaders working in it, though I’ve laid the groundwork for doing so should I choose to.

After that comes the challenge of creating demonstrations of what the shader can do for use in trailers and tutorials. This isn’t inherently especially difficult, and is also rather fun – thinking about what effects are interesting and visually impressive and quickly throwing together demonstrations of how one would achieve them using the tools I’ve made. However, going through the process of building effects for a different scene with different assumptions than the one I’d been working in revealed a number of problems that needed fixing, some of which I’m still trying to figure out, as well as revealing weaknesses and oversights in how I’d implemented certain functionality. The demos themselves are fun at least.

Additionally, looking through competing sprite shaders on the store, it’s clear to me that I need to put some effort into making this more readily usable and into supporting a couple of effects that might be difficult or impossible to implement with the current feature set but would be highly desirable.

Finally, I’m going to need to write documentation on what the different shader properties do and how to use them, record tutorial videos, and cut a trailer demonstrating the capabilities of the shader. This was all stuff I’d intended to have well underway several weeks ago, before I got sidelined by the challenges of Unity’s multiple pipelines.

What I’m realizing now is that this is the closest I’ve gotten to finishing a significant project in a long time. Most projects I can either declare myself done with as soon as they’re satisfactory or keep on scraping away at in perpetuity – and, having set this one as a project I want to properly finish, to finish to a degree of quality where I feel good about charging money for it, has revealed to me that I am exceptionally bad at actually finishing projects. I’ve had to work a long time to get to the point where I feel okay about putting my work out there at all, but having it be technical work, work that can objectively function or malfunction, and having it be work I’d be directly charging money for, all acts like a targeted charge directly into the anxiety centers of my brain.

This has raised a lot of questions in my mind about my long-term work on EverEnding. Is what I’m doing actually a good way to finish a game, or am I setting myself to work on a project for perpetuity, to eternally avoid the pressure of finishing? The work isn’t bad, but someday I’ll need money, and there are other projects I want to work on at some point. The question now is, what can I do differently? The answer may involve trying to get more people involved in the project, but that’s a little tough when you have minimal financial resources.

Anyway, the next couple of weeks at least are probably also going to be working on this shader stuff: Completing the demo effects and making tutorials for recreating them, cutting together a trailer and maybe writing music for it, writing up the documentation, creating a store page, and fixing any more bugs I find along the way. It’s a little bit exhausting and a little bit demoralizing sometimes, but I am proud of this project and what it can do and I’d like to share it.

And I’d also like to make a bit of money for once as well.

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.

This was not the best month for the project so far. As last month ended I was quitting caffeine and consistently having my ass kicked from the fatigue of doing so, and the tail end of that continued into this month. Before long, though, I was able to consistently open my eyes and think about things and sometimes, even, accomplish work. I completed the animations for standing up after a crouch, but then I started worrying about something I’d avoided thinking about for a while: Idle animations.

In most games the player’s character animates a bit even while otherwise not moving. Often this is as simple as a little bit of motion to suggest the character is alive: Slight movements, breathing, shifting weight, a breeze blowing by, and so forth. However, to touch lightly on the narrative of EverEnding, this character is not exactly alive in a human sense, so it feels correct that she would be perfectly still while not moving about for any particular purpose. Just leaving her on a static frame, though, made the animation feel inert and careless compared to the life of her animated movement – and, crucially, the liveliness of the procedural wind and water animations. At the same time, animating a constant breeze in the idle animation doesn’t feel right either, since any animation of reasonably brief length starts to quickly seem canned and unnatural in that context and, also, much of the time the character will be in an indoors environment where such a breeze animation doesn’t make much sense.

The solution I finally able to devise was to create two idle animations: One is the character standing stock still as I’d imagined, except with that frame redrawn several times to preserve the ‘living’ quality of the animation even when the character isn’t moving. The second animation is the same as the first, but with secondary elements like cloth and hair being blown in the wind. I can switch between these two animations based on environmental factors – perhaps even tying it somehow into the existing wind system that is controlling the behavior of the grass.

At this point I got derailed again by a minor family emergency, but once I got back on track I was confronted with a set of new problems: I had my crouching and my standing animations, but there’s also a lot of other crouching animations such as attacking and rolling and it only made sense, I thought, to get all of these in the same file to make transitioning between these and keeping them consistent easier. However, the more I thought about it the more I thought: Wouldn’t that be true for all of the character’s animations? So I embarked on creating one massive animation file to combine all of the character’s movements into. This was, I think, overall a good idea. I’m already finding it much easier to see what new animations need to be done, to see issues between animations and issues with proportions and reference points changing over time, but this also has lead to Problems. First and most obviously, it was just a big pain in the ass getting all of the existing animations laid out together and combined in a way that makes sense. However, that’s the challenge I signed up for – the challenge I didn’t sign up for was that this decision also, for whatever reason, lead me right into the buggiest part of Krita (the program I’ve been using for animation). Frame data which I’d copied over was being saved as a solid white block, and frames which I moved around would have garbage data around the edges I had to manually erase. These problems are still with me, but I’ve gotten better at bypassing them – and, more importantly, catching their effects before they ruin hours of work.

Even aside from the aforementioned difficulties, though, I’ve found the last week to be rough going. It’s unusually difficult for me to start focusing on animation work, and also to maintain that focus for longer than 30 minutes or so. As I get more used to my art setup here it becomes a little bit easier to dip in and out of work – a big advantage of having a pen display is that I can be mostly paying attention to something on my main display but look over and make little changes and improvements as they occur to me – but it’s still far more difficult for me to spend a lot of time and do a lot of solid work than it is when I’m working on programming, or even writing.

Nevertheless, I have made the master animation file, and while I’m still a ways off from creating all of the frames (some 450 or so in total) I have all of the basic motions planned out. There are actually a few character frames not covered here – I’m not sure if I’ll be adding the animations for getting damaged and defeated into this file or making another for them, since it’s harder to create a natural flow – but this is a pretty solid overview of what I need, and it is something of a relief to see them all laid out together, in a fashion that is perhaps a bit overwhelming but is eminently quantifiable.

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.

At the conclusion of last month’s DevBlog, I mentioned I’d be spending a couple of weeks house-sitting, and that I wasn’t sure what sort of work I’d be able to get done during that time but that I hoped to make some progress on the animations for the player character. To put things bluntly, this did not turn out as planned: I was there for a day before the wind-storm that precipitated the calamitous Oregon fire season sprung up, and in the midst of that the power went out and a fire started in the neighboring golf course. I wasn’t sure how big a deal this was, but I didn’t want to be the smoldering skeleton who had regarded it as an insufficiently big deal and the sheriff’s deputy outside was suggesting that folks might want to leave just so that if things did suddenly take a turn for the disastrous the firefighters would have less to worry about.

So I left. It turned out that that particular fire was not, in fact, a big deal, and it was swiftly gotten under control, but by this time there were other fires near where I lived (as well as nearly everywhere else in the state) and it was uncertain how far they would spread. I was a little uncomfortable with the idea both of leaving my entire life behind to the caprices of fire and fate and the idea of spending a lot of time on the road, so I ended up only getting back to the house I was to sit once to let some other people in, friends of the owners, who themselves had had to evacuate from their own home because of the fires.

Even though I was back home with my regular setup, no work was getting done during this time, on account of the apocalyptic toxic smoke just hanging about outside. A sort of impromptu vacation, enforced by act of god. It still helped, a little, and I got some rest, which I imagine is why when I started actually working again I made so much progress so quickly.

Last month I talked about issues with getting the grass effect working, most notably the huge performance cost of manually coloring and rotating each particle representing a clump of grass. I experimented briefly with some ideas of making this process more efficient, but the end conclusion I came to was that, short of creating my own completely new particle system component, there was no real way to fix these issues. There was, however, a solution completely separate from particle systems: I could instead create a shader to warp the grass sprite to create a visual effect of it flowing in wind, and control both that warping effect and the color change effect I created last month using the same texture I was currently using to modify the grass particles.

Here’s what the old effect look like, manually updating the position of each particle:

And here’s what it looked like when I just displaced and recolored pixels for the underlying terrain in the shader with no particles:

This actually looked better than I’d expected it to, but it definitely looked like a computer effect rather than something natural. It really needed the grass clump particles to add variety, irregularity, and a bit of texture and noise. I could just use the same pixel displacement technique to render the grass particles, but what I really wanted was for each particle, each clump of grass, to be blown by the wind – to rotate as a single piece rather than just to have their individual pixels pushed around. I tried to create another effect, where the shader could rotate the texture around its pivot, but quickly ran into issues trying to use that along with the grass sprite sheet – because all of the images were stored as one large texture in memory, displacing them significantly would cause pixels from adjacent images to leak into the edges of the other. This is something I could easily fix if Unity provided any way to get information about where these boundaries lie in shaders – but it doesn’t. Without that, I’d have to manually add a script to any sprite that is stored this way in memory in order to get it to render correctly. I did not want to do this, for various reasons.

However, there’s more than one way to rotate a texture. Rather than rotating the UV coordinates that the texture used for drawing, I could just rotate the vertices of the quad that was being rendered. Now, in addition to an effect that displaces pixels, I have added an effect that displaces vertices – which is relatively narrow in its applications, but great for, say, rotating a bunch of particles in a performant fashion. Putting it all together, we get the finished grass effect:

The other big issue I ran into creating these effects is that, though things like transformation and color changes make the most sense when performed using a matrix, as these sorts of transformations are what matrices are all about, matrices are actually not very easy to use inside Unity shaders. The reason is, as it turns out, that Unity simply doesn’t bother to serialize or save any information regarding matrices in the materials of objects, so they always reset to their default values whenever the game updates. This seems like an oversight to me, but regardless of the reasons it makes matrix values a nightmare to work with. In the end, I bypassed this by just saving the matrices as a set of 4 vectors and then combining them together later to perform the necessary operations.

Most of this was basically over the course of one incredibly intense week, with a second slightly less intense week to fix bugs and create nice interfaces for all these new features. By the end of this I’d started to get extremely tired, and decided that I really needed a little break from programming, and that this would be a good time to get to that animation work I’d been wanting to do before. I also decided this would be a good week to try quitting caffeine to see how it affected my sleep patterns. These two goals were not entirely compatible. I got some animation work done, but it was mostly just an hour or two here and there – nothing even really ready to show here. I’ve still got a headache from the lack of caffeine, and I have no idea how to start my day absent the ritual of a nice coffee or tea, but it’s in the name of experimentation I suppose. If I can fix my sleep issues without making it impossible to wake up in the morning that would be nice, but so far the sleep issues persist and waking up is much more difficult. Oh well.

What adventures await next month? I have two goals for October: First, to finally do that animation work. I’ve at least started to get into the swing of it, and I have a sense for how long these will take – I think I have a pretty good shot at finishing all of the basic motion animations for the character in two weeks, or at least getting close. Second, to get something onto the Unity Asset Store: I’m not sure what. I have numerous tools that I’ve been developing for this project, and I think a number of them would be useful to other developers – this grass effect is made using the advanced sprite shader I’ve been working on for much of the last year and a texture mixer which I think could be expanded into something powerful, and looking over what I’ve already done I have the 2d conditional animator which is close to complete and a couple of pretty interesting post-processing effects which could be expanded and upgraded. In order to feel comfortable putting something up on the asset store, though, I’ll need to push these things to a higher degree of stability and user-friendliness than I usually undertake for tools for my own use, so this could end up being quite labor-intensive. I’ll most likely start with the sprite shader I’ve been working on, since I’ve spent so much time with it – but, between aforementioned polish issues and a couple of extra features it will need to be competitive, this is probably something that will take at least a solid week to complete.

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.

Last month I had just started working on a system for transforming the color of sprites. I finished it pretty early on into this month, and immediately afterward made an post-processing effect which performed the same effect but across the entire screen. Although color matrices can do some really interesting and nearly arbitrary things to process one set of colors into another, for now I settled for just creating a set of interfaces for the most common set of effects I’d need: Hue, Saturation, Lightness, and Brightness. If you’re familiar with these sorts of operations you might have expected “Contrast” to be listed there, and it was at one point – however, I realized it was easy to approximate its effects with the lightness and brightness sliders, so I removed it.

Perhaps a word of explanation about what a color matrix is would be useful. A color matrix is a way of multiplying color values by each other and then offsetting the result: So, for instance, I could rotate the colors by making the red channel equal to the green channel and the green channel equal to the blue channel and so forth, or could zero out the blue channel to tint it yellow, or could add to all the channels to increase the overall lightness of the image. With that in mind, the operations do the following:

  • Hue: Rotate the RGB channels by degrees from -180 to 180
  • Saturation: Multiply the RGB channels while offsetting them enough to keep the overall average value the same
  • Lightness: Add to the RGB channels, moving them towards white or black
  • Brightness: Multiply the RGB channels, making colors more vibrant

This is a pretty powerful set of commands and is probably all you’d need under most circumstances. Nevertheless, it is tempting to add an interface for setting the matrix directly at some point, which would be much clunkier but allow for more unusual effects such as negative imaging, mapping the image’s transparency to its RGB brightness, or performing operations on only certain color channels. I’ll likely add it either at such time as I need that functionality or as I decide to sell this on the asset store.

Another feature I added, which I’m not sure if I’ll ever use but it seemed like an obvious addition, was adding a mask texture to control to what degree the color matrix is applied. I have no idea if or when this will become significant, but the idea of modifying both this texture property and the color matrix values simultaneously opens the door for some really unusual and powerful effects. Another possibility which I’m tempted to explore in the future might be loading a bunch of color matrices into a 3d texture and applying that as a post-processing effect… but I digress. The range of possibilities is exciting, but I need to keep moving.

This is something I can clearly go on about at length, but in practice this only took me a week or so of work and is more or less complete now. After completing the color transform feature, I was feeling stressed out with all of the work I’d been doing on the game and decided to take a week off… sort of. I ended up spending it working on music composition, something I’d been missing doing. This isn’t strictly part of the DevBlog, since this piece won’t feature in the game, but I’m quite pleased with how it turned out and felt like posting it here anyway.

I’d also, at the end of last month, finished implementing a system for changing between rooms in the game. This system was more or less functional but not really tested, and I’ve been developing it further over the last month. Aside from debugging, I’ve also made it so each room has a set of appearance options such as default lighting, background image, and post-processing effects, and whenever you move between rooms it changes between them. I actually went a step further and made it so these values actually change inside the editor depending on which room you’re currently looking at, so I can actually see these appearance modifications without starting the game and running to the room.

I spent some time at this point making some improvements to my work-space. It turns out that for $70 in monitor mounts you can drastically increase your available desk-space, and also just make a working environment feel generally more professional. For whatever reason, I’ve never felt as much like I was living in the future as I did after setting up my room with monitor mounts. Unfortunately for some reason my phone camera is incredibly terrible and this was the best picture I could take (so much for the future), but you get the idea.

In between all these other things I was making slight tweaks and improvements to the test rooms, shifting the terrain around, improving the visual effects, adding a mist particle effect and so forth.

I’m very pleased with the overall appearance of this section so far. I am not, however, pleased with its performance: There’s a little bit of framiness in the first couple of areas, but not enough to worry me too much. However, if I move further on, into areas with larger particle systems, performance starts to become truly terrible. At first I thought this was due to core issues with the way the Unity particle system renderer worked, and started working on developing a replacement, but once the supposed replacement was a ways along I tested it against the basic particle system and noted its performance was actually slightly worse – you know, the same sort of performance hit you’d expect from a system doing basically the same thing as what was there, but made by someone with less internal access and less experience with this kind of programming. Replacing the particle renderer was a bust, but all hope is not lost: Further brief diagnostic attempts revealed that the worst issues seemed to disappear if I disabled my custom particle animation effect, which could either mean that that effect is far more processor-intensive than I had believed or that enabling it was forcing the particle system into a state where it couldn’t operate as efficiently. Between that, the possibility of shader efficiency improvements, and the potential to replace some of the particle effects with cheaper and simpler animated textures, I think I’ll be able to resolve this to my satisfaction… eventually.

I’m going to be out of town for the next couple of weeks but will probably still have plenty of time to work on the project, so the question is how much of this work I can effectively do on my old laptop. Considering the areas with really bad performance drop down to like 2 frames a second even on this somewhat recent desktop, it may be unfeasible to tackle these performance improvements right away just due to the amount of time I’d have to spend waiting for clicks to register while testing changes. Still, I’ll give it a shot – and even if it doesn’t work I still have a ton of animation work to do, which I should have no problem doing with that equipment. Even if that, too, proves infeasible for some reason, I can plan out what I need to do for these first few areas – even if I have to do it with pen and paper.

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.

Another month has gone by, and though a short vacation, a nasty little cold, and a number of other minor distractions got in my way, I still managed to make a little bit of progress.

First, and most importantly, I put quite a few hours into writing the music for the first boss of the game. I may have gone a little bit overboard on this one: The concept I wanted to pursue was a track with multiple phases that mapped to different parts of the boss encounter, bouncing back and forth between them until finally reaching a conclusion. I’m not sure if I can possibly create a boss encounter that stays interesting long enough to accompany this track, coming in at almost 9 minutes long, but it will be fun to try once the rest of the chapter is complete.

The phases of the track are:

0:00-1:47 Intro
1:47-4:13 The Chest
4:13-6:16 The Mask
6:16-7:49 The Heart
7:49-8:40 Conclusion

This one honestly ended up getting quite a bit out of hand, and I spent quite a bit more time than I’d originally expected to on it, but I’m quite pleased with how it turned out. I also just enjoyed doing music work again! I’m going to carry on with composing the soundtrack even though I’ve effectively completed all the tracks for the first chapter of the game now, which is the part of the game I’m focused on finishing. The reasons why I’m going to continue doing music work, despite otherwise attempting to contain my efforts to this first chapter, are several-fold: first because, as mentioned, I like making music and I want to do more of it, second because if I can’t make this game in a timely fashion I can damn sure make its soundtrack, which is a discrete sub-creation that I can be proud of in its own right, and third because I find music so compelling that I think just having the soundtrack to the game will motivate me more to finish the rest of it. There’s also a fourth, more pragmatic reason: Inspired by UNDERTALE’s soundtrack, I’m really trying to integrate motifs from different characters and locations into tracks with a narrative connection to those characters and locations. It’s going to be really hard to do that until I know what those motifs, for later parts of the game, actually are! I’m not really going to be able to consider chapter 1’s soundtrack complete until I’ve written the rest of the soundtrack and know better what my overall thematic tools and goals are.

Anyway! Aside from music, I’ve been working on a few things. I’ve been feeling my way around programming the main narrative component of the game, the storyteller. This is going to be something pretty similar to what Supergiant does in their games with an ongoing narration element, except I would like to integrate these narrator lines a little bit more closely with the music, syncing the lines up with particular parts of the track and so forth. Additionally, I want to have text appear in the world synced with the audio, so it’s a bit like playing a storybook. Figuring out how I’m going to pragmatically handle the synchronization of these elements and making them play nice with a player who may or may not be interested in the narrative taking place is going to be a challenge, but I’m getting close to having a simple version ready to test so that I can iterate on it.

I’ve also been thinking a lot about what the interface of the game is going to look like. There are really only two elements that need to be displayed under normal circumstances: The player’s current health, and how many sparks you’ve collected, which also maps to your max health. I could just have a red bar along one side of the screen, but that felt inelegant. A sphere that fills and empties like the health meter in Diablo might have been a bit more thematic, since there’s some sun/moon symbolism I’m playing with in the game, but it felt like a circle would take up a lot of screen real estate for how much info it would impart and probably wouldn’t look very good. What I’ve come up with instead is an idea that’s… actually a little bit difficult to express here. It’s basically a life bar along the left side of the screen, except it looks like an engraved stone tablet. Only a small part of the tablet is visible early on, but as you gain more power the tablet expands and you can see more of it, and the engravings on it. I can actually directly tie the health meter into the narrative of the game in what I think is a pretty interesting way. However, because you don’t gain power at a constant rate, but instead end up collecting more and more as you defeat more powerful opponents, I’m going to have to figure out a curve that reveals the tablet at a rate that’s satisfying over the course of the game. I have a logarithmic function in mind that may work well, but it will have to be tested. I’ll also need to figure out how to have the tablet build up in such a way that it feels satisfying, and ensure that no matter what its interim shape is it still gives satisfactory feedback as a health meter. This will all take a bit of experimentation, but it’s an idea I’m excited about.

Finally, I’ve been working on the game’s first animation. I mean, I’ve already built several animations, but this is the first one that will play in the game: The player character awakening, standing up, and taking her weapon at the very beginning of the game. I started creating this animation, and then had to start over after working on it for a few hours because my first take on it sucked. I think my second take on it has potential, though it’s still very rough the motion feels good to me.

The actual removing-sword part of the animation still needs to happen, and of course all of the detail and the tween frames need to be added, but I think I’m on the right track this time.

So, the plan for August is to finish working on these things, write the music for the first area of chapter 2 (I’ve already started), create more main-character animations, and maybe get some basic sound design in. Of course something else may capture my fancy and I’ll end up working on that, but as long as I stick to my big task list I think I can maintain forward progress.

This month was a completely different kind of weird month than the last weird month – but weird nonetheless.

I ended up taking around two weeks of vacation, between a planned family visit, a memorial service, and associated travel times. When I got back the entire city was blanketed in toxic smoke particles, so I had to lock myself indoors – even more so than I do habitually, and with less ventilation. And, between these trips and certain extremely stressful interpersonal conflicts, I’ve been thinking about things – about where I’m going with my life, how I want to get there, and what that will look like.

First, I should probably address the lack of posts on the blog. I could have probably kept things going, but I’ve been feeling like it’s harder and harder to come up with topics that I feel are worth writing about, to the extent that I don’t feel some of my posts are to the level of insight or quality I want them to be. If all else were equal I’d just shake it off as a bad streak, but I think it’s also just been hard to focus with all of this strife and uncertainty in my life, so I’ve put things on hiatus for a bit. I wanted to make some sort of official announcement about that, but I kept putting it off until now, when I needed to write a devblog post anyway. I intend to resume posting on the previous schedule starting in November.

Regarding my plans for the future: The game is still being made, but I also feel like I need to put a bit more into existing as a professional in the here and now rather than just in a nebulous future. Towards this end, I’ve decided to start seeking freelance work –  and, tangentially, if you would like to hire me to do any of the sorts of work you have seen/read/heard here at Problem Machine, please feel free to email me with inquiries at However, as soon as I began looking for contract work, I realized that I feel a crushing lack of confidence in what I have to show as portfolio work right now. I don’t feel like what I have done shows in any way what I am truly capable of doing – and, since I happen to have come into a bit of money recently, enough to relieve my most immediate financial pressures, for a while I will be shifting my focus from just surviving while I make my game to making my game, learning and practicing, and building my portfolio. I have a list of what I want to create over the next few months, a list I don’t really care to get into the specifics of at the moment, but which involves a number of art, programming, music, and game development tasks. Once this list is complete, I expect to have a body of work that I can be really proud of, something which, even if it isn’t outstanding in every respect, can at least be regarded as roundly workmanlike and occasionally exceptional.

Now I’m 500 words in and I haven’t really talked about the game much at all. Despite everything, I have gotten some work in on the project – mostly, at this point, developing the attack animations for the sub-types of mask enemy.

And when I say mostly, I mean entirely, since I really haven’t had more than a week or two free to actually work this month. As I’m working on building my portfolio I’ll probably have a bit less time to work on the game, but will continue to plug doggedly away at it, if for no other reason than my skull starts feeling too small for my brain if I stop for any significant length of time. It should be fairly easy to finish developing these enemies animation-wise, and then I can revisit the behavior code to fix the remaining issues with their in-game behavior, which shouldn’t be too hard. Once these guys are done, there’s only a couple more enemies to develop for the opening sections of the game, one of which is pretty simple, and I can probably refocus my attention on building up the aesthetic of the early stages. In the meanwhile, future devblog updates will probably contain samples of the work I do in building up my portfolio, which hopefully will be of interest to those of you who have been interested in the game in the first place.

It’s been a bit of a weird month. I haven’t worked deeply on much, but made a lot of slight progress on different things, and have also made some substantial revisions to the game design.

Well, first things first, I made this piece of background art:

I like how this one turned out, but I also need to make an alternate version of it for a special effect I have planned and that one is proving to be a bit difficult. A lot of these background images are almost technical problems, where I need to figure out a way to depict the idea I have in my head without getting bogged down for hours and hours, and also to depict an area that makes some sense relative to the actual navigable portion of terrain the game takes place in. This background already has taken far more time than any of the others, and the potential for an even more detailed and time-consuming version has me a bit concerned, so I’m trying to figure out a clever way to approach it..

With these concerns in mind, I decided to drop the background work for a bit and work on some animations. I began creating animations for one of the other early-game enemies, the Crawler:

This is one of very few enemies in the game what does damage on contact rather than having to do a particular attack, and is more or less completely unaggressive and minds its own business – an obstacle as much as an enemy, really. The animations aren’t quite complete yet, with the turn animation in particular being a bit of a troublesome obstacle, but it’s coming along. Once this and the mask enemy are complete, there’s only one more enemy type planned for the first couple areas of the game, so I’ll have pretty much everything I need in place to finish building out the early areas. I also spent some time building out some of the animations I’ll need for the other variations on the mask enemy, such as the stone throwing and spear throwing types, but nothing finished as of yet.

There were some other minor side-lines – a system for making it possible to modify a value from multiple locations without overwriting each other’s modifications, building a special ‘alternate reality’ effect for the second area, roughing out some of the level designs… near the end of the month, though, I realized, or perhaps merely acknowledged, a number of substantial design flaws that were threatening to undermine the game. These had to do with the upgrades I had planned, when you were likely to find them in the game, and how useful and interesting they would be. The biggest problem that emerged was that I had come up with the idea of this attack using the sling and, when I thought about how it would feel in action, I realized it was completely unsatisfactory. Essentially I was planning this whole ability which didn’t really have any role in what the player was doing – it would be the only ranged attack available, sure, but in a game where ranged attacks weren’t really necessary to succeed, and it would totally clutter up the control system.

I spent a few days thinking about this, and eventually came up with a whole new system, with a set of 4 elemental attacks and alternate forms of each attack, along with a system of special attack ‘charges’ that get restored whenever the player gets hit. I think this is a pretty good idea! But it also presents a lot of issues with, again, when the player finds upgrades and what role those upgrades play in the overall flow of the game. I’m still not 100% there with this design, but the missing pieces will probably be small things that I can fit into place as I go rather than massive gaping holes that I need to invent whole new game systems to fill.

Since then, I’ve just been reworking the way attacks are programmed to make room for this system. The new attack system is far more flexible than before, though there are probably still some ways I could improve it that I may have to consider.

This month will probably have more work on creating enemy animations, a little bit more design work figuring out what the flow of upgrades and specific properties of special attacks will be (along with whether I want to have, say, special objects that the player can interact with using said special attacks), and perhaps laying the groundwork for creating the special attacks themselves – though they are mostly a low priority for a moment, since most of them are planned to be found later in the game than the first chapter, which is where I am currently focusing my development effort. If I don’t feel like that stuff then creating assets and level details for the first couple areas, finishing the mentioned background image, or building improving tilesets are also strong possibilities for productive work to do next.


In a bit of a weird spot right now. I’ve been working on doing the animations for the first and likely most complex non-boss enemy of the game, and I’m starting to feel a bit depressed about it. Working on a bunch of very simple very similar pictures for a few weeks tends to get old, even if you feel proud of the result. I ran into this same issue working on the main character animations, and now as with then I’m going to have to figure out more kinds of work to mix in because this is starting to undermine my motivation to work on the project. I need to remember never to leave myself on the same animation task for more than a week or so, since it tends to do terrible things to my morale after a little while.

Because these guys aren’t quite symmetrical, but I didn’t want to create left and right facing versions, some interesting properties emerged. The most noticeable of these is where they actually momentarily drop their knife and then catch it in their other hand in the running turn animation, which nicely adds to the frantic and panicked feel of the animation and swaps hands so that when they run the other direction it looks natural. The strap holding up their clothing also quietly changes shoulder, and the light shifts to the other side of them, during the turn. I think these weird fudgings of reality will largely be invisible in action, but it was an interesting problem to figure out as I went, since I hadn’t really considered it before.

I had originally planned to make several different shapes of mask for these guys, but I think that’s something I’m unlikely to do now. To create each mask I’d have to do a bunch of drawings of the mask facing in different directions for the turn, add code to make it draw in front of or behind the head based on where they are in the current animation, and make sure the movement perfectly syncs up. That’s possible, but seems like a lot of work for something that might not look very good. Alternately I could just make a bunch of different animations for different masks, which, again, I don’t think will be worth the effort. That said, there are alternate versions of this enemy with different capabilities, so when I make them I can make their masks look different, which will be more communicative and less labor intensive than what I was planning on doing.

That’s mostly it for the last month, though I also did some miscellaneous work fixing bugs in path-finding, improving the cave tileset and building out the caves. The particle system is basically functional but is still not really an improvement on what I had before I started in any way, remaining extremely buggy when run in multi-threaded mode while still not quite performing as well as I’d hoped – for reasons which, as yet, remain mysterious.

I think for the next week or so I should focus on getting all of the editors working  so that I can spend some time detailing the levels, adding foreground and background elements, generally making them feel finished – or as finished as they’re going to get until I finish making enemies for them.

I like these animations, but they’re not much to show for the better part of a month or work. I don’t know what to think about that: It doesn’t feel like I’ve been slacking. Maybe these guys were just difficult to animate.