Archive

DevBlog

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.

 

Well it’s not quite the 10th, is it? Ah well, it keeps rolling around to the next month and I want to have something more impressive to show for the time I’ve spent and it just makes me fall further behind. This has not been a month of great strides, but of small but significant ones. And, as I look back now, I see I actually have several interesting things to show off, if only because I have been remiss about showing some of the things I’ve been working on in the past.

First, I think I should probably show what the water effect looks like in action now. The effect is basically constructed, but there’s still obviously a lot of little improvements I can make if I go in and take the time to later:

Right now the ripples made by entities entering the water move absurdly quickly and don’t really spread out the way they should, and there probably should be something in between no splash at all and the substantial splash that’s made on exiting or entering the body of the water, and maybe the surface of the water should be a bit blurry or should be a bit wavier, but the bones of the effect are all constructed now and I can tweak it at my leisure later. Oh, also there’s that weird stray splash particle up on the upper left — that’s the particle that’s getting cloned to create the splash effect, but I’m not sure why that one is just sitting there.

I also did some more work on painting backgrounds. A couple of these are really complex, and aren’t really ready to be shown since they’re taking a while, but I also decided that I didn’t like the way the caves background looked and set out to improve it, as well as creating a secondary caves background for some of the other rooms.

Some of the stone ended up looking a bit woody, kind of like tree trunks or roots, but I don’t think that’s too much a bad thing. I can always tweak it later if it causes confusion, anyway.

The last major thing I’ve been working on is one of the core components of the game, the harvest system. The way this game will work (mostly) is that whenever you defeat an enemy they are basically put in stasis while the spark that keeps their spirit going flies out and about, in the shape of a moth. Once you gather that the body dissolves, but if you wait too long (say, because you’re being attacked by other enemies) it will return to their bodies and they’ll activate again. Once you harvest all the enemies in an area that area stays dead and empty, so you only need to fight the same enemies twice if you fail to clear an area. That means that I need to be able to individually track every enemy the player has harvested and make sure that data gets saved with all the other game data. It also means I need to have effects for when the enemy is defeated, when the moth is absorbed, when the enemy is dissolved, etcetera. I architected most of the former a while ago, and this past month I made big strides into the latter.

Actually, a lot of the work I put in here emerged directly from the work I earlier put in with rendering those water effects. The weird hazy effect I’m using now for enemies fading away after defeat is a combination of a scrolling displacement map, a blur filter, and a standard transparency fade-out: I really love the way these look together, and I don’t know if I’ve ever seen anything quite like it in another game before. As with the water, I still feel the effect can be improved upon, but I’m really happy with what I’ve got so far here, and I will probably use something extremely similar for the final game.

In reality, most of this stuff was pretty close to its current state as of about 10-15 days ago. Most of the past couple weeks has actually been taken up by extremely uninteresting-to-talk-about debugging of some problems with the drawing functions of my animation class that only manifested when I started rendering these special effects. As annoying as it is to not do work that feels like progress, my animation class is one of the bits of programming I’m proudest of, so I’m always pleased to get the opportunity to improve it.

This next month will probably be more background drawing, polishing up this basic enemy to fix the weirdness in animations and behavior, and getting started on building out some of the other enemies and variations on this enemy.

I feel like these monthly devblogs have been getting away from me a bit. From now on I’m going to just nail the date down here and say I’m going to always have these up by the 10th, since that gives me plenty of time to recover from the traditional rent panic and wrap up whatever loose ends I want to have before the post goes up.

Anyway.

I guess the first thing that should be said is immediately after spending last month’s DevBlog complaining about being unable to increase the framerate, I went and did the extremely obvious thing that I mentioned in that post and that,  unsurprisingly, boosted the framerate massively. It’s still not a stable 60 frames a second, but it gets there on some of the more bare-bones levels and is stable above 50 on some of the more complex ones so it’s fine. Of course, I immediately tanked that framerate back down to 30 or so by engaging in a month-long project to add a sweet water effect to the game. In fact, the entirety of the last month has been spent on working on this sweet water effect.

This effect is achieved with a combination of copying and flipping the screen buffer, overlaying a texture on top, applying a displacement map on top of that to warp the image, and then running that through a color matrix filter. I’ve fixed a lot of the slowdown by cutting the draw area down to just the section of screen that needs to be drawn, rather than drawing the whole screen worth of water and then masking the parts I need out, but it could still use some more optimization. I’m a bit frustrated that this effect is taking so long to get working, during which I’m not making ‘content’, but I’m also pretty happy – this water effect is actually something I’ve been thinking about for a long time, and honestly now that I’ve got something in place I can think of a lot of rather interesting applications beyond the obvious. The ripples and displacements might be applied to make grass ripple in the wind, the reflections can be used for other reflective surfaces, and the improvements I’m making to the particle system to allow entities (like the water) to spawn particles for special effects will have limitless applications.

There’s still some work left to be done here. I have the architecture in place to add splashing effects and whatnot as entities enter and exit the water area, but these effects have yet to be tested or implemented. With that major revision done, further work on the water system will probably mostly be in the vein of tweaks and refactoring, which I can do gradually as needed over the life of the project. Some glistening white areas might also be nice, but I’ll probably add that to a wishlist for later. Next, I’ll be focusing on really building out the first few areas of the game and ensuring the first couple enemies function properly. i am, of course, months behind the project planning schedule I had earlier devised, but at this point I’m just trying to maintain morale and make steady progress – I can see about working harder and faster as I gain aptitude with (and slowly improve) my tool set.

It’s been a rough month for the project. I’ve been feeling the least motivation to work seriously on it that I have in a long time, and there’s probably a number of reasons for this, ranging from stressing out about volatile political conditions to worrying about money to being distracted by very good video games. However, I think the biggest thing undermining my motivation is lack of confidence in the technical side of the project, and I’m still figuring out what to do about that.

See, I’m building this project in Adobe AIR, which is essentially the same thing as Flash but repackaged for local installation instead of streaming. There’s a lot good to be said about AIR, and a number of good games have been made in it, but over time it’s felt like I’m struggling more and more against it, being limited by its weaknesses while not taking advantage of its strengths. I’m starting to question (again) whether I should be working in this environment at all. The past month has been a struggle to get the framerate up over 60fps. Originally I had believed that once I got my multi-threaded solution working it would just happen. Then I thought that once I got my multi-threaded solution optimized it would happen. Then I thought that once I went through and optimized everything else it would happen.

Now I’m thinking it might just not happen – at least, not with the amount of individual animated details I want to have in each level, and/or not with the lighting system blending in on top. There may be another way to handle the lighting issue, so I’ll look into that. I also can probably improve performance somewhat by more carefully culling draw operations that would take place outside of the screen space. I can try those things, but it’s time to start carefully considering what I do if they don’t work. I’m slightly tempted to try to port the engine into some new architecture/environment, though I probably won’t. I may experiment with getting it running in OpenFL again, since that gives me a lot more opportunities for optimization, but I probably won’t remake the entire thing running in C and SDL…

Probably.

So, what do I have to show for this last month? (A bit more than a month, actually, since this devblog is a week late). I did all of the animations left to get the basic mask enemy working (though the enemy itself still needs some work since the behavior doesn’t work quite right), fixed a number of bugs, finished getting the multi-threaded particle system running and fixed performance problems therein, and made some performance improvements. It’s not a very productive month, but they can’t all be I guess.

But what’s next? What’s my plan to get out of this funk?

Most immediately, I’m going to go in and see if some judicious culling of draw operations can improve the framerate. Then I’m going to see if I can figure out how to do some decent looking water. Then I start building out the early levels, adding details, fixing up the mask entity so it feels good, and perhaps starting work on getting another enemy working.

There’s still so much to do, and I don’t feel like I have any momentum. But who ever starts with momentum? It’s something you pick up along the way.

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.

EveHeader

I’m doing a terrible job of sticking to the schedule I came up with. I keep getting sidetracked by new tasks, improvements or things I forgot to put on the schedule. This last month, I finally got around to looking up what sorts of multi-threading solutions are available in Haxe/AIR. It turns out that Adobe AIR has supported multi-threading for a while now, with an implementation that is both very straightforward and kind of frustrating. AIR’s version of multi-threading is: Load another AIR program into your running program, and pass values back and forth. Simple enough in concept, but it still has all the traditional concerns of multi-threading with sharing resources and managing access.

So, much of this past month has been taken up with trying to get my particle system, the most demanding discrete subsystem of EverEnding, running in a separate thread. It took a lot of thought and experimentation to figure out a way to restructure a system which had presumed open access to a shared memory pool and make it run remotely with operations mediated by a single point of communication. After a week or two I got it running, but… not especially well. The benefit of the new system is a bump from 45fps to 50fps, which is not as dramatic or life-changing as I’d hoped — plus, for some reason, there are spikes of 30-50ms, which make the overall effect still somewhat disjointed and unpleasant. Still, I think these problems will be fixable, though it may be tricky to figure out exactly how they’re manifesting.

Aside from that I’ve mostly been working on building out the last section of the first area, the caves. I think I’m finally starting to nail down a paradigm of tile design for this game, based around the idea of areas which are lit, areas which are dark, and areas which are somewhere in between. Lit areas are mostly on the upper right and dark areas mostly on the lower left, with various transitional tiles to make them flow smoothly from one to the next. The cave tileset is starting to come together, though certain tiles still need some work. The background could use some improvement as well.

caves00

Also, looking back through my daily devblog notes, apparently I worked on collision in February as well. Strange, it feels like much more than a ago now. Well, most of the collision improvements are in place and working, but in the process some things broke, so those will need to be re-fixed. It’s basically guaranteed that any time I work on collision code I’ll end up frustrated.

So what’s next? I’ll probably focus on developing the level architecture and tilesets until I’m completely done with the caves, then go back and focus on populating this first area with enemies and details. Along the way somewhere I’ll spend a few days fixing all the things I broke getting the new particle system implemented and see if I can fix weird glitches there, as well as maybe a bit more collision work (sigh).

EveHeader

It’s been kind of a strange month for the project. I’ve made next to no progress on the task list I’ve created for the game, but I’m still largely satisfied with the work I’ve done. That is to say, I’ve been putting a lot of time in on things that it hadn’t previously occurred to me I would need, so I can’t really cross anything off a list when I get it done, but nevertheless the tasks I’ve done needed doing.

So, what are these tasks?

  • Created a system to modify hue/saturation/brightness of animations, and implemented controls for this into existing particle systems and associated editors, as well as creating a similar system for modifying tileset colors
  • Fixed up the detail editor to make it more flexible and easy to use, including the ability to modify multiple details at once
  • Created a seeded random number generator so particle systems that use random numbers will generate consistently from one play to the next
  • Created a simple collision system for particles, which can be used to make them only spawn on top of tiles or perform special behaviors when they collide with tiles
  • Added the ability to have particle behaviors that only trigger once on spawn rather than updating continuously
  • Collision improvements and implementation of water tiles and combination platform/slope tiles
  • Fixed the way perspective is calculated on details to center the vanishing point rather than have it locked to the upper left
  • Stripped out a non-functional zoom in/out system in favor of a much simpler one that actually works
colorchange

With all these color controls I have a lot more ability to customize areas without creating all-new assets

On top of that I’ve been building levels out, which is on the list but also takes a long time to make progress on. It’s really difficult to say much about the process of building levels, because 90% of it is just spent on making sure tile boundaries line up and making tiny aesthetic tweaks. In that way it’s a lot like working on the animations after I created prototype animations: All of the concept is mostly there, I just need to elevate it to finished quality.

I’m getting close to the end of my ad-hoc list of unexpected and unscheduled problems/improvements, so I ought to be getting back to the game schedule soon. Worst case scenario is I’m a month behind of where I wanted to be: Best case scenario is that I end up making up the time I lost by leveraging some of the improvements I’ve made. We’ll see. In any case, I’m probably going to be spending the coming month or two getting early-game enemies fully animated and operational. The first couple of enemies will be the most difficult by far, I believe – after those are complete I should be able to copy and paste from them for almost everything I’ll ever need an enemy to do.