So, feeling better means more inclination to work on my games. But, brand new job means I have a crazy couple of months ahead trying to learn the ropes. I’m going to break even at “not committing to too much blog” for a little longer. I’ve resurrected another project I had once been kicking around. This one is simpler with more recyclable components, including some skimmed from Space Fortress. I’ll throw up some pictures of that one later.

I remember that it was this overcomplicating of the sprite definition that got me into trouble last time. This seems to be my issue. I started working on hardcoding some behaviour, that will do!

I think it’s time to define a milestone where it is okay for me to park this project. I think the first one will be “in game units”, and I’ll break that down into some individual requirements, then knock them off.

Jamie kicked things off talking about priority queues. I like the idea of using priority queues for tasks. It makes the most sense. I had something similar set up in the old space fortress, which allowed the player to dig holes in the ground. When the order came in, a job was created (”dig this hole”), the workers would then subscribe to the job and would be fed tasks like “dig this square”, which in turn became “move next to this square”, “now dig this square”. It allowed for interruptions, such as “square is unreachable”, which tragically happened too often as rubble accumulated.

For the lower-level actions*. I think Ian has it with the hierarchically (a word I cannot pronounce) built FSMs. I’m going to take another crack at defining the worker with that in mind. I think I’ll let “falling” be a moving task, it seems counter-intuitive to suggest it is “idling without anything underneath you”. Especially since falling is a proven technique to move from up to down.

Regarding my obsession with those Booleans, I think Jamie has got it right by suggesting putting it into code. I’ll worry about XML expandability later. I figure a handful of hard-coded superclasses alongside some attributes can handle just about every type of entity in the game. That way I can still have my directory full of PNG and XML files for unit definitions.

Thanks again!

* Which are motivated by tasks, which are created by jobs, which are created from orders, which are created by the GUI based on user input (!) untangling that will be a future blog

Struggling with Structure

So, I think about what I want this generic worker to be able to do. When you start, it just stands there. When you order it to work, it moves to the work-site then works. By my reckoning, there are three states. Idle, moving, and working. I come up with the little DFA, and realize that the worker can move among these states fairly freely. In the figure, I didn’t connect moving and working, because I had already drawn it as a DFA, even though it could just be an array since transitions aren’t needed.

Then I started thinking “well, what does idle mean?” it means not-working. But what if the worker is idle but recharging, then it’s resting. What if it was wounded and is sparking about waiting for ro-bot repair? It could also just be waiting since it has no job. So idle just got more complex. Same deal with working (workers can do many things). Movement becomes interesting, too. Because if the worker has to walk half a mile, jump over a hole, climb down a ladder, then there are many types of ‘movement’. We need a little hierarchy!

So, suddenly, should there be states, substates? That seems a little nuts. But it also seems better organized than having all those actions on the top level. My other thought is that maybe in an RTS-style game, this is just how things look. When I brainstormed Tinyroidvania, I was also thinking along the lines of using FSMs to define player abilities. I noticed there was kind of a problem defining “state” that made good sense to me. I need to iron that out before I can go any further.

I think my problem is that I need to mix two different sources of state updates (environmental and input) and I worry that this will explode the complexity of my DFAs. Maybe I just need a new way to describe the capabilities. I’m sure it exists. First, I’ll try to explain what makes me confused:

I think my protagonist from Tinyroidvania should have very simple states: “Walk”, “Jump”, “Idle”. I convinced myself that the proper thing to do would be to expand that to be more specific. So I now have “Walk-Left”, “walk-right”, “jump-left”, etc… I somehow thought that not having a ‘left/right’ variable was a virtue. It would be complex, but pure!

Now I can define the character very easily in terms of a DFA. I can add transitions to “walk-right” from “walk-left” and the “idle” states on the input “PUSH RIGHT ARROW”. Beautiful, I think, I am so clever!

Now I start thinking “Well, any system worth its salt can support wall-jumping”. Meaning, when the player is against a wall, in mid-air, they can kick the wall and get a little hop. But, oh no! I don’t have a state called “mid-air-against-wall-on-left”. Nevermind the distinction between “falling-against-wall-on-left” and “jumping-against-wall-on-left”. I need a zillion bubbles in my FSM.

Writing this out makes the solution seem quite obvious to me. But since I can’t type it succinctly, I must not yet understand have it.

The FSM should only have nodes refering to the behaviour of the entity. Stuff the entity might control. Like what I have above “idle” (it doesn’t want to work), “working” (it is doing something), and “moving” (it wants to get there). The multitude of states I’ll never name should be a suite of variables, which are used to define transitions. All the fiddly bits (like, environmental cues including “feet on ground”, “underwater”, “against a wall”) can be worked into transitions, which become… boolean expressions?

if ((state == idle) && (  !feet_on_ground && against_wall )) state = wall_jump;

I think my brain stopped working. That doesn’t seem like the most elegant solution. And it doesn’t take into account all the different ways you can be idle. Unless… all those different ways are really just aliases for a set of those environmental booleans? Ugh, not for all of them. Should sub-state ‘falling’ really be ‘idle without ground under you if you aren’t floating’? There must be a better way!

Having proofread this, I realize some parts make no sense. When I revise it tomorrow on a juicy, well-rested brain I hope I’ll see the conceptual hole I’m falling into.

Space Fortress wise, I have been getting some boring-to-discuss sloggage into a sprite system done. I now have:

1. An entity system (to be discussed later) for loading definitions of in-game entities from XML files, entities being the things in the game world that aren’t dirt.
2. A sprite system, which manages those animated little bitmaps drawn onto the screen. The Artist class responsible for drawing entities creates a sprite for each entity. The ‘front end’ of an entity, also xmelly
3. Used an ordered list on Terraflubb

These things are very crude at the moment but will eventually be one of the most feature-rich aspects of the game engine. Hopefully, once it’s in place, I will be able to convince myself that it is not a ridiculous introduction of complexity but something useful. My goal is to have a worker-drone and a building entity defined and set up in the game soon. Fun stuff comes after that.

I am not getting distracted, but I know that the old Horror Mansion will be able to use most of the things I’m building now. If I keep on plowing ahead this way, I think I can revisit most of my ideas in the future and at least get to the prototype phase. If they’re not fun at that point, I can be satisfied knowing that I tried.

Meanwhile! I’m so close to finally doing the whole Model – View dichotomy neatly arranged in my brain. I think it is all set at the moment, but until I get it animated, I won’t be pleased.

Why Worry? Because you might be a poseur.

As I have expressed before, I love to say I am a game-development hobbyist, but I do not have any artifacts that show as much. I know how to code and how to create passable programmer-art, but for all my years of experience, I have nothing! This resulted in me telling myself “Make your stuff recyclable! How many times will you fail at collision detection?”. So I adopted a strict Model-View-Controller approach to game development. I figured that I would eventually collect enough Model and View bits to be able to throw games together quickly. I did this with a few failed projects, and I’m pleased to say it’s working well!

How Rob does MVC in games

Since I never really learned MVC in an academic or professional setting, only from reading little things about it. I probably have it wrong. I also read the Gang of Four’s book, but I should really have chatted about it with an expert. But this is how I’m doing it. I appreciate corrections and comments, I respect the software engineering skills of at least 2 of my known audience.

Model

The ‘game world’ lives in the model classes, which are the ones that represent the game world. In Space Fortress, that means the 2D-array of dirt which makes up the planet (a tile-based level) and a set of entities (I’m defining that now) which are all the ‘things in the game which aren’t the level’. So, buildings, robots, monsters, and pomegranates. My model classes are laced with accessors so that all the important (observable) parts can be reviewed by public methods.

View

Then I have my view classes, which are made up of persistent, Artist classes. I have a WorldArtist which knows how to read the level data out of the model classes (read only!) and an EntityArtist which knows how to draw the entities (I should say ‘knew’ how). The EntityArtist will have to keep track of the animations and all that. It also does the GUI (with what I would have named GUIArtist, but instead I used Thingle so I won’t complain). It collects input and burps output. It does not touch the model directly, that’s done through the controller classes.

Controller

I currently have no controller classes anymore. But since I’m doing an RTS, they will be probably presented in some kind of UserDesire Interface, so the view sees my clicks, boils them down to a desire, then tells the model what I wanted. So “Click on a robot”, “right-click on spaceship”, “select dismantle”, gets turned into “new UserDesire(”robot_1″, “spaceship_12″, “dismantle”)” and gets interpreted by the model.

Why that hurts

Sticking to that makes me seem anal (believe me, I am not!) and it feels quick awkard at fist. Maybe this won’t work with an action game, it might only work with an RTS, since they are effectively spreadsheets with the data scooting all over the place. Oh, it probably would, I just don’t want to think about it right now.

It’s nice to be able to do this:

guy.jump(); // model
guy.draw(); // view

But now I do:

guy.jump(); // model
entityArtist.draw( guy ); // view

This makes animation a pain! But as you figure it out, you feel better for it. At least I did! We should all thank electrical engineers for making processors so fast we can software engineer the hell out of our games. I suddenly really have to consider what is game-affecting and what is cosmetic. Animation is purely cosmetic, until the animation is of a guy rolling, and when he is in the somersault position, the bounding box becomes half-height!

This is where my brain dislodged itself a bit, because something obvious became apparent to me tonight, and I have some coding to do as a result:

Pixels mean nothing at all to the model. They become “world units” or something that has nothing to do with lovely little squares of light. In 2D games, particularily pixellated ones, apparently my favourite kind to attempt, they map perfectly onto one another. But I must break that bond! I want to be able to do a full 3D rendered version of my game by only changing the view classes. A ‘world unit’ of OpenGL has nothing to do with a pixel! It’s up to the view to map them that way.

Model-view mapping

So now, I have my fancy recycled Entity management system for the model. It contains bounding boxes for collisions with the environment and fellow entities. However, I also need a Sprite management system, for the view. Entities map to Sprites. I think I’ll cheat and create both out of the same XML definition for now. But as it stands, I have a bit of code that does both right now (since the mapping is perfectly 1:1) and it’s time to diverge.

Moral of the story, Rob now believes the following:

• Model is to View as
• World Unit is to Pixel as
• Entity is to Sprite

And with that, the last shackles of pre-MVC is shed, and I delve into awesome. Until the next shackle is revealed. It’s late now, but I think the ol’ noggin will sleep now. Apologies for the typos and adorable grammatical issues.

OMG Another one

The following morning I realize there is another in the series:

• Tick is to Millisecond

Today was my last day of school for the year, so I expect that I’ll start updating again shortly. The whole point of this blog was to post to it frequently, so that’s what I’ll do!

My next step is to move the old Tinyroidvania sprite-animation system (with XML loader!) into the game so the sprites will no longer be integers for an array of Textures. Once they know how to be animated, then we’ll have more interesting videos.

There was also a great big overhaul of the scene drawing code. Right now there are two drawing sweeps. First the tiles are drawn (the environment) then the entities (the things). Both of these sweeps are very crude at the moment, but their logic is pretty sound. It was a bit harder than I thought to get the entities to wrap around the x-axis. There are a few neat little special cases that had to be resolved.

In fact, I’m so proud of this, I’m going to stick up my first video!

Geek stuff after the break!

Nerds can see in the “sprites” section of the debug window, there are three little letters that explain how the entity drawing/culling/wrapping works. A is the primary drawing box. It’s usually the only one used in sufficiently big worlds. Then there is W which is the wrapping box, with an optional P box for awkward cases right at the axis… oh geez. I need a diagram to describe this. Nevermind, just know that it’s kind of clever!