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

So, I stayed up a bit late last night looking into DOT3 bump mapping and multi-texturing effects. This book explains how to do it. The Crazy Bump software would generate the DOT3 images. I’m not entirely sure if this would be worth it, or if it would even work or not. So I’m going to put the actual implementation of this towards the end of my TODO list. I’m happy with how the game is looking, and I’m sure those features would make it look even better, but I don’t need to get those done right away.

Now I’m thinking over what I need to do in terms of a level editor. I will make the game have two layers, one will be the map layer, and one will be the “codes” layer. The map layer is the walls and floors. The codes layer is the position of the lights, guards, and how things move around. Right now I’m building a list of what needs to be in the editor, and then I’ll start coding it up.

.. time passes ..

Things have gone pretty slowly today, but I’m getting a few things done tonight. I’ve got my tile type definitions in another JSON file, and I’ve got those loading. Really, it would have been quicker to do it all as a C++ definition, but I’m going for the whole “make the game a little bit extendable” so as to encourage a bit more modding in the future 🙂

Here’s an example tile definition:

{"n":1, "name":"floor", "type":"none", "value":0, "view":"floor"},

So, here’s a level .. pre-editing. This will get much more exciting once I add editing controls. This screenshot represents a few hours of code cleanup and prep.

Anyway, I’m going to try and get some reasonable sleep tonight and I’ll try and get the level editor up and running tomorrow. At least for some minimal definition of the word “up and running”.

-Phil

First off, I did a bit of bug fixing. I improved my panning by mouse drag code a bit by using gluUnProject (the same code I’m using to pick a tile with the mouse.) Before I was just kinda guessing how to pan so it wasn’t very accurate.

Next off I noticed in yesterday’s screenshot that all the tiles had lines between them. I found that this was because I’m using a 256×256 texture which I’ve now added to a texture atlas. So when GL mipmaps it down to a smaller size, the blank area between textures is getting used a bit. This forum thread seems to cover a number of options I have. The simplest solution for right now was to move the “wall” texture out of the atlas, and just leave the sprites in the atlas.

Updated screenshot. I have the walls set at 0.5 height for the moment, but it shows the fixed textures. I also added variation in the darkness of the tiles to give it all a dirtier look.

Due to high demand, I decided to work on the textures a bit more. I found that www.cgtextures.com provides a huge library of textures! I’m using a few of these to give the game some pizzaz. Here’s an updated screen shot:

And with wall textures and ceiling textures ..

And now with windows!

And now with a guy trapped in a box! This is actually the cursor, so when you are trying to walk to some destination this shows you where your mouse or finger is hovering.

And now with some always-on shadows for the pillars so they look attached to the floor. I considered having dynamic shadows for everything all the time based on the other in-room lighting, but that would get more complex than I care to deal with and doesn’t seem overly necessary.

And NOW with multiple lighting sources! I turned off some of the shadow features for the moment, but I’ll probably try and figure out how to re-enable those later.

.. and that’s about all I can manage for one day! Thanks everyone for the feedback, the encouragement to go after the visuals a bit seems to have paid off nicely!

-Phil

I’ve done a bit of further improvement of the lighting code. I think the lighting will end up relating to the game mechanics somehow.

Next up – to finish up the idea I was talking about yesterday, having a proper texture atlas system. I ended up using jsoncpp for my json loading in C++. This worked very well. This is a vast improvement over how I did it in Galcon / Galcon Fusion. In those games, I generated C++ code with defined values for each image / texture. And I had generated C++ code with the structures for all these things, so everything ended up getting baked into the binary, and was very “undynamic” (it also added a considerable amount to the compile time, and in certain compilers – MSVC, I had to change some oddball stack settings for it to even work.) By using JSON I’m avoiding all kinds of nonsense and loading everything is just as quick as ever.

To show off this milestone, here’s an updated screenshot. I adjusted the lighting a bit more, to make the basic level of lighting a bit more 3D looking.

Tomorrow I want to have a basic editor up and running so I can save and load levels. The editor might end up being available in-game, so I figure I’ve got to get that feature in from the start. Then on Friday I’ll try and get actual gameplay happening. Thus leaving the entire month of October for the last 10% 😉

-Phil

Bockini Tournament Oct. 3

This iPhone / Android tournament will be an individual tournament, broken down into two game modes – 2v2 and FFA. We will be organizing groups of 4 for the FFA round, you will play 5 games total. For each win, you receive 3 points to your grand total. The next round is a 2v2 game-mode with randomized partners. You will play first to 15. For each win, you will receive 1 point. For more information and to join the tournament, click here.

New game development blog!

As of yesterday, I began work on a new game! This is going to be a crazy month as my deadline for completion of the game is OCTOBER 31st. As you can see from the picture, I’ve already made a handful of progress for just 2 days of work. You can read more about it here, and watch as I do daily blogs all this month covering my progress. I definitely want feedback as I progress, so be sure to tell me what you think. -Phil

So I stayed up late last night getting the lighting working. Turns out I was doing my gluPerspective and gluLookat against my MODELVIEW instead of against my PROJECTION matrix. Here’s the result:

Now I think I’m going to try and get a bit more texture variety, windows, height variety, thinner walls, some torches, and some shadows. Didn’t get all this just now, but here’s an update:

Now I’m working on switching from dev under linux to dev under OS/X and XCode. The Linux dev has been tough because with VMWare Fusion I don’t get GL under linux, so the framerate is pretty bad. I had an old SSH -Y trick that tunneled the GL back out to OS/X, but that seems to be even slower than software rendering today. Maybe it’s just time I embraced XCode and tweaked the key bindings a bit to suit myself.

Having done that, and tweaked a few settings, it’s time to start loading up data from files instead of inlining all my level data, etc. I think I’m going to give JSON a whirl for this project, since it should make handling all this pretty straight-forward. It also is supported in just about every language, so I can use my python scripts for generating texture atlases and fonts and have them just spit out some JSON for my code to load up. I had also considered sqlite for this purpose, but I think in this case, a database isn’t quite the right fit.

I think sqlite is a good fit for when you need to store CSV type data, except you want it packed. It’s particularly useful if you’re going to be storing a larger amount of data. In this game, the largest data store will be the level itself, which I can’t imagine will be much larger than 200k or so. sqlite can handle huge amounts of data and it’s quite efficient for that, but it’s also a database so you have to access everything using queries, which can be cumbersome if they aren’t needed.

Using python to generate the atlas does give me an excuse to pop back into linux for a while though!

-Phil

10:30am – I have achieved the classic black screen. This is a good start. I’m using this opportunity to take all the various cross-platform code I’ve written and clean it up a touch and put it in files that are totally separate from my game code. So, thus far, I’ve got my “initialize a black screen” code in a separate file. As well as my event handling. So far just desktop support, iOS will come later.

I’m also using a Makefile with automatic dependency generation this time around. I got a snippet from Mike Kasprzak to do this about a year ago, and it seems to work pretty well. Clutters up all my folders with .o and .o.d files, but I can cope with that. (His version did something smarter like sticking all those files in a separate folder, but I broke it.) I only use this Makefile for my linux development, which is where I’ll be doing all my dev.

10:45am – Slight distraction, Unity 3 has been released, though there is still an extra day to buy it on the pre-order price. I must admit, coding this whole game myself does sound a bit like work, and using Unity might be a ton easier. I’m downloading it so I can give it a quick eval to see how much has changed since Unity 2.x.

11:15am – I now have textures loading and being displayed on the screen.

11:30am – Unity 3 download complete, checking it out.

12:00pm – Got intimidated by how fancy it all seems. I’m just looking to make something pretty simple here.

12:30pm – Working on setting up the basic state engine. Trying to do something that won’t require the use of reference counting.

Upgrading the game to isometric was pretty straightforward. I just had to render the sides to all the boxes and do some gluPerspective / gluLookAt stuff to get the game view happening.

2:00pm – Got a basic 3D isometric view displaying.

Now with soldiers! And box picking! And scrolling!

Spent some time later on fiddling to get the perspective just right, still need to work on that s’more.

-Phil