Saturday, 22 December 2012

Surrounded sort-of functioning

I picked up some Creative Commons character sprites from, which are a big improvement on the smiley/frowny faces from before. Threw together the weapon and tile graphics myself, and got most of the meat of the game's logic integrated with the graphics rendering. There are still bugs like text displays not updating as often as they should. The code is rather more spaghettified than it should be, so I might slow development down and take the time to modularise things better. The new floor tiles make route planning much easier than the original ASCII display, and the weapon overlays are a lot clearer than the obtuse colour filters of the previous version (not to mention the player can now use shift or control to restrict the overlay to information about tiles that can be attacked or tiles that can be attacked from).

On the other hand, I'm not sure 16x18 character sprites are very good for viewing at their original scale on a desktop or laptop monitor. I've transplanted them to a 22x22 grid, which (with a few tiles shaved off in each dimension) is about as big as sprites can be to hold a grid of this size in a 1024x768 window. Doubling the sprite size would entail either halving the map size (with catastrophic consequences for gameplay), or restricting the view to a subsection of the map (meaning that player and monsters can attack from offscreen, which is just bad). I'll probably try both, though I'm leaning towards maintaining map size, restricting view, and imposing a maximum range (8 squares or so) on attacks. Then the only danger is if the player is moving quickly and a monster with a strong ranged attack appears from offscreen, giving the player only one turn to react. In that case the player should have checked the list of enemy weapons before starting to run, but perhaps I'll leave the full-map view as a toggle to exchange prettiness for safety in later levels.

Tuesday, 18 December 2012


Got slightly sidetracked making a graphical version of Encircled (converting from curses to SFML). Most of the logic and dungeon rendering is now linked up properly, so I'm currently focussing on getting the HUD to display. Encircled is very unforgiving without the sidebar information.

Unfortunately "graphical" means it's displaying 20x20 tiles that I made myself. You can imagine how bad they are. Actually you don't have to:

The other problem is they're not close to being colourblind-friendly.
I don't see this as a particularly bad distraction from the strategy project - not having dealt with parallel threads before, this will make a good platform for practising their application.

Thursday, 15 November 2012


When this game was originally planned, with the assumption of tiles, I had hoped to do everything on the CPU to avoid all the troublesome library linking and constraints on end-user hardware that come with using the GPU. Obviously with 3D graphics that's not a position I can maintain, so I've started reminding myself how OpenGL works. I's a lot different to 3.5 years ago when I was taught it!

It looks as if I should be able to leverage the GPU for a little or a lot of the simulation requirements of the game, provided I can keep the graphics processing to a minimum. There are a lot of things the computer will need to do:
  • track locations of N actors on a heightmap
  • keep grouped actors marching together, preferably via local interactions similar to boids, and preferably with variable "discipline" governing regularity of formation (discipline 1.0 => perfectly aligned rectangles and (sometimes, when surrounded) circles, discipline 0.0 => random jumble)
  • render heghtmap shadowed by visibility from PC, and preferably by sun's angle too.
  • render actors visible to PC: different skin textures (corresponding to armour types), different weapons, different animations at different stages (or, even better, simple ragdoll)
  • render actors reported by scouts, either in observed location or in assumed new position
  • track locations and actors visible to scouts (and estimate sizes, directions of groups seen by scouts)
  • track actor-actor visibility, with occlusion from heightmap, actors, and vegetation/buildings
  • avoid actor-actor collisions
  • simulate actor-actor combat (geometrically rather than numerically)
  • simulate movement diffculty caused by and to large groups of pike wielders (particularly in forest)
  • track orders for each actor or group
  • propagate orders through shouting
  • interpret orders and make independent decisions
  • track skill use and increase speed and effectiveness of the relevant actions accordingly (latter part optional - can be done between battles)
  • flexible actor size to accommodate horses, elephants, etc.
  • find paths, considering difficulty moving uphill, potential difficulty moving through vegetation or water, positions of dense groups, enemy groups and groups in combat. In last scenario (and preferably others), walls will become relevant
  • attempt to surround or flank enemies when possible
  • change facing appropriately when [potentially] surrounded or flanked
  • use sensible strategies for enemies - simulate a general if possible
  • allow pausing, slowing down, speeding up.
  • generate a variety of large, realistic heightmaps with vegetation and water, and render these efficiently enough to allow the largest possible number of actors on screen.
Some of  these will be more suited to one or the other of the CPU and GPU. Using CUDA would make a lot of these tasks much easier, but I don't want to restrict players to those with nvidia cards and I haven't actually succeeded in compiling anything that uses CUDA. OpenGL 4 seems to have enough features to make at least some of these tasks doable on the GPU.

Anyway, the current state of the program is a heightmap render gutted and Frankensteined from, (which seems to be abandoned), and... I think that's it so far. Most of the surgery I had to apply comes from removing all references to the GLTools library (substituting GLM), and removing all references to freeglut (substituting SFML).

To continue, I think the next few steps will be:
  1. Get terrain LoD with tessellation shaders working.
  2. Get instanced actor drawing (with LoD) working.
  3. Figure out how to get a variety of textures and individual weapons and ragdolls (or at least animations) working on instanced actors.
  4. If I get bored during one of those stages, figure out how to do triplanar texture mapping on a tessellated heightmap (and hence kill the unpleasant texture stretching artefacts that are so common in RTSs)
  5. If I get really really frustrated trying to draw tens of thousands of instanced actors without killing framerate, figure out how to do those triplanar textures with Wang tiling (which is really cool)
GPU Gems and pyalot's WebGL projects pop up a lot in my googlings, and I'll probably end up using a lot of code from there. I'm going to allow myself one rewrite, so that I can experiment freely with the techniques I'll need to try without worrying about sensible coding practices. Once I'm confident that I've done enough research I'll figure out what to title this thing and start the rewrite, doing things properly with header files and OOP and things. At that point I guess I'll be approximately where I was when I dropped the discrete-space version, but with a lot more processor power to harness and a much more sensible space in which to do the mechanics of actor-actor interactions.

As for titles, I still haven't got any better ideas than "Rogue City".

Thursday, 25 October 2012

Continuous Space (Continued)

To represent the game in continuous space, I've got a few choices, all of which would probably want OpenGL:
  • Maintain orthogonal top-down perspective, as in the libtcod version. Indicate heightmap by terrain colour and shadows. Sprites for characters, possibly even just circular symbols indicating weapon/shield/armour/skill combination
  • First-person 3D perspective. Would easily justify the restriction on player's field of view. Will probably not be able to getaway with sprites for characters in this case. Would rather not waste time on 3D models.
  • Isometric or variable perspective with 3D models. see above.
  • Isometric perspective with sprites. Cossacks style. This could work very very well. I'm leaning towards this. 2 minutes after publishing this it turns out Cossacks used 3D models pre-rendered in a set number of orientations. Whatever.

Continuous Space

Still too busy to be doing any coding on the strategy RL, but that should change soon when my work stops involving any coding for a few months. I did take the time to make a decision about the project's direction, though, which will probably lead to a rewrite. Long story short, the game was originally intended to take place in discrete grid space, and now it's going to take place in continuous space.


Initially at the very least, the game is supposed to offer a scenario in which undisciplined untrained hordes are able to defeat professional, but badly outnumbered, armies, with the forces gradually equalising as the members of the player's group die, gain experience, and retrieve intact equipment from their fallen enemies.

The game is not intended to be ultra-realistic in terms of modelling exact arcs of weapon swings and interactions between colliding materials, but it is supposed to simulate that kind of asymmetric combat in a reasonably plausible way. That is, something less abstract than attack and defence values and hit points; in a microcosm of the game where 2 or 3 unskilled fighters  attack a professional warrior (with DEF 10) and win/lose, I don't want the result, or the probability of the result, to be an obvious consequence of the unskilled fighters having 4 ATK and the other having 10 DEF, and them losing or winning because 2 times 4 is less than 10 and 3 times 4 is greater than 10. I'd prefer to have more realistic interactions along the lines of one of them being blocked by the shield, one of them either parrying or harmlessly hitting armour, and the third being free to concentrate on making a good hit without retaliation.

When scaling up this kind of situation to a smallish army and a large horde, the problems with simulating such a system on a square grid become apparent. A regular formation must either have a soldier in every tile, or every other tile. There are no alternatives in between. If dense formations are made standard, then the horde is unable to gain advantage by using a larger number of fighters per unit area. That is, unless they do strange things such as organising the battlefront into groups of three who each target the same enemy, they are unable to force the situation in the previous paragraph to play out. In contrast, a continuous space system with continuous facing angles would allow finer distinctions between formation densities and make situations like the above occur naturally. A penalty to freedom of movement when surrounded too closely would discourage use of excessively tight formations (at least, for the kinds of warriors that need space to swing).

Continuous space will also make mounted troops a lot more natural, since they won't have a one-tile-per-actor rule to break - they'll just have a differently sized collision box. I had trouble imagining how to implement polearms in gridworld, since they would extend for more than one tile. In continuous space, the simulation of how they restrict movement and the ways in which a charge might, with losses, get through a pike wall, will be a lot more natural.

For troops organised enough to sit in box formations, a continuous world allows them to maintain a consistent frontier while marching in non-cardinal directions. Depending on how the maps are constructed, it could also make for much simpler field of vision calculations.



Monday, 1 October 2012

Encircled has health regeneration and is much more likely to be winnable

Tiny update to the code, big difference to gameplay:
  • Gave all actors small level-dependent chance of health regeneration when standing still. This means that the player doesn't have to die on the first level where an enemy has a ranged weapon. I was able to get to level 9 of normal mode before encountering a crash which I think was also fixed in this update (number-flashing routine). Before now, this problem meant I died on level 5 or before.
  • Alter AI to take advantage of regeneration, and to make bosses move more freely when the player is far away (so they don't get stuck in corners permanently)
  • Update colour display information on entering a new level
  • Improve number-flashing routine

Same download link.
More likely to be winnable, but still very easy to die.

Wednesday, 19 September 2012

Encircled has a tutorial!

And the tutorial has text!

Something like 50% of the initial playtesters complained about being dropped in an abstract world with no instructions when they loaded the game. Quite understandable.

However, figuring out which mechanics need to go in a tutorial and writing terse, clear, easy-to-read prose that will explain those mechanics is a time-consuming task that I only just managed to finish now.

But now, Encircled is accessible to people who don't have me on the end of an IM system, don't like reading readmes or built-in help systems, and don't like to have to figure things out for themselves.

Hopefully that demographic includes some people who will enjoy the game.


Next on the RL agenda: planes, Purkinje cells, normal vectors, and parallel fibres.

Monday, 17 September 2012

ARRP: Encircled and Mutant Aliens update 4

For this year's Annual Roguelike Release Party I've updated Mutant Aliens! and Encircled.

Mutant Aliens! update 4

 * Draw bright colours for visible things
* Stop drawing things that are in LoS but out of visual range
* Don't generate aliens with identical representations
* Completely prevent player from being "trapped" (escape was still easy with explosives) when the ship crashes into a building (previous fix only prevented most such cases)
* Fix autotargetting so that it doesn't get confused when the previous target is alive and out of sight
* Allow player to close the door (but not fly away) when the transmitter is destroyed and an alien is in the ship
* Notify player when hit by an explosion
* Don't allow explosions at the corners of the map to break the program
* Choose transmitter location more carefully
* Notify when an explosion happens
* Monsters no longer spawn in player's visual range :3
* Ask for device time and delay before targetting throws
* Put transparent windows in buildings, make doors opaque, randomly turn some doors into floors
* Overhaul terrain destruction - different terrain types take different damage amounts
* Cannon shots can destroy walls and windows (walls unreliably)
* Add critical hits (shoot a monster several times to figure out where it's vulnerable)
* Hologram, sound, scent, and brain devices all give LOS to the player, so they now function as spy cameras as well as distractions
* Overhaul message display to allow partial messages in the message log.
* Include monster health/stamina descriptions, sense descriptions (don't need to be discovered) and finer stat descriptions from Mutant Aristocrats!
* Alter sound levels to allow movement to actually be heard
* Make monsters screech 75% less often
* Make monsters' decision about whether to run slightly more sensible
* Draw running monsters with capitals, draw near-death monsters in red

Encircled, version 0.4.1

* Menu system, including online help
* 6 play modes: standard, tutorial, two quick modes, unlimited mode, and munchkin mode
* Much more interesting level generation
* Offer to dump (very minimal) character stats on death/victory
* Flash damage amounts (like in Sil), remaining HP, and culprit of each attack.
* Option to change animation delay for damage flashing.

Saturday, 25 August 2012

Encircled: 60HRL

Download link.

Two and a half days isn't bad. It's got everything I wanted except an evil challenging AI for the bosses (they just run away). Their now-smart minions totally make up for it, though. It still doesn't have any semblance of plot or background, just because I haven't the faintest clue what kind of world this gameplay would make sense in (aside from Conway's Game of Life).

I verified that the game was winnable against mindless random-walker zombies, but I was too busy coding the AI (up to the 60HRL deadline) to test if the AI is actually beatable. So, good luck with that. I'll be putting an effort into winning and post a blog if I succeed.

Summary from the forum thread:

Unlike every other roguelike out there, you can only attack if the terrain surrounding you matches a pattern on your weapon, and you can only hurt someone if the terrain surrounding them matches a pattern on your weapon. All the enemies have the same restrictions.

Slightly inspired by rogue rage, you automatically attack every turn if you can. All you have to worry about is where to go and whether to pick up a different weapon off the floor.

Objective is to slay a certain number of boss enemies on each level. All the other enemies can be ignored, but they'll do their very best to hinder and hurt you.

The dungeon is initially just a random mess of walls and floors, but as you play a level it gets restructured by whoever stands on a terrain alteration button - as long as someone does that, the dungeon will change so that their weapon patterns are more prevalent.

Please comment or email me if you try the game, and especially if you win.
Encircled running on Linux over ssh.

Totally surrounded by 'b's. NOT THE 'B'S! Equivalent to death without an appropriate weapon.

Doing reasonably well on level 1.
... and I just noticed that "hlth" and "wepn" are the wrong way round. That'll be fixed for ARRP, if not sooner.

Friday, 24 August 2012

Encircled: 44.5 hour report

Everything except AI is finished.

Download link

Unfortunately the game is really easy playing against random walkers (it only took me a few tries to win), so I'm going to have to give the AI some claws.
However, unforseen circumstances mean I'm busy until approximately the 2DRL deadline. Which I guess means that this is going to be a 3DRL. Or at least 2.5.

So while this release isn't very indicative of the final version's challenge level, I would be interested to hear whether people feel the variety of weapons between dungeon levels is good. Personally I feel it's a bit too heavy on adjacent (melee) weapons, with visual range weapons showing up slightly too late. Since this is still a debugging version, you can fake a boss kill by pressing capital F if you want to explore the lower levels and see what's on them.You can also take a new random pair of weapons by pressing 'v'. Feel free to experiment and tell me what tweaks you think are needed in the balance of weapons.

Thursday, 23 August 2012

Encircled: 24 hour report

24 hours ago (about 3:45 PM on Wednesday) I started writing a small roguelike, intending to finish it in one or two days. It's called Encircled, and its schtick is that actors can only attack if the 8 tiles surrounding them match the first pattern on their weapon. Likewise, they can only cause damage to actors whose position matches the second pattern on the weapon. So, winning is dependent on positioning oneself to avoid damage from all enemies and to be able to deal damage to the enemies that need to be killed (bosses - everything else can be (un)safely ignored). It's also important to exploit the restructuring squares, which when an actor stands on them will remould the dungeon to favour the weapon carried by that actor.

So far, everything's implemented except:
  • Sensible AI (just random walkers for now)
  • Swapping weapons from the floor (at the moment you press 'v' to take a new random pair of weapons)
  • Sensible progression of weapon quality for the player (see above)
  • Plot (I don't think I could possibly think up any narrative excuse for this gameplay)
That means that what I do have is:
  • Combat system implemented: matching rotatable and reflectable weapon patterns against use and target, checking for range. Weapons can affect adjacent enemies, enemies in visual range, or enemies anywhere on the map; weapons can either choose a target at random, or damage all matching enemies.
  • 16 dungeon levels (numbered 1 to 20 with some gaps)
  • Procedural weapons, ordered by a reasonably sensible quality function
  • Procedural enemies, 5 per level, which consist of a weapon plus a health counter
  • Boss fights (kill 21 minus DLevel bosses to win the level)
  • Restructuring pads, which alter the dungeon layout to favour the weapon(s) of the actors standing on them.
  • Activatable assistance displays. One shows where the player can/could attack and where they could attack from, and where the enemies can/could attack and where they could attack from.
  • Three simultaneous keymaps for movement. qweasdzxc, hjklyunm, and 789456123. The only people who will be unable to play this game are dvorak/azerty laptop users with a non-functioning fn key who hate vi keys. And they can jolly well edit the source code.
No download link yet, but I might post a preview version a bit before the deadline. Assuming I don't decide halfway through that it's a 7drl. That's how KleinRL turned into a 14DRL...

Edit: download link.

Also given that this is a long way off from ARRP, I guess for ARRP I'll have to release a bugfix/update version.

Wednesday, 1 August 2012

ARRP plans

The Annual Roguelike Release Party's coming up soon, so I've resumed making changes to Mutant Aliens!
  • Buildings now have windows, which can be destroyed by explosions (but not bullets) - this makes getting into and searching buildings slightly easier.
  • Damage required to flatten a given piece of terrain now varies with terrain type. As well as windows (reliably), walls can now (unreliably) be destroyed by direct cannon shots.
  • Doors are now opaque - this makes walking through them more dangerous.
  • Active devices now have spy cameras that transmit pictures to you (giving you line of sight)
  • Aliens can now be shot critically, doing double damage. You have to discover a species' weak point before you can specifically aim for it, which you do by shooting at each of its body sections in turn. All this is done automatically, so for the player the effect is that after several shots (the larger the alien, the more it takes), a shot makes a critical hit. From then on there is a slightly-more-than 1/3 chance of each shot being critical.
  • New messages are drawn in bright white, old messages are drawn in dark white (grey) to distinguish them.
There are other changes I made slightly longer ago, which haven't yet been included in an official update:
  • Tiles in line of sight are drawn with bright colours
  • Two alien species can no longer share a character representation with each other
  • Probability of the player starting trapped in a room is now 0 (but escape was always possible with explosives)
  • A message is generated when the player is hit by an explosion, discouraging them from shooting the cannon at adjacent enemies
  • If aliens are camped in the ship when you return, you can close the doors before killing them in order to stop any more from entering.
  • Aliens can no longer spawn in visual range of the player.
  • Transmitter is always generated at a minimum distance from the player.
Several more changes are planned:
  • Options to change the keyboard controls
  • Tutorial, even if it's just a bunch of labelled ASCII screenshots!
  • Incorporating improvements from Mutant Aristocrats! (feedback on individual monsters' health and stamina states when examining them)
  • Flesh out the plot, make it not-totally-obscure why the transmitter is there (completely changing the endgame), add props to make the map seem less dead
  • Write scores/character dumps to file in a format suitable for usenet and forums
  • Choice of character backgrounds (classes)
  • The ubiquitous galactic pest: giant carnivorous plants (if you're very unlucky)
  • Rebalance monster senses to ensure that distraction devices have a noticeable but not overpowered effect
  • Complete difficulty rescale (too many easy difficulties which don't differ much, too few challenging difficulties which differ too much). Most of the planned gameplay changes (critical hits in particular) make the game easier, so a general increase in difficulty wouldn't go amiss.
    • changes to alien stat distribution?
    • changes to initial ammo?
    • changes to device counts?

Monday, 9 July 2012

Field of vision on heightmaps, part 1

Spent the day researching field of vision algorithms. I've had a look round that part of roguebasin a few times before, but so far I've not made any games that needed anything more complex than simple Bresenham lines. All my previous games had a hard limit on the player's sight radius and only drew the FOV once per turn, though. Here, not only will sight range be bounded only by the map (because if you're standing on a hill you should be able to see an army on the other side of the map). I'll also need to (occasionally) calculate FOV for non-player actors, to allow scouts to report what they see and to allow groups to detect enemies they could engage or avoid.

Someone pointed me to an algorithm that only checks each tile once, and which doesn't check obstructed tiles. It's quite attractive to check as few tiles as possible, when there are so many on such a large, open map. At the moment it's 512x512, and if I decide to make formations looser by default (in order to make tight formations more meaningful and facilitate friendly formations moving through each other) then that might go up to 1024x1024. Most of the FOV algorithms around check some tiles more than once, which obviously isn't desirable on such a map.

For instance, one algorithm draws a Bresenham line to each point on the border of the viewable area. Near the borders you'll have just one ray passing through each tile, which is nice, but near the centre you'll have several rays passing through, checking the central tiles more than once!

A few pages of a notepad, and it turns out that for a square map, the number of times a tile is checked depends on where in the map you stand. In the very corner, the number of tiles checks will be 3 times the number of tiles on the map, in the middle of the border it'll be 2.25 the number of tiles, and in the centre it'll be 1.5 times. Because there aren't any obstacles that guarantee there's nothing in FOV behind them, every tile has to be checked. So, which algorithm to prefer depends on how expensive it is to process a tile under the different schemes (and whether it's any cheaper to skip over an already-checked tile).

LibTCOD has both of these algorithms (unfortunately not in a form I can use directly, since it deals with definite obstructions rather than heightmaps), and apparently it's faster to cast rays to every point on the border (and it would still be faster if the rays were cast from the corner of the map). Since the diamond raycasting algorithm is more difficult to understand, more difficult to implement, and slower in the implementations that already exist, I think I know which one I'm going to try first.

Or ever.

Part 2 when I've implemented at least one FOV algorithm.

I think I could totally get away with grouping tiles into 2x2, 4x4, 8x8 or 16x16 squares as distance from the observer increases. It would definitely work well with the minimap, and it would save a huge number of tile checks allowing more actors per second to have their FOV calculated. If the player scrolls to some faraway area then the calculations can be done at the single-tile scale there.

The only problem I anticipate is if a scout looks around, gets some coarse FOV data with big 16x16 chunks, reports it to the player, the player looks around, and sees a big artificial-looking 16x16 chunk of weirdness. I guess the solution would be to do fine raycasting for things that will be exposed to the player (player FOV, scouts who intend to report back), and coarse raycasting for other things (everyone else).

Given that there are bounds on how high a tile can be, there are actually definite obstructions - if the product of the distance with the highest slope encountered on this ray is greater than the difference between the observer's eye level and the maximum height, then the ray can be terminated.

Wednesday, 20 June 2012

Excuse Plot

It took a few iterations and going round in circles and mentally crossing things out, but eventually I managed to construct a story that can just about excuse the gameplay I'm aiming for. Problems arose because the obvious way to get a large horde of recent civilians fighting a somewhat smaller number of soldiers is to have a revolution. Unfortunately, that doesn't lend itself too well to the stipulation that there should be several battles in a row over a long journey with no substantial reinforcements found on the way.

Written in lazy mode because my pretending-to-be-an-arts-graduate mode half-doesn't exist, half-writes at one sentence per hour. Also if I decided to use the actual names rather than these placeholder names, I'd have taken another 2 days to get this down. It probably just needs a Markov chain name generator, but for some reason I want heavy-handed symbolism and mind games. Or do I?

The Actual Plot

The City has a proud history of heroic deeds, monster slayings, battles won, bridges defended, castles sacked, dragons stabbed, etc. etc. Having accomplished, or at the very least claimed to have accomplished, these things many times more frequently than people from anywhere else, the people of The City built this huge stone monument to their great and heroic acts.


(I just did all this writing! You don't expect me to do all the artwork as well, do you?)

On the top left you can see That Person the Great leading a troop of kittens to assassinate King Thingy the Pillager; underneath is Thingummy the Lefthanded tricking the twin dragons of Somewherania into killing each other; beside that is Whatchumaface the Brave headbutting the gates of Villainy Castle, the whole of the bottom half is apparently reserved for future daredevilry, and in the top right there's a lot of very small writing in the Ancient Tongue that the scholars say was about the builders of the city and the several thousand killer elephants (or possibly bears) they slew. Those are just the parts large enough to see from this distance.

Naturally, these legends spread far and wide into foreign lands, such as the Wherevrian Empire that currently holds this country in thrall. Our King several miles away in The Capital, being mostly sensible and unafflicted by unreasonable pride, is providing Wherevria with tribute each year in order to avoid this country being crushed beneath the Wherevrian heel.

This year, the Emperor demanded our monument.

The King is aware of our reputation and quite rightly thought better of telling us. Rather, he secretly sent royal guards to The City to steal it in the dead of night. Weeks later The City's furious questions were answered by rumours among the travellers and merchants. The monument was in the imperial palace of Wherevria.

To all of us, it was immediately obvious what had to be done. Into the monument's blank spaces would be carved the story of its return to The City. But the Wherevrian armies are strong and the people of this City are clever. A bare year later, our spy meets the Emperor, the Emperor demands the King's Sceptre, The King marches every soldier in the country towards the border, the imperial armies prepare to meet him, and we have our chance.

The armies will be distracted, The City will be empty, and the people of The City will take back the Monument. [but only if the person playing the game can stop them all from dying on the way]


Hm. Being constructed with the intention of enabling specific mechanics in a game rather than to espouse any particular ideal or dogma, I'm not entirely sure what sort of subtext this thing has. It's got some regional chauvinism nonsense (The City's pride) going on, and the same people seem to be dwelling too much on their impressive past achievements without claiming that any of them were particularly recent.

Nonetheless they are forward-looking, and they seem confident that being born to a heritage of leetness is enough to carry them past a few large armies into the capital of an empire and back with a large piece of rock. I guess the barbarians managed something along these lines in the case of Rome several times, but in this case all of the actual soldiers are off in the King's army preparing to run into the imperial armies and die. Maybe the civilians spent the last year practicing swordplay in their spare time... or pitchforkplay.

On top of that, I'm probably not imagining the 300ish vibe, which would be somewhat stronger if I were making the Wherevrian Empire a ridiculous racist caricature, and if I weren't turning it upside down and portraying the non-leet hordes of barely-trained fighters as the ones to be rooted for (as opposed to the smaller groups of trained warriors that they'll be bumping into and fighting).

Well, I wish them the best. Good luck.

Or good players.

(No progress coding the game, I have some actual work-work-coding-work to do)

(Let me know if you end up sketching what that large rock looks like)

(Also who was this story supposed to be addressing? My best guess is the amnesiac mayor who should know the whole story but might just happen to be the player character)

Saturday, 9 June 2012

Because reducing player performance to a number is what gaming is all about

Actual work-work is interfering with RL-work again, but I spent a free minute fudging together a scoring system for Mutant Aliens! So far (in my experience) it reliably gives negative scores for losers and positive scores for winners. Unfortunately to justify the scores to the player would require a proper postmortem screen. I guess I'll make one of those the next time I have a free minute (hour). No progress on Command, but every so often I take a moment to think about UI (I'll have to look up how libTCOD does mouse things), tutorials, how to phrase the introductory fragment of plot, actor behaviour, and so on. It won't be until mid-August that I can resume properly working on it, though.

Friday, 18 May 2012


OK, clustering is unnecessary for now; it's pretty easy to propagate information at the speed of sound without the need for artificial groups of actors. Here follows a video of the normal 16,000-actor gorefest, combined with an argument about which random colour best matches the rusty iron of a 5-decade-old pitchfork.

The main problem here is that the competitive nature of "ideas" in this setup and the actors' undiminished sensitivity to old ideas makes it pretty difficult for new ideas to take hold in large, densely packed groups. I'll keep in mind the need to overcome this issue when I modify the system to convey useful information.

Things I should be able to accomplish just using shouting:
  1. Sharing visual information
  2. Relaying orders
  3. Detecting when a group is surrounded
  4. Facing outwards to counter flank/rear attacks
  5. Getting into box formation
  6. Moving in box formation
  7. Morale, giving up, tactically withdrawing
  8. Probably more
Getting the shouting system to do these things is my next priority. After that I'll probably add some depth to the combat system, which at the moment consists of "if you hit, you have a one-in-four chance to kill".

Wednesday, 16 May 2012


Am I worried that this is overly ambitious?

No. I did a 14DRL, a 7DRL, then made a 1DRLL out of the 7DRL, and now I'm getting tired of projects with excessively limited time and scope. ASCII graphics and lack of economic system take out a lot of the work that would be required for a typical strategy game, and I just checked that Shogun 2 can handle 14,100 people at 4x speed (with animated 3d graphics and occlusion culling and experience tracking for everyone, though not with a capable AI), so there's no doubt that doing all the stuff I want to do in a game second 4 times per real second is possible, at least on two cores. I won't be bothered if single-core users have to make to with just 2 game seconds per second. Boo hoo.

What do I definitely not want to do?

Some people might have thought I had gone crazy and wanted a procedurally generated plot with procedurally generated characters and relationships and socio-economic modelling and a few years worth of coding a plot generator. Actually someone *did* think that.

Definitely not. The overall plot, which would only be strictly relevant at the start and end of the game, would be constant. Ideally I'd have around 15 "types" of battle, each with an introductory/closing snippet of prewritten prose and procedurally generated maps/enemy forces. Of these, something like 8 would appear in a given game, preceded by the opening bloodbath (which would need some heavy narrative) and followed by the climactic whatever-the-win-condition-is that the player does at the end (also narrative-heavy). This wouldn't be difficult at all, with a writer on board to do the prose, and would produce around 260 million possible sequences. Between battles would be a summary of what was lost/gained in the battle, the group/equipment assignment interface (see Intentions), and not much else. Some kind of choice about where to go (probably not free movement) on a world map might not hurt but would be nonessential.

Quests, side-quests, side-anything: nope. Considering the total absence of reinforcements and friendly faces, there's no-one to give you quests, and there's no reason to go way off course and lose 5% of the army rescuing a kitten from barbarian wolf-riders. Not unless you're desperate for mounts.

Next time: either the procrastination-born macguffin plot that's just about coherent enough to excuse the intended gameplay, or the local shouting system that probably makes clusters unnecessary.

Saturday, 5 May 2012

Dynamic Clustering

The centre of mass of a finite number of point masses is easy to calculate, especially when they all have the same mass: sum their position vectors and divide by their number. In a discrete setting we can avoid floating-point operations altogether by simply summing their positions, and remembering that the resulting value is N times the actual value.
This makes dynamically updating the centre of mass of a cluster completely trivial - when an actor in the cluster moves, update the cluster's centre of mass with the same delta as was applied to the actor. Checking if an actor is within R tiles of the centre can be done by multiplying the actor's position and R by N, and comparing to the stored value of the centre as normal.

Before I implement the dynamic updating, I need to figure out how to assign these clusters in the first place. Ideally they should be as large as possible within the constraints of the cluster_join_range constant that I set. Ignoring all the times when I tried to dereference null pointers, here's what happened:

Attempt 1

 I had the foresight early on to place the actors on the battlefield in random order, so if I iterate over the list of actors I get a random sequence of locations in the army. For each actor, check if there's someone adjacent who's in a cluster and try to join their cluster. If that doesn't work, make a new cluster and tell everyone adjacent to join it.
 The result, obviously, was tiny clusters. About 700 are needed to hold all 16,000 actors, or about 23 actors per cluster. Considering the value of cluster_join_radius allows clusters to contain up to 169 actors (yes, my "radius" applies to a square), that's pretty poor.

Attempt 2

Iterate over all the actors 10 times. The first time, after checking for adjacent people with a cluster to be joined, have only a 10% chance to make a new cluster. The second time, 20%, etc.
The result was a big improvement. I won't post it here, but it needed around 470 clusters or so. That's 34 actors per cluster. Still not ideal...

Attempt 3

If a change brings some benefit but not as much as you want, what do you do? Make the numbers bigger. So the first iteration there was a 1 in 40 chance of making a new cluster, and that went up to 14/40 before it jumped to 100%.
This needed about 340 clusters to hold everyone, or 47 actors per cluster. Not bad. But what happens when I let them move before I implement the dynamic joining/exiting of the clusters?

What I should be doing

Reading bioinformatics.

Oh, With the initial cluster assignment? By starting with maximal clusters, of course. Check everyone in a 13x13 square centred on the first listed actor, then the second (if they're not already in a cluster), etc. Much quicker and simpler to draw 169-square boxes around a small number of actors than to iterate over 16000 actors 40 times. Depending on the splitting/merging routines the number of clusters will obviously increase as they advance, but as long as they're sensible this shouldn't be a big problem.

Also, these random colours obviously won't appear in the actual game to let people to complain about bad libtcod colour schemes.

Friday, 4 May 2012


These are the things that Command (or whatever it ends up being called) will have when I consider it complete.
  1. A sequence of battles on a Total War scale, and a player character commanding one side.
  2. Player's sight limited to their own field of vision, and not including their soldiers' vision.
  3. Player's ability to command limited to earshot (and nearby combat noise).
  4. Individually and reasonably intelligently acting troops who can take the initiative.
  5. Mounts, probably multi-tile, including at least horses, possibly elephants. Maybe some more unusual real-world ones. Perhaps non-flying dragons, if the plot is fantasy enough to allow them and if the lore/game mechanics can allow them to be captured from the enemy and work for the player.
  6. Player initially commanding a very large force of people with no battle experience and no relevant equipment, who must learn to fight and scavenge equipment/mounts from fallen enemies.
  7. No possibility of reinforcement between battles (at least not nearly enough to replace losses).
  8. A variety of battlefields and circumstances: fields, hills, forests, buildings; attacking or defending a position; ambushes; storming a castle for the final battle.
  9. Difficulty. Losing any one of the battles should be a possibility, winning the first few battles shouldn't require complete mastery, getting to the final battle and winning the game should require a great deal of skill.
  10. A plot, preferably with randomised elements, quite possibly excluding fantasy elements, which allows for all this. I don't plan to write this plot.
  11. As little micromanagement as possible, despite the individual nature of the troops and their skills/equipment.
    1. It must be possible to direct commands at groups of units, refer to groups of enemies in orders, and to divide/merge/reshuffle groups according to need during the battle.
    2. During the assignment of equipment, it must be possible to assign groups/equipment/mounts based on groups, troops' skills, etc. For instance: giving all the horses to the most skilled of the current sword wielders and making a new group from the new horse riders, then dividing the heavy armour equally between the group of axe wielders and the new horse riders.
    3. Doing this should be trivially easy and not require any dealings with individual troops. This will require some careful interface design.
  12. Since much of the battlefield might be out of sight of the player, messengers should go to the player with status reports if/when appropriate.
  13. The whole thing should run at 2-4 game seconds per second at the minimum on a reasonable computer (someone said they had a single-core 1.8GHz machine, so I'm aiming for that).
What does the game currently do?
  1. Runs at over 15 game seconds per second at 2.6 GHz, with 8000 troops per side. Obviously this will go down as the individual actor AI becomes more complex, and as battle calculations become more involved. Because of the stipulation that there are no reinforcements, it will take a large number of troops in the first battle to make victory attainable in the final one. So, ensuring good performance with large numbers is essential.
  2. Troops walk around friendly troops.
  3. Troops kill enemy troops.
  4. Dead troops leave bloodstains.
  5. Not much else.
What would be nice features that would add to the game but don't necessarily have to be in the complete game?
  1. People with appropriate skills automatically fixing damaged equipment after combat.
  2. Very small quantities of random reinforcements, or caches of weapons and armour, or stables of horses found between battles, if the plot allows.
  3. Lieutenants who can give reasonably sensible commands while the player is too far away to do so. The enemy should probably have these anyway.
  4. Some kind of decision from the player about where to go for the next battle, perhaps something along the lines of the travel map in The Last Stand 2 (minus the supplies and the day counts).

What am I working on/thinking about right now?

Dynamic clustering, vision, and hearing. While all this stuff about troops behaving/thinking individually is all very nice, making every single troop look over the whole map to find enemies and making every soldier process every sound by themself is completely infeasible.

The solution is to have them form into communication groups (not the command groups the player will be assigning later, which could get spread out too much), which are formed and bounded by distance from their centre of mass (anyone too far from the centre gets thrown out of the group).

These groups can ration the use of their eyes so that every group on the map gets a chance to look for enemies, and can simulate the spread of information between nearby comrades... by simply making the group's information available to every member of the group (maybe with some delay for realism/performance. Maybe not). So if one group member sees a thing or hears a sound, all of them see/hear it.

I'll need to find a sensible method of inter-group communication too, and make sure that the way group members deal with nearby directional cues in a way that will allow them to make non-stupid decisions in situations such as being surrounded, or being on the flank of an enemy group but having a group centre further back on the front line.

No screenshot today, you got your nice screenshot last time.

Monday, 30 April 2012

Klein Roguelikes

Despite the blog title, which is more relevant to my first roguelike, this will mostly contain development logs for the strategy roguelike provisionally titled Command.

You'll also see occasional updates for my 2012 7DRL Mutant Aliens! and its deterministic cousin Mutant Aristocrats!. There will be at least one of these before the Annual Roguelike Release Party this September.

Today, writing this blogpost is the most harmful possible form of procrastination, so I'll leave the screenshots and the list of my intentions for Command for the next post.

The repository for Command is on bitbucket (no binary downloads at the moment), so if you want to compile a non-interactive demo where 16,000 troops charge at each other and turn into a long curvy bloodstain at a speed ratio of 10:1 or more, please feel free. That speed ratio will probably decrease as more interesting features get added.

If you feel mortally offended by the way I wrote the makefile and the way I linked SDL (which I'm pretty sure is just about as far from ideal as you can get), then please contact me with a better suggestion.

... OK, you can have a screenshot: