Archive

Tag Archives: 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.

If you’ve been keeping up on the blog for the past few months, you may have noticed that it’s been a while since I’ve posted any updates regarding monthly projects. What updates there have been haven’t really included any finished results. The fact is, these last few months haven’t been very conducive to getting work on these projects done – and, even when circumstances have allowed it, I have not had the motivation to pursue these projects as devotedly as I’d need to to bring them to completion. Even though I’ve been happy with how the weekly posts have been going here, that’s really only half the work I’m supposed to be doing. For March I’d wanted to collaborate with others to bring a reasonably-sized 2d platformer to life. There was less interest in the project than I’d hoped and I had less time and energy to pursue it than I’d hoped, so it eventually went on hiatus – hopefully to resume someday but, well, we’ll see. Afterwards, for May, I wanted to develop a vector graphics drawing tool for Unity. This is still an idea I have some enthusiasm for, but it turned out in the end that I needed to do a great deal of studying in order to understand the fundamentals of computer graphics that would allow me to bring this to life. It turns out that just understanding the math isn’t enough, you have to understand how the math translates into instructions that you can pass into a graphics card. And, though I eventually got a handle on these problems (I think), the next month was so busy that I ended up having to time or energy left over to work on actually programming the tool itself.

And now it’s July. I really don’t want to turn this project that I have barely any concrete work done on into a three-month project. I really don’t feel like finishing that platformer right now. So, for the time being, I’m doing something different. I need a win, here.

Five months have passed since I made Convergence Compulsion for Wizard Jam 8, and since it is a semi-annual event the next one is rolling around again. As with the last jam, it’s intended to last two weeks – but I’m going to spend the entire month on it since no one is really a stickler about these things. I don’t know what my project is going to be, but my commitment at this stage is to A) Actually finish a damn game, and B) Make it shorter and more polished than Convergence Compulsion, since I felt like a lot of players lost patience with it before the end (though I remain proud of that project).

Once the month is out, once this game is done, I’m going back to EverEnding for August. I’m currently considering ways to integrate EverEnding into my Patreon monthly work, and I’ll have more on that in a month or so. For the time being, I have to figure out what I’ll be working on for Wizard Jam 9. Wish me luck!

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!

I always hate doing these updates where there’s not a lot of progress to report. The last couple of weeks in particular have been devoid of any progress on the project, or even any work on it – at first because of a shoulder injury, which was making it particularly difficult to focus on any of the complex problems I needed to solve to work on the code part of the project, and then on a short family vacation. Before that, I was working regularly on the project – well, except for the week or so where the new meds I was trying out were making me too groggy to think straight – but, still, not making a lot of progress.

Part of the problem with working on a project the size of a game is that sometimes even the components of the project, the discrete chunks you’ve written down as tasks on a task list, come to substantial undertakings in their own right. Especially when one’s focus is split between several of these, it can be entirely possible to spend a lot of time working on them, not running into any particular roadblocks and making what feels like good progress in the moment, and look back and not see anything new actually finished. This is basically how things have been for the last month – In particular, the storytelling system has taken much much longer than I’d expected it to, leading me to do a bunch of rewriting of the music system. The reason why the music system had to be rewritten was so that I could readily sync the storytelling lines with the music when I wanted to, in a way which I didn’t have to custom code for every story and every music track. I now have a system where any music track playback can intelligently jump around – that is, once I put in a number of valid points it can jump to in a track, say if a certain section can end in three different ways, I can give it a destination range in the music and it will find the shortest path to get there. I didn’t expect to have to read up on pathfinding algorithms for my music code, but here we are.

Now that I’ve got that component of the storytelling system figured out, there’s still one major roadblock to finishing it: Text rendering. This is something that should be easy in Flash/AIR, but just due to how I have entity rendering set up is a bit tricky. At this point, I have two options: Either I modify the entity rendering system, which would be a nuisance but not too difficult, or I find a way to convert the text into graphics rendering commands that I can send to the entity draw command queue. I’ve found a library that does this, but it hasn’t been updated for 8 years, so it might not be an ideal choice. If it doesn’t work out and I don’t find an alternative, though, then I’ll just have to rewrite the entity draw command system, because writing a whole text renderer to handle this problem would be an obscene waste of time, albeit presumably an educational one. At some point, as well, I’ll have to create a typeface for the game to use, possibly several. I think that will be fun.

The other two major things I was working on last time were the health bar and the awakening animation. The awakening animation has turned out to be a bit of a quagmire as well – I had the motion of standing and grabbing the weapon looking pretty good when I realized that I hadn’t really planned out how it was actually going to fit into the level where it was supposed to happen. This was something I can only describe as an extremely foolish oversight on my part. I’ve begun reworking the animation and I think I figured out a way to do so without completely starting over (again), but it required me to redraw the tree which was the main prop in that area. Honestly, I’m glad I was forced to do so, because the previous tree looked pixelated in a way which I had thought looked okay – but, I can see now, really did not. It looks much better now.

Of course, now I have to be concerned that making this tree look better will make the rest of the game look worse in comparison, and lead to an endless cycle of revisions. For now I’ll just have to enjoy the journey I guess, because I can’t say when things will start looking ‘good enough’ to me.

As for the health bar, progress is being made on it, but the storytelling code took priority and I didn’t want to split my attention between two programming tasks. I’ve also been working here and there on music for the next area, but though I have a number of promising ideas down, most of which will probably find their way into the finished version somewhere, none of them really feel like the right place for the song to start. For now, there, too, I keep experimenting, waiting to be visited by the spirit of satisfaction.

So, for this next month, I intend to finish the storytelling system, finish the awakening animation, finish the health bar. From there I’ll probably start in on other necessary animations – though I also think it quite likely that I’ll look at the tilesets I have to bring their level of quality up to this tree asset. It’s gotta be about the pleasure of the journey, because at this point I have frankly no idea when this project is going to go anywhere. I wish I knew how to work on it faster, but at this point it seems like it’s work slowly or not at all, and hope one day to accidentally, habitually, fall into a more rapid pace.