Been working on a handful of minor tweaks and I created a few new levels.

I’m a bit at a vague point where I need to decide what my next few steps are. There’s an endless list of minor things that I can do, so maybe I’ll carve away at those for a while. I also need to start thinking about what I’m going to do to get the graphics up to the level I want.

I did add in an overhead view for the level editor. This makes designing layouts much easier. (It also makes playing easier, but less awesome looking, so I probably won’t allow it in-game, as it makes it a bit too easy to see what the guards and everyone is doing.)

In that shot you can see me experimenting with different colored lights. During the afternoon I spent an hour or so messing with the guard AI to get it “just so” then I created another couple levels. And to finish off the day, I’ve added in the coveted DATA CARTRIDGES!!!

Anyway, the core game is getting better all the time .. I might even start doing a beta or something soonish!

-Phil

So, I spent all morning / afternoon getting the rendering working properly, shadows working how I want, changing some of the game logic, adding more levels, adding sound effects, and updating the icons to something a bit more meaningful. Here’s where I’m at:

The question is, shall I submit this to the IGF? From doing a quick review of where I’m at, I need a few more levels to justify this thing as a game. Nan and I gave the game (as it stands) a complete review. The core gameplay is really solid, but the menus are totally rubbish, and the amount of levels and whatnot is pathetic. The graphics in-general aren’t where I want them to be yet.

I just feel like -even though- the judges might not look at the game right away and I might have another couple of weeks to submit something a bit more shiny, submitting this right now might be a bit weak. I can imagine an early judge looking at my entry saying, “Gee, that Galcon guy sure is a time-waster.” I don’t really want that.

So, I’ll be forging along in the October challenge, and if this game does really come out hot, I’ll submit the released version to the IGF next year. Or who knows, maybe I’ll hit up some other contests with it in 2011!

-Phil

So, today my main goal is to build a few levels for this game! Rah! (My title for this post was originally “Building Levels”). But as it turned out, I did very little of that. Instead, I improved and fixed a bunch of broken things.

But first, I added in zlib compression of the level data. This will keep my sqlite3 database nice and small. Worked super easy, took about 2 or 3 extra lines of code. I might even use zlib for my rewind feature, just so I’m not using 2MB of memory for no good reason!

So, I keep on coding here, and I’m finding that in some oddball edge cases the pathfinding code is failing. This is kind of painful. I may have to write up my own A-Star implementation.

.. time passes ..

I did, and it seems to be pretty solid and fast. I even made it pretty “generic” so it might be useful in the future. Maybe I’ll do a post with the code, as I’m pretty pleased with how it came out. I use STL containers for all the internals and it seems pretty zippy even in bad cases.

The next mess I decided to clean up was my rendering engine. As it was, I was making some 10’s of thousands of GL calls. Really. During playing the game this meant I was using about 63% of the CPU. I adjusted my code to use large VERTEX_ARRAY batches, and whatnot, and got it down to a handful of GL calls. Now I use about 8% of the CPU. We’re talking about a 8x gain in speed here. Definitely worth it.

So, I didn’t get done what I wanted to get done today, but I got a ton of other pretty important stuff wrapped up, so I’d call it a win. I’m taking off Sunday, and Monday is the IGF deadline. I’m going to try and get something submitted, even if it’s a very basic game. Who knows, maybe they’ll like it! I’ll definitely be sending in updates to them almost daily until the game is done, so I’m hoping the judges will actually see the game when it is in a more finished state.

-Phil

So today, I’ve got a long list of cleanup items I’m doing. Then tomorrow I’m going to create a bunch of levels. Then on Monday I’ll package it up for the IGF. Madness ensues.

So far I’ve been working on reducing the memory footprint of the game. Now the whole game takes 2MB of data, and a single level takes < 64k of data. It's good to keep things trim! I'm also fixing a bunch of mundane bugs / minor issues. In the meantime I've created a main menu. So, yeah, there's a reason that I'm going to be rounding up an artist pretty soon 🙂 This is not "teh awesome"!

Okay, my big goal is to get the Build section working. The user has to be able to create new levels and edit their old levels. My brain is melting a bit, but I think I can manage to get this done today. I’m going to be using sqlite3 as the storage system for the levels.

A lesson was learned today in KISS. I was having all kinds of confusion in my brains about how to handle some state transitions. Then a pal of mine (Mike Kasprzak) said: “I have a 1 level state stack” .. as opposed to some kind of complex stack system or whatever. He ended with these wise words:

<PoV> yeah, it’s all you really need
<PoV> each menu option can go where it wants to go, but parent lets you remember 1 level deep, like whether to return to a pause menu or such.
<PoV> anything more than that is probably too complicated for the user too

That’s the truth. Anyway, thanks to that piece of advice, I was able to get to my goal for the day! I’ve got my level editor integrated into a level-preview list whereby I can manage a number of levels (and thus, create a game that has more than one!) Here it is.

Anyway. Tomorrow I’m going to be spending some serious time churning out levels!

-Phil

So, today, I’m working on getting the game fully working. I’ve added a win condition and the resulting explosions!

I’m ending up doing a little bit of work on my OpenGL GUI today, I’ve got to get it working somewhat so I can manage level meta-data (title, intro text, music, etc.) I could just skip that for now and do something else, but I think having the level editor working from the start is important as that’s going to be a key feature of the game.

I’m keeping everything really big-sized so that if I decide to do a iPhone version of this game, the menus will work without any notable alteration. I’m glad that I’ve got my old OpenGL GUI code from Galcon, etc, because writing GUI code is always quite a bit of work! I’m doing a bit of updating of this code as I go to make it easier to work with, but no major changes.

Now I’m going to expand the game to be able to save / play multiple levels instead of just one. Now, in a more, tomorrow kind of way, that is.

-Phil

So to start off the day, I had my wife Nan beta-test the level I created yesterday as well as create her own level in the editor. I now have a list of 20 items to resolve. Oh boy! One really handy suggestion was enhancing the level editor to show all paths all the time. This makes it much easier to see what is happening. (I’ve also added “undo/redo” to the editor!)

So while watching Nan play, I found that she was dying pretty often. The game is pretty challenging. So I’m working on a rewind feature for the game. The core data takes about 60k, and I want to rewind 10 seconds. The game is at 30 FPS. So a rewind at 5 FPS would be 60*10*5 = 3MB of data, not bad. I originally had it going at 15FPS, and that was 9MB of data, which seemed a bit excessive to me. I could do better rewind stuff, but I’d have to write up some basic binary diff code, or something. Which seems, again, excessive considering what I’m trying to accomplish here. Anyway, it has been accomplished. I should post some video sometime. But in the meantime, here’s the lousy pause screen that has a “rewind” option on it to “prove” that I’ve added it.

Along with all this, I did a handful of other really minor things today, but those were the two coolest, I think. In the next few days I’m going to start building some levels so I have something to submit to the IGF that’s at least semi-playable. I think I’m going to hold on the iPad conversion of the game until after the IGF submission.

-Phil

Just figured I’d mess with textures for a few minutes this morning:

Interesting results, not my favorite though! I do think I’ll have a few texture set options for the game when it is finished. That will add some needed variety.

In the meantime I’ve added guard shooting and player dying states. Got those done. I think I now have all the game logic more-or-less working. I’m sure there are a few rough edges, but I think it’s time to build a real level and give it a play!

Here’s a explosion. This is the artwork from the original python game. It’s a pretty nice explosion, but I’ve really got to get the lighting working. I’m also thinking of swapping it out for a particle system.

This one is vastly improved, using GL_ONE to render and adding a light source for the explosion.

Okay, got distracted by polishing the graphics. Time to make a level, for reals! Here’s my first level! It works!

Anyway, that’s about all for today. I might make another level later on, but we’ll see …

-Phil

So now I come to needing to make the guards work proper. Mostly this is a ton of muddling around with arrows and pathfinding.

I think I’ve got it working adequately. Maybe. The trick is to make the level editor work in such a way that it gives designers the most options, basically. Now a guard can stand still, a guard can walk from A-B, and a guard can walk from A-B-C and have loops between B-C.

Now I’m just adding in more guard behaviors (dying, running, shooting) which bring the game that much closer to being playable!

One of the tricky things is figuring out what the guard can see. I’ve got a pretty fancy bit of code that figures that out for me. Seems to work well, I hope.

Anyway that’s all for today. No new screenshots, nothing visually changed. Might be a quieter week on the screenshot front until I start switching over to fancier graphics.

Tomorrow I’ve got to get the guard actually shooting, and add win and lose conditions and tweak the bomb features a bit.

-Phil

So that horrible code that I posted yesterday, yielded a pretty negative response from the #ludumdare community. They were right, it was an abomination. I’ve since replaced it with rather mundane for-loops that actually work. The thing about the code I showed the other day is that it would not work nicely during a screen rotation, and I do want the user to be able to change the perspective they are looking from.

Since I’m using sprites for all my characters, I also had to add some logic to get them to rotate proper when the user changes perspectives. This worked out pretty well. You can see the jerk between different angles because I only have 8 angles for each sprite, but it seems good enough. No screenshot because it’s hard to show without making video.

In other news, I’m trying (again) to embrace XCode as my editor. It gets to be rather silly to switch over to Linux/Kate to edit files then back to XCode to make my builds. I’m trying to just get used to the default XCode keybindings as well.

One feature I just added to the editor was “arrow prediction” which shows you the path that is along where an arrow is pointing. This is a huge help when designing complex paths because it’s pretty easy to lose track of exactly what row/column you are supposed to be tracking.

Heh, these steps aren’t real, I’m just messing with isometric perspective. From other angles they don’t look like steps at all 🙂 All the same, I’m pretty pleased with how the lighting is working out in this game!

The little touches take some time to get ’em all just right. Here I’ve made it so that while in the editor, the characters are facing the direction they will start walking.

Our hero, next to a freshly created crater! One could argue for considerably fancier graphics at this point, but one could also argue that this gets the job done.

Anyway, I never did get to writing the guard logic or getting it running on the iPad. I guess those are next week! The IGF deadline looms, I might just submit whatever I have at that point and update every few days as the game actually comes together. I do hope by the end of next week to have the game fully working with a few levels.

-Phil

So, I’m filling out the game logic today. I’ve now got the display rendering buttons for the types of explosives you have along with an indication of how many you have in your pockets. No more “unlimited bombs” for you!

A special bomb effect:

I’ve got a few different bomb types which are all pretty exciting. The main bomb type is one where you drop the bomb run off and then press a button to explode it. (As in the original game.)

.. After a bit of a break and some thinking, I’ve got a pretty long “TODO” list now .. there are of a ton of little things that I need to have working nicely before I can really create a real level ..

One of them was defining a padding edge for the level. This is a sanity feature to avoid anything blisteringly dumb happening. It as a 4 box wide edge around the whole level. It also gives the user a visual cue as to how far they are from the edges of the map when they are editing. The edge won’t be shown when the game is in play.

I’ve added the ability for lights to roam about. And here’s a cool looking screen that is the result of me trying to get my renderer to work on larger level sizes:

I eventually got my renderer working, but I produced some of the most awful looking code in my life while doing so. Look away if you can feel pain.

    for (int iy=i1,jy=j1,yflag=0; yflag!=3; iy+=sign(i2-i1),jy+=sign(j2-j1)) {
      if (iy == i2) { yflag |= 1; }  if (jy == j2) { yflag |= 2; }
      for (int ix=i3,jx=j3,xflag=0; xflag!=3; ix+=sign(i4-i3),jx+=sign(j4-j3)) {
        if (ix == i4) { xflag |= 1; }  if (jx == j4) { xflag |= 2; }
        for (int ia=0; ia<2; ia++) {
            int x = iy + ix - i2  + ia;
            int y = jy + jx - j2 ;

Anyway, I think that's all I can handle for one day. Until tomorrow!

-Phil