Sometimes days and days go by where I just try to fix these tiny bugs that have been in the game engine for months and I’ve just always thought “Oh yeah, I understand that bug, I’ll just fix it next time I’m in that part of the engine”. Then you get back to that part of the engine and you realize you have no idea how any of that code works anymore or why it’s bugging out the way it is.
Even with the amount of comments in my code, I sometimes spent a large chunk of time actually re-learning how I managed to make something work the first time so I can actually get down to making it work properly the second time.
For something slightly more entertaining, I went ahead and removed the old “Damage popup numbers” that were floating out of creatures when you damaged them. They were way too big and ugly, especially in hectic situations. I replaced them with blood particle effects with no real damage quantifier to let you know how much exact damage you’re doing. Weapon power is made clear elsewhere in the game when you are equipping abilities, so I think for the in-mission effects the blood is a much better result.
It also looks pretty cool when all hell breaks loose. In these videos, my creatures have a massive amount of health, probably more than you’ll ever actually achieve in the game. It’s just to test it all out.
When the player interacts with the UI, I want it to be really clear what’s going on. When you click on a creature’s portrait it snaps onto your mouse cursor before sliding back to where it started; the player needs to know that they can click-and-drag that portrait. When you hold down the mouse button on the portrait, any “ability” icons next to the portrait curl up and hide behind it to let the player know they’re dragging the creature and all their abilities along too.
If you release the mouse button in a useless place, everything smoothly returns to where it started to let the player know clearly that their action had no effect. If they drag the portrait near an appropriate resting-place, all the other portraits near that place will move aside to make room for it, even if the player hasn’t released the mouse button yet. If the player moves the mouse away from that resting place, the portraits will all move back to where they were, showing that you’re no longer considering dropping your portrait in that place.
Everything on the UI needs to move smoothly, deliberately, and intuitively to make sure the player understands exactly what they’re doing with the elements they’re interacting with. I hope I’m slowly getting close to this goal.
I spent all of New Year’s Day making the drag and drop mechanics feature-complete for one of the in-game menus.
It’s been amazingly more complicated than expected to implement something that I use in my OS and other games every day without even thinking about it. When you pick up a sprite to drag it somewhere, you have to record such a huge amount of information about what you’re doing and what you might possibly plan to do with that sprite.
I use the mouse cursor as an entity which records what it’s carrying, where it started carrying it, where it’s considering throwing it to, what it’s doing with it at the moment, and about fifteen other things. When you release the mouse button, the game has to check so many things regarding “Is this a good place to drop this?” that it’s amazingly easy to leave loop-holes that can be exploited and result in duped items or creatures.
Another important thing is to only check certain “drag and drop” conditions if you actually need to – because you’re looking at doing a huge number of checks on a per-pixel basis, you can’t do that every frame all the time; you need to turn certain features on or off depending on whether they might possibly apply at any given time.
In the end, everything turns out very satisfyingly tactile and you can kinda “throw” objects around between windows in a smoothly rendered way. I like the result so I made a little video about it.
Most of the work lately has involved changing the way the player is shown how they’re interacting with the game. Use of abilities now has a totally different flow where that player can see how much ‘Juice’ their ability has left and the ability fails when they run out; an ability ‘Upgrade’ system ties into this concept.
I’m also trying to massively improve the menu system so it’s not so much about clicking on tiny little buttons, instead being a mostly drag & drop interface. I want to keep the menu system easy and also make it extremely clear to the player exactly what they’re interacting with.
Drag & Drop design is an absolute nightmare to work with, but it looks tactile and sensible when it actually works.
So I talked about particles the other day when I pushed the prototype into the game engine and got them working, but I had to do some work to make them really “exist” in the game world. The first thing to do was make sure you couldn’t see them through walls, and I’ve now given them the ability to “collide” with the floor.
As an example, I’ve made “Bullet Casings” eject from guns fired and bounce on the floor before coming to a resting stop and fading away. To do this, I had to make the X axis inertia inherit the direction the creature was facing when he fired the gun to make sure the bullet fires out of the “back” of the gun. On top of this, the particles are told, when they spawn, how high above the floor are they. The floor is defined as the bottom-most pixel of the sprite that emits them.
Using this information, the particle can tell when it has hit the floor, however, because the game camera is skewed isometrically, the floor is angled. If the creature is facing North or East, the floor behind the creature is tilted “downwards”, otherwise it tilts “upwards”. The further the particle has traveled horizontally, the further the floor has skewed.
With much fiddling, bullet casings now bounce along the floor as per the rules of the isometric camera, and any particle can follow the same rules with a simple “CollidesWithFloor” flag.
That was certainly a whole lot of words that probably make no sense out of context, but I’m still pretty happy with the result; I’m wondering if I should make particles bounce off walls now.
So, last post I mentioned that I had finished off the particle emitter system in a prototype environment (literally a blank 2D canvas) but the next job was to take those particle emitters and drop them into the game environment. I had initially through that I would just overlay the particles over the top of the game scene and it wouldn’t be all that bad if you could see particles through walls; in-game walls aren’t taller than people anyway so it should be okay, surely.
But it wasn’t okay, it looked terrible.
In an “Isometric” scene, zSorting (the order things are rendered in so behind/in-front looks right) is done from the top of the screen to the bottom in linear order. In-engine at the moment, only 1 object (a wall tile, a person, a door) can be on 1 tile at a time, so the engine just renders whatever object is on whatever tile starting at the top of the screen down to the bottom. However, there can be 2000 particles on one tile, and incorporating them into the zSorting populator and renderer took some fairly heavy changes to the way it works.
Every particle has to remember what the y-axis of the tile was for the emitter that it came from and then gets inserted into a massive stack in order of y-axis, with up to 2000 other particles sharing the same y-axis. So there’s an array called ParticleSorter(200,2000), the first dimension is the y axis, and the second is the particular particle that’s on that axis. Once all the particles are added to that array stack, the stack is then read from during the zRenderer routine.
It’s not perfect yet; particles need to be given a concept of “floor” for them to land on, but the rendering is working and it seems to be fairly pretty so far. Here’s a video where you can see a fairly early implementation of breakable doors with particle effects.
I’ve been working on lots of little mathematical bits of graphics for UI stuff and also simple in-game animations. You’ve probably seen the “Spawn In” animation where people seem to drop out of the sky, which is all animated procedurally, but I’ve now added a nice little line-graph UI element for a new game system and I’ve just finished the particle emitter system.
I uploaded a video showing the particle emitter system being built from scratch if you’re the sort of person who likes to watch that kind of thing. Also, an irrelevant animated gif.
I’ve been making lots of improvements to the game engine over the past couple of weeks and I just wanted to shoot out a few videos showing some of the new features that have been implemented.
The first is the new, smooth vision cones. Now, when a Creature wants to look somewhere, it isn’t able to instantly look at that new direction; it has to turn its head smoothly. This is fantastic for making sure creatures notice other creatures standing next to them when they’re changing direction.
These are the new class of unit called Sentry. They’re exactly the same as the “Enforcer” class (as in: they have guns, they run at stuff and shoot it) but they can be linked to a trigger and HAYWIRE!ed. If someone HAYWIRE!s them, they change their “Team” to the hacker’s team and immediately fight on their side. The one in this video has 9999 health so he easily wipes out the entire level.
And finally, this is the new “Spawn-in” mechanic and graphic. I can add creatures mid-campaign now with a little “drop pod” animation. You also notice the ground shake a little when they land thanks to the new Camera.VibrationStrength setting. Also, the game crashes if more than 20 creatures try to pathfind at the same time.
The last couple of months have been a powerful push, with a hopeful goal of reaching an “Alpha” for the game (working title: BA Project).
I’ve got a list of about 20 items that need to be implemented/fixed before I’m happy to call-it at alpha. Once I get things to a state that I’m happy to call “Feature Complete”, I’ll go ahead and put up a page on this blog dedicated to the upcoming game. I haven’t been posting much information about functionality or implementations lately because most of the recent work has been directly related to creating game functions rather than barebones engine features. I’m saving a lot of the information for a time when there’s actually a game to go along with it so that there will be context for most of the gameplay concepts.
In the meantime, have a look at the latest #screenshotsaturday from my twitter.