Archive

Programming

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.

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.

 

EveHeader

It’s been a bit of a slow month for work on the EverEnding project for reasons which are largely obvious. About 10 days of the last 30 were taken up with a big holiday trip, under which circumstances I wasn’t really able to find the time and energy to work on the project – and, what’s more, left me tired and inert enough that I didn’t get much done for a while after either. That being said, progress is starting to be made, and certain foundational parts of the game are coming together.

So, to start with: The main character animations for chapter 1 are pretty much all done. I say ‘pretty much’ because I’m confident that as time passes I will notice improvements that need to be made, possibly even new animations that need to be created. However, for the time being that all-important part of the project is complete.

Once I achieved that, I turned my attention towards various outstanding programming tasks that have been on my to-do list for some time. I finally found and fixed a very annoying bug that was causing entities to self-replicate when I saved a level I was editing, which was causing massive slowdown since the entire lighting system was getting duplicated several times over. I found and fixed another bug which was causing the background layer of levels to not match the size of the foreground layer, and also created a player profile system, which should be able to handle saving and loading all the necessary information for game progression alongside all of the player’s controller/keyboard binding information. Somewhere in the midst of all this, I built a bunch of assets for the early areas of the game – mostly pretty simple ones, which makes them excellent test cases for the kinds of improvements I’ll need to make to the details system to get levels looking the way I want them to.

01-05-2017-standing-stones

I’m noticing something strange now that I’ve finished the main character animations: Even though I frequently found the work tedious, having something straightforward, relatively brain-dead, and indisputably important to the core of the game to work on was actually incredibly useful. When I was feeling tired or dull or confused it was still totally feasible to get good work done just by focusing on creating animations. That is not to say that animating is easy or stupid work, but I’d already planned out all the animations such that easy and stupid work was mostly the only kind left to do on them to complete them. Now that I don’t have these animation tasks to rely upon, I feel a bit cast adrift on the gigantic task list that is this project.

Oh well, I’m sure I’ll hit a new rhythm soon enough. I think building out the levels may be similarly straightforward and rewarding, though the level editing tools may need a bit of improvement before I can dedicate myself fully to that work. Perhaps those improvements should be my first priority, then, after I get the core game systems I’m currently focused on up and running.

EveHeader

This was an eventful month! Following my devblog post last month, I started sharing the project on a couple of game dev forums, and through a logical process which eludes me now 30 days later determined that a) I wanted to have the first chapter of the game complete by the end of 2017 and b) that in order to do this I should create a complete task-list and schedule for the project up to that point. This ended up taking me a few days, but I really feel like it was worth it. I now have, printed across 12 pages, a fairly comprehensive list of work that needs to be done in order to complete the first chapter of the game. There’s going to be four chapters total, so a lot of work will remain to complete the game even after all this, but the scope of the work will be determined and I’ll know how much time and effort it takes to create finished content for the game. All major gameplay bugs should get eliminated through this process, and all fundamental design code will be firmly in place.

I broke the schedule up into a total of five three-month blocks, one for the rest of this year and four others for next year. Currently, for this year’s block, I have 24/53 tasks completed or otherwise resolved. I also have a few tasks which I had to add to the list which aren’t accounted for there, as well as a few that are partially complete, but it’s still good progress and I’m proud of how quickly I’m getting the work done. Now, I expect some future tasks to be quite a bit trickier, and I also expect many unforeseen tasks to crop up, but that’s why I’m trying to get ahead of schedule now – as well as acknowledging that December is likely to be so busy with other stuff that I’ll probably only be able to work for half of it.

The biggest task accomplished over this month is the attack animations. All right-facing attack animations are complete – well, except for the occasional mistake or two still to be fixed, a few of which I’m noticing as I watch the attack montage play below. About half of the left-facing attacks are complete as well, and they should progress more quickly on average now that I have the right-facing attacks to use as template and I’ve got so much sprite creation practice. There were a few big sticking points: I realized after mostly completing them that the original standing attack animation was a) boring and b) functionally redundant with the running attack animation. I’ve since replaced the former with the latter, but fortunately not all was lost: I was able to use the standing attack frames to resolve another issue that had cropped up. When I changed the crouching position of the right arm some time ago, I invalidated the entire swing arc of the primary crouching attack animation prototype. However, the new arm position made perfect sense for the motion of the unused standing attack animation, so I just pulled the torso from those frames into the crouch animation. I still had to redo the leg positions from scratch, but it was a nice shortcut into creating a good expressive attack.

attackmontage

I’ve also been working on the music for the game. The first few areas largely have completed music tracks already, since I created music concurrent with them to figure out the tone I was going for, but as I made that music like five years ago there’s a lot of rough edges in those old tracks and they’re not necessarily well set up to work with the systems I want to have in place for the game. That is to say, I’m not planning on just creating a loop for each area, but having some degree of adaptive music based on where specifically the player is in an area and what the game state of that area is. Thus, I’ve been remastering the old tracks, making small composition tweaks, and rearranging the parts to make jumping between them work better. Fortunately, I found that by setting timers and jump points, I could very elegantly skip between segments of an adaptive track to switch playback to a new section. Less fortunately, I discovered that a track with tempo changes and heavy use of delay effects is probably the least optimal type of track to feed into such a system. Still, it’s functional for now, even if some of the track transitions sound a bit odd. I’ve at least proven out the basic concept and built the architecture: If I need to change things up a bit later to resolve these issues, it should be quite feasible.

hills

I’ve also been working on tilesets and backgrounds here and there. I made this background very desaturated to create a clear delineation between background areas and gameplay areas, and also to reinforce the misty feel I was going for, but I worry a bit about how well it will work with the extremely vivid and saturated caves background I made before. I really love playing with color in unexpected ways, like I did with making the distance in the caves background a dark vivid red, but consistency is important as well. In the end, that’s something I can only figure out by getting the assets into the game and playing around with them and seeing what works. Really, though, changing palettes is incredibly easy compared to creating new assets, so it probably won’t be a big deal at any rate.

In addition to the backgrounds, I’ve created a number of the transitional tilesets necessary to blend different tilesets together. Now I can have grass tiles next to stone tiles next to dirt tiles without them looking like artificial grid-based garbage. There’s still some gaps in there, tiles that I’ll need to create that I haven’t noticed I’ll need to create, but I can build out most of the environments I want to now, at least at a degree of rough detail.

Over November I plan to finish out all of the character animations and start creating detail assets for the first section of the first chapter – Mostly just different kinds of grass and stone to start with but, again, in many of these cases I won’t know what I’ve forgotten until I get there and find I don’t have it. Still, finishing this game, as distant a goal as it remains, feels more concrete and feasible now than it has in a long time.

 

simpsons3d

How is a number like a hero? How is an equation like a tragedy?

First: The world as we perceive is not the world as it is. As we perceive the world we live in, through our sense of sight and sound and touch, we break everything down into symbols that our brain can comprehend and work with. Because those symbols are internally consistent, we can still interact with the world as though we are part of it – which, of course, we are. Our minds are always at one level removed: The brain sees the world, converts it into a symbolic understanding, and then operates on those symbols to decide what to do next, sending instructions to the body which thereby affects the world, and so forth.

This symbolic system is unique from person to person, comprised by the specific tissues and issues of each brain. Therefore, we create an other symbol system, language, to translate between these. It’s kind of like the same OS running on different kinds of hardware: The programs are the same, but the metal that interprets them is different, and sometimes this causes problems. Realistically, the languages we use are prone to a lot more error than actual programming languages, relying a lot more on abstractions and inferences. Much gets lost in communication. It remains to be seen whether this aspect of language is feature or bug.

We have another language we created, one that’s not prone to losing information: Mathematics. The only thing that makes mathematics useful and relevant is that it’s possible to convert real world systems to mathematical systems, operate on them as mathematical systems, and then convert back to real-world systems and have the effects translate perfectly.

Couldn’t we do that with any internally consistent system? Actually, we have: Geometry is a discipline separate from mathematics, though they are often used together, and itself represents an internally consistent system. Perhaps the different instruction sets of computer hardware could be regarded as such, though they are so mathematically grounded and implemented that it is difficult to separate them from the field of mathematics. It’s scary to think, though, that maybe we missed one. Maybe there’s an internally consistent system of symbols that, if we were to use it, could completely open up a whole new fields of thought. Maybe there are an infinite number of such systems, each one boundless in its applications and implications.

It’s interesting how, viewed through this lens of internally consistent simulations built of symbols, the mathematics we use start to resemble the stories we tell. We craft a reality that operates on its own internally consistent rules (build the world), operate on it (tell the story), and then translate that back to our own world (find the message/moral). Mathematical problem solving is a form of very specific parable for solving very quantifiable problems.

And now we have the video game, which exists with one foot in each world; built on mathematics, scripted by storytellers, a literal world of possibilities waiting to be expanded. What could we discover, as we did with storytelling, as we did by math and geometry, with the parables these worlds could tell us?

EveHeader

I worked on two major things this month. First was the rolling animations, which are the two most complex animations in the main character’s animation set, with the possible exception of the running animations. I’ve gotten better at doing animations so the work moved faster, but these two just have an awful lot of frames and each frame is different enough from the last that there aren’t a lot of shortcuts one can take.

crouching-roll-left crouching-roll-right
You can also see that these are two of the most different animations of the left/right flip versions, so again they defy shortcutting for that reason as well. These animations, with their high rate of contact with the ground, raise an interesting issue: Right now, all of the main character animations have a cyan outline to make sure she pops against dark backgrounds – perhaps unnecessary, but it seemed like a good idea at the time. However, the outline disappears where she contacts the ground, which is usually fine because she only contacts at a relatively narrow point. However, with the roll animation she makes contact all along the ground, especially while her hair drags across it. It looks fine on flat terrain, but on slopes or coming off of a ledge it’s obvious where the outline ends. Of course the animation looks a bit off in other ways at those moments since it kind of assumes a flat ground surface, but that’s by far the most noticeable. I still haven’t decided what to do about that. Maybe I should remove the outline and create a programmatic solution, see if I can bang out some code to make her pop out the way the outline does. Or maybe that’s all unnecessary, maybe the white cloth will make her show even on backgrounds where her darker tones would otherwise fade in. Or maybe I should bump all the animations up a pixel, extend the outline underneath them, and then make it so in-game they all draw one pixel lower. Not sure yet. I guess the smartest thing would be to start experimenting with just removing the outlines and then go from there.

The other part of the game I’ve been working on is a stone tileset. You may recall me working on stone before, and though I decided that weird wet-looking tileset worked fairly well in the cave area, it looks pretty terrible outdoors amidst the grass. It took several days of experimentation to find a stone tileset that looked good outside, and it turned out that restraint was key. Most stone, it turns out, is basically the same color as itself: Adding a lot of details and cracks made it look like ruined bricks or stone blasted apart by some catastrophic event. However, creating blocks with just a bit of patterning, either something kind of rough and scaley for uncut/broken stone or something almost flat but with slight patterning for that more man-made look, really seemed to do the trick. I also took the technique I used before of creating different lighting levels and using them to sort of draw a three-dimensional looking chunk of rock out of sets of simple tiles. There’s still flaws in the result, but I am quite pleased enough with it to table it for now until the rest of the game progresses to the point where its flaws are more noticeable.

stonetiles005

For the next month I’ll probably be focusing on a) creating attack animations, b) creating transitional tiles so the stone tiles actually fit into their environment, and c) developing some of the early levels to actually use all the tiles I’ve been making and look decent. I’ll also need to start seriously considering how to go about enacting the ideals espoused in the Problem Machine blog post earlier today, but that’s going to be a long road and I’m not sure what shape it will take yet. Still, lots to look forward to!