Well, I’m still grinding away at the web integration today.

So far I’ve added in basic user tracking, this will keep track of how many levels a user has created for use in leaderboards. I’m not going to implement leader boards now, since I’m going to be tying into GameCenter and whatnot for those features.

Next up, I’m going to create a table to track each level win, so users can leave feedback (skulls and stars!)

With all that working I’ll be able to get queries going for various categories in the game. Like most popular, and newest, and favorites.

I’ve also added in error handling to the game, so if you have an invalid login, or whatever, it’ll display a message on the screen. It’s amazing how many little things I have to add to get the game all working “just so”.

Whew, nothing like a fresh coat of paint to make things look un-awful:

Anyway, I’m taking off tomorrow, but I’m going to try and “monetize” this thing on Saturday!

-Phil

I’m continuing to work on the sharing menus. A lot of this is “polish” type stuff, so there isn’t much to say. The challenge is figuring out how I want to store the levels and have the game work when an internet connection isn’t available. I want users to be able to play levels they downloaded previously. I eventually decided on just storing all the data in a single sqlite3 database. I erase old data when new data is downloaded. If the connection is broken, then nothing changes. So it should be pretty transparent to the user.

You can see in the level selector the “rating” and the “difficulty” indicators. I now have to add support to the game for grading levels once you beat them. I think I’ll do that tomorrow, and then I’ll try and set up a way to buy the beta!

-Phil

So, one of the big objectives in this project was to make it so users can create their own fortresses for their friends to storm! Here’s a screenshot of the “in progress” user level-picker screen.

I’m pretty happy with how that looks. I need to add scrollbars and stuff like that yet, but it’s mostly functional already.

Stuff for tomorrow:

– Getting the various categories working .. at least on a basic level, I might not have the web-backend queries fully developed immediately.

– Displaying the title of the category

– Decide on what categories make sense. Maybe these should be queried from the web API?

– Add the ability for users to rate levels

Then for Thursday, I’m going to try and set this up for beta-sale if possible! And start sending out requests for artists to help me finish the job!

-Phil

So .. I spent all day today getting some of my Web API up and running! Here’s some of what went into this:

– I considered using libcurl or some other pre-made solution for making web requests. However they were all too heavy-weight or did not support Windows.

– I ended up taking the code I had written for Galcon’s web API and cleaned it up a bit. I also wrapped it with a nice C++ wrapper so it would integrate more cleanly with my new codebase. I can now make web requests like this:

WebRequest r;
r.host = “www.galcon.com”;
r.request = “/somegame/api.php?action=dostuff”
r.post = string(“data=”)+r.urlencode(&game.data,sizeof(game.data));
r.exec();
while (!r.poll()) { … wait … }
results = r.get_response()

This is nice and simple and asynchronous. I am able to make these requests, and call poll() once a frame, and then once it’s done polling I can handle the results.

Since I had taken the time to do all this, I figured I’d spice things up by integrating some kind of analytics package with it so I could see where the rough areas are in my game. Unfortunately, no analytics package I found has a “super simple officially supported web-API” .. I may however give playtomic a whirl, it seems to be pretty simple web API calls from looking at the API code, but it’s really for flash .. in the meantime I’ve got a database setup that captures my tracking calls. But I’ll be looking at other options.

To wrap things up today, my biggest goal is to be able to share levels between players. Since I’ve got my web calls working, this should go pretty easily. It’s 3:30 now, so let’s see how long it takes to get this up and running. And, 3 hours later, I’ve got sharing working! Wooo! It’s still not quite as elegant as it needs to be, but it does work to some extent.

-Phil

Since this game contains a level editor, it’s pretty important for me to have the gameplay ironed out solid before I beta the game and have players creating levels. So I’ve been adjusting little things about how the bombs work and whatnot so that I don’t have to change much after the game is “in the wild”.

We’re coming to the end of the fourth week of dev on this project, and so far I’ve been really pleased with how things have been coming together. Not everything is perfect, and there’s a way to go before it’ll be ready for the final release, but I’m pretty hopeful that I’ll have a for-pay beta going next week (like Minecraft / Wolfire do.) The main things that will be done after that is bug fixing, graphics, and the single player campaign. As well as integration with Game Center or whatever.

Nan has noted that some of the levels I design are outrageously difficult, so I’ve enlisted her to design some easier levels. Difficult levels are challenging, but sometimes they just aren’t much fun at all. Getting the right balance between “challenging” and “infuriating” isn’t always easy. But I guess that’s where having say, 100 levels or so in the game is smart. If I only have 10 or so, the curve is going to be really steep. It’s okay for the last 10 levels of a 100 level game to be near impossible, but not for the 10th level of a 10 level game.

One of the things I really miss about python / PHP when doing C / C++ work is the lack of handy standard library goodies. I just spent the last few minutes rounding up a md5_digest and a base64_encode, base64_decode function for my codebase so I can start doing some web requests. I’m also going to have to re-hack my web code to work better, since CURL has too many dependencies, and there doesn’t seem to be anything else available, so I’ve got my own silly web request maker. Along with that I’ve got things like urlencoding, and whatnot, that I get to implement. A bit slow going.

-Phil

So I’m marching towards getting this game into beta. Fixing up some final items. The first one was I was finding that guards would sometimes get together into packs (all on a single square) and stampede. I’ve fixed that by checking for guards who are on the same spot going the same direction and having some of them wait a few frames before moving. This does a nice job of breaking them up.

Aside: I’m listening to Skaven’s tunes via the Modizer app. Very cool!

Time to churn out a new level! “The Barn” has arrived.

I’ve added in auto-save / auto-restore of the whole game state. And I’ve added in save / restore of the game settings (like your volume preferences, or whatever.) I had to hold myself back from doing anything crazy like using a fixed_map from EASTL, and just do it the “simple” way. Using new and shiny things is fun, but it doesn’t necessarily buy me any time or improvement in my code.

I then added clipping to my GUI code so that I can have things like scrollboxes and whatnot. I considered SCISSOR_TEST, depth buffers, and stencil buffers. I eventually decided on just calculating all the clipping in software so I could avoid using all those GL features. That way they are saved for possible more cool uses, like effects.

-Phil

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