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

So .. it’s been a crazy day here, so not a lot of dev got done. But I did just add the ability for the user to drop an unlimited number of bombs. It looks pretty messy, but it does indicate progress!

Oh, and the function that I call to drop a bomb is:

void logic_bomb(Game &game, int b);

Which I like. And to follow it up, here’s a tiny explosion’s resulting floor damage:

I’m not sure that I’ll get much more done today .. but I feel that was a pretty good go of it. Next up is getting the various bombs working how I want and then doing some game cleanup, and then testing it out on the iPad, so I know how much I have to tweak the graphics code to get it to run at speed. Then I’ll be ready to move onto “making tons of levels” !

Though, somewhere in there, I’m going to have to do a ton of extra work on the guard AI, it needs to work well regardless of how the map is destroyed by the bombs 🙂 Not an easy task!

-Phil

So far today I’ve just been doing some cleanup in my code. I’m about to add a “play” mode so I can try out my levels, which involves having information easily available to know what is solid or not. I’ve updated my tiles.json file to include that information on a per-tile basis, and I’ve used that along with some other things to clean up my rendering code as well.

I also am considering having the ability to rotate the screen 90 degrees. This way you can see behind walls easier. I had considered other options like a “short wall” mode or whatever, but it all started seeming really un-cool. Here’s a picture of the short-wall mode:

You can see really easily in this picture how light can leak through walls (those short ones). I haven’t decided on my solution to that problem yet. I think I’m going to have to get this running on the iPad, maybe at the end of this week, and evaluate how fast it is running and if I can afford to do more complex lighting.

Was about to get after getting the game playing, but I’m finding that jsoncpp is crashing during shutdown of my program. I’m getting a traceback like:

pure virtual method called
terminate called without an active exception
Program received signal: “SIGABRT”.
(gdb) backtrace
#0 0x97803ef6 in __kill ()
#1 0x97803ee8 in kill$UNIX2003 ()
#2 0x9789662d in raise ()
#3 0x978ac6e4 in abort ()
#4 0x975b7fda in __gnu_cxx::__verbose_terminate_handler ()
#5 0x975b617a in __cxxabiv1::__terminate ()
#6 0x975b61ba in std::terminate ()
#7 0x975b6753 in __cxa_pure_virtual ()
#8 0x00016cd4 in Json::Value::CZString::~CZString (this=0x33a180) at /Users/phil/code/idynamite/osx/../ext/json/json_value.cpp:199
#9 0x0001e06b in std::pair::~pair (this=0x33a180) at stl_pair.h:69
#10 0x0001e089 in __gnu_cxx::new_allocator >::destroy (this=0xbfffe8ff, __p=0x33a180) at ext/new_allocator.h:107
…

Turns out this is due to some sort of bug in jsoncpp which makes it not work as global variables. Which I guess the old notion that global variables are bad news is hard to get away from. So I wrapped up all my json away from being globals and it works fine now. Less globals is certainly a good move, whatever the case.

Next off, I’ve now added a toggle to switch between editor mode and play mode. The editor saves the level state so that whatever happens during play doesn’t permanently damage the level.

With a bit more work, I’ve got the “play” mode starting to take shape. The player now walks to the tile you click on!

And now I’ve got a guard running around me like a crazed maniac. The arrows on the floor are special codes that tell the guard where to run.

I’ve also got animation going on the guards and the player, just sorting out some bugs on those. Tomorrow I hope to get a win condition and a lose condition and some more explosives going 🙂

-Phil

So, today is off to an exciting start as I cut-n-paste some of my font code from Galcon and get it wrapped up how I want it for this project. This took me about two hours, which is kind of a long time .. but .. I had to do a fair bit of reshuffling to get it working in my “new” framework. Again, all the data is stored in JSON files, and things are a bit simpler in general.

Next up, some basic GUI stuff. I’m going to use the GUI toolkit I made for Galcon, but I’ll be cleaning up the code a bit so that it plays nice with my new framework. I’m not sure how I’m going to accomplish this yet.

.. time passes ..

I just hacked it in. And commented out a bunch of stuff that didn’t compile right away, so as needed I’ll uncomment things and clean things up. I gave some brief consideration to using some other GUI or making a new one, but then I realized I’ve used this GUI in Galcon and Galcon Fusion and I’ve got it working on a TON of platforms, so it’s got a lot of little stuff in it that works really well, and it’d be a bit of a waste to go and start something new. I’ll just improve the code as I go, as needed, so to speak. Here’s a screenshot to show I’m doing something:

One thing about my basecode that is a bit weak is that it does contain a lot of C-strings instead of std::string .. I should probably work on upgrading my code to use all std::string a bit more than I do.

I’ve now updated my game to save and load the current level on exit. This way I can focus on adding gameplay to a single level that I’m editing.

First off, I’m now loading full animation of the player and guard, because I want to get my player walking around, then the guard, then add explosions. (Then there won’t be much left!) I’m not sure if I’ll be using the player and guard images forever or not, but I figured for now I’ll at least get something loaded and I can always change them later if I have time (and money) to do so!

I found and cut-n-pasted in a nice A-Star algorithm, which I need for both the users and the guards to walk around properly. It all seemed to work without much of a fuss, which is always nice.

After a couple hours of fervent icon creation, I now have the 32 icons needed for my level editor! Yessss!

The editor is now semi-functional. I am able to place objects on the level! I don’t have the icons at the bottom properly corresponding to the items though, so it’s a bit confusing for now 🙂 Next up is to get the in-game objects to correspond to the icons!

And here the level editor is 100% functional! Here’s a crazy looking level I whipped up in a minute or so.

I’m pleased with the days work! Next week: Game Play!

-Phil