next »

[Craig Stern]

I don't generally play Telepath Tactics with fog of war on. However, in the process of updating the fog of war tiles, I played a few matches and discovered that some not-insignificant bugs had crept into games with fog of war. Those are now all fixed, however!

In the meantime, I've created a variant of the icy bridge map I posted above. This version is filled with lava and an explosive charge sitting in the middle of the map, ready to be detonated--in other words, it's even more crazy and high stakes than the earlier version. Here's a screenie:



I'm considering changing the placement of those boulders in order to encourage the frantic scramble for the center without forcing a drawn-out fight at one of two choke points.

[Craig Stern]

Hey folks! Sorry for the extended silence there. The truth is, I was a little stumped about how to proceed with a certain aspect of multiplayer: specifically, accurately reproducing the results of random die rolls.

I started off by recording each die roll along with the action it was associated with. Eventually, however, I realized that certain events occurred during battles which were both randomized and automatic (that is, not tied to any player action). Player spawn locations, move order, whether item drops occur, item drop positions, which space a character or item is displaced to when it falls onto/spawns on an occupied space--was I going to have to record all of those things as well? Multiplayer was quickly ballooning into a huge headache.

Today, however, I finally had a breakthrough in figuring out how to get a virtually limitless sequence of results from a random seed. Using a seed single-handedly solves the whole messy problem of making results replicable: the same seed reliably produces the same results in the same sequence. The only true point of randomization now comes at the moment of the seed's creation: from that point, it's all just generating a deterministic sequence of numbers from the seed.

I now have this new method of random number generation in-game and working. With that out of the way, it's time to continue coding multiplayer!

[Houndninja]

WOW! This looks really awesome! I think its time we saw a return to some of these tactics turn based games like worms and the metal gear acid series! some of my favourite and I look forward to playing this with friends!

[Craig Stern]

Thanks, man!

[Craig Stern]

I realized yesterday that I have more work to do before I can continue coding multiplayer. In particular, I need to reorganize the way the game looks for external assets (particularly levels and tiles).

So, here's the way it works now: I specify a base filename (tile, say, or level) and then append an ever-increasing integer to the end using a for loop. The game then checks for every filename until it reaches the end of all available files. Thus, every level and every tile  must be named with a series of consecutive integers in order for the game to recognize them (e.g. level1.xml, level2.xml, level3.xml, etc.) If there is ever a gap in the numbering, the game won't detect anything beyond the gap.

This was quick to add and worked well for the early stages of development, but this is going to be hugely problematic going forward if I leave it that way. Suppose the game ships with 8 levels (level1.xml through level8.xml). If a player creates a new level, the game won't detect it unless it's named level9.xml. That means that there are going to be a ton of custom maps all named level9.xml--a player who wants to download and use more than one player-made map is going to have to manually rename all of the files so they have consecutive numbering.

The situation also exists with tilesets, which is even worse. Not only would there be potentially dozens of files for the player to rename, he'd also have to redo any maps that referred to the tiles' original numbering. That's terrible!

After experimenting a bit yesterday, I figured out a method for automatically detecting every single file in a directory regardless of filename. The game is now updated to auto-detect every level in the Maps subdirectory and load them; I need to update the Map Editor to do the same, then figure out a method for separating the game's tilesets and detecting them successfully in a similar fashion.

[Craig Stern]

We have an art update! All of the directional character sprites are now finished to my satisfaction. Here are two I haven't shown yet--the Stone Golem and the Shadowling:

     

[Craig Stern]

The map editor has been updated to conform to the new, more flexible map detection system: it now supports loading and saving maps with any sort of filename you want.

[happymonster]

Looks great! Does this mean you are getting rid of the white directional arrows now?

[Craig Stern]

Thanks!

I'm not sure about the arrows; I'm going to add in the directional facing graphics, then see if people have any trouble figuring out character facing without the arrows. If so, they're staying in. Useability trumps pretty.

[Moczan]

Add it as an option, it's a win-win situation for everyone Generally some options to customize HUD should please both casuals and hardcores.

[Craig Stern]

Yeah, adding that as an option seems sensible.

Unrelated to that: here are two more units in their four-directional glory! Behold, the skiakineticist and the spearman:

[Craig Stern]

I've been rewriting all the tile-loading code--and, in the process, rewriting the format for level maps. The map editor is now up and running with it; here's a video showing the current state of the map editor, with the improved moddable tileset system firmly in place:

http://www.youtube.com/watch?v=RKPgTK1wCmM

[Craig Stern]

YES. I have two new victories to report:

(1) The modular tile-loading scheme is now finished. It's fully integrated into the main game and working beautifully.

(2) I finally tracked down and squashed an obscure bug that was preventing certain characters from firing their full range on small maps, but only in one direction. (Don't ask.)

I also went and rearranged the tiles in the Grass tileset to make them easier to use in the map editor. However, this had the unfortunate side effect of screwing up two of my maps (which use the grasslands tileset). I'm probably going to have to redo those from scratch now. (On the plus side, I have an old build of the game that I can use to take a screenshot of those maps for use as a reference.)

[Craig Stern]

Okay, Stonebridge is re-tiled and back in service! I'm not sure that I want to re-tile the other one, Islands--I'm pretty sure that I can design a better 6-player map than that, so I think I'll just let it die a dignified death.

Speaking of dignified: check out these lovely spriggats!

   

I can't wait to see them animated, flapping their wings and all.

[Craig Stern]

All right! Another update, this time with regard to game performance. I tested the game out on my netbook, and it ran smooth as silk except for one particular set of circumstances: characters moving combined with camera panning totally bottoms out the framerate. I've temporarily fixed this by having the camera zoom quickly to the destination ahead of the moving character, meaning that the framerate drops for only a quarter of a second or so. For mobile devices, I may just pull an X-Com and have the camera jump immediately to the destination without any smooth movement at all, depending on how this does.

You may also have noticed during Teaser #4 that the game would hang for a second or two when calculating moves for characters that didn't have any enemies in attack range. That's because the long-term planning routines being used were quite inefficient, checking for every possible attack from every possible space on the battlefield to determine the ideal destination.

Well, no more of that! I spent a few days going in and re-coding the long-term planning routines, and performance is way way better.

With that bit of housekeeping out of the way, I think it's time for me to get back to coding the asynchronous multiplayer.