Game List

I finally ran out of space for game links in my Roguetemple signature. That means I finally found motivation to make a page with links, descriptions, and screenshots for all of my games. You can find it here: http://kleinroguelikes.blogspot.co.uk/p/games.html

Coming soon: announcement post for my 7DRL (it was a success) and blogs about my map library.

7DRL 2014: Poachers Will Be Decapitated!

Poachers Will Be Decapitated!

Decades of exploitation by "adventurers" have left many species such as Orcs, Kobolds, and Trolls in danger of extinction. The monstrous dragon Uozeni, who once burnt your family and your village to cinders, lurks at the bottom of a previously undiscovered cave.

Populations here are much stronger than elsewhere, and the Society for Conservation and Ecology of Dungeons are protecting the inhabitants in the hope that they can later be reintroduced to other locations. Adventuring is restricted by strict limits on killing and looting, which are enforced by the Rangers, Inspectors, and Castigators of SCED.

These kill limits aren't nearly enough to sustain a traditional approach to dungeon adventuring. To avenge yourself on Uozeni, will you work within the rules, subvert them with stealth, or publicly flout them?

Remember: SCEDRIC decapitates poachers!

I'll cross-post updates here, on RogueTemple, and at 7drl.org if my account there ever gets reactivated.

I'll be writing in C++, using BearLibTerminal for display and my own library Griddle for back-end tasks like map topology, actor management, FoV, and pathfinding. I've written some experiments in map generation and general use of BearLibTerminal and Griddle, and a lot of their code will probably be used in the 7DRL. Source for the game will be released as usual.

Griddle is intended to be reusable in a wide variety of grid-based games, enabling effects like seamless travel between map chunks and rotation of player perspective. It makes heavy use of template metaprogramming and is currently a header-only library. Once it has a more stable and well-organised API I'll try to release it as a compiled library that can be used from other languages. That way it can usher in a new golden age of ridiculously disorienting maps cobbled together from rectangles and glue. With a side order of smoke and mirrors.

Schaak! Post-Vivem

(Cross-posted from http://www.ludumdare.com/compo/2013/07/29/schaak-post-mortem/, renamed because it didn't exactly die)


Schaak!, my 7dRTS for MiniLD 44, is complete and submitted. Coding started at 9pm on Monday the 22nd, and ended at 9pm on Monday the 29th. Very little of the process went to plan. The repository is online at https://github.com/essarrdee/Schaak.

DAY 1

Day 1 was mostly taken up with scribbling and typing design ideas, and emailing my collaborator about CMake, ideas, and names. Various bad puns and portmanteaus were rejected without comment, Persian and Spanish words were considered, and a Dutch word was settled on. Coding started at 9pm, and mostly consisted of copying SFML boilerplate from a previous project.

DAY 2

Coding continued into the night. Board drawing was set up pretty quickly, followed by board drawing with cover indications (showing whether a square is guarded by black or white pieces). I took an unusual approach to board rendering - a texture the size of the map is stored on the graphics card, and updated regularly with the cover information. The board size had to be halved to fit this texture in my CPU-GPU bandwidth.

After a sleep, scrolling to zoom was implemented in the evening and piece definition files were planned - just a name, sprite information, move speed, and list of move/capture locations.

DAY 3

Implementing the piece data loading was pretty quick. Next I made a dummy piece, the Doomed Wanderer, that jumps around the map in Knight moves and tests the protected-square display's correctness. With one piece working, it was time to plan how thousands of pieces would work - not a trivial consideration when all of them will be AI controlled. The plan was to exploit the grid nature of the board - if you need to know whether a piece is in a square, you just look up the ID of the piece in that square. This simplifies capturing and collision avoidance. I also wanted to keep the vector of units compact, minimise the number of gaps formed when pieces die, and minimise the time it takes to spawn a new piece.

With the help of some people from the IRC channel, I settled on a three-part structure to hold pieces:
The vector of piece objects, indexed by piece ID which never changes during a piece's lifetime
The double-ended queue of free slots in the piece vector, which just lists all the piece IDs that don't correspond to a live piece
The 2D array of board occupants, mapping each square to the ID of the occupying piece (or -1 for no piece). Pieces also store their own board coordinates.

With the first two of those implemented, the Doomed Wanderer met his fate - deletion. I now had random walkers spawning a few times per second. There was no collision detection without the occupancy grid, though.

DAY 4

I had been making attempts to recruit artists to draw chess piece graphics since day 2, but everyone either joked about how their pixel graphics skills were so good that they could draw 1x1 sprites, or made an attempt and gave up. Or told me to use a font that doesn't scale small enough, or attempted to shrink vector sprites down to 8x8 and smaller (with antialiasing).

Halfway through the challenge and I only had a board full of invisible random walkers. There was no way around it, I had to make the sprites myself, today.

It took about 3 hours to get them right. I looked at low-resolution chess sprites from around the internet for inspiration, and for the larger ones visualised my grandfather's chess set. The knights look pretty stupid. Drawing pixel horses is difficult.

The high-resolution sprites have outlines, and to smooth out the zooming I made the 16x16 ones have half-outlines. They looked *terrible* like that. I added a bit more outline to them, but I'm not really sure what to do with them.

Code written today: zero lines. Halfway through the challenge, I only had a board full of random walkers and a spritesheet.

DAY 5

Progress towards drawing sprites. Still no chess pieces on screen. Time to get concerned about whether I'll finish the game.

DAY 6

Continued coding into the night. First thing accomplished was pieces being drawn. Squashed bugs. Got a linux makefile from a new collaborator, who exists. Implemented scrolling. Decided it would be a bad idea to develop epilepsy while coding an RTS, set scrolling speed to prevent horrible flashing. Made pieces mortal. Made a video demonstrating the zoom functions and piece sprites: http://www.youtube.com/watch?v=XIKouIOXPtY

Pieces are mortal - time to make them capturable! Planned and implemented the generic piece AI, capable of 4 out of 5 of the behaviours I want (the "protect" behaviour requires an extra, more difficult feature). Loaded behaviour definitions from files (but I only wrote two of the 4 behaviours). Took me a while to notice that the value-based AI was actually picking its *least* favourite move. Discovered this because a lot of pieces set to "Kamikaze" were ignoring all opportunities to capture enemy pieces...

Next problem with the generic AI was that the move-choosing method sorted by target coordinates when values were equal. This meant that *everyone* beelined for the bottom-right corner of the map. And captured their friends. Fixed. I added a behaviour that causes pieces to seek friendly pieces' cover, which made them form clusters. Made a video of that: http://www.youtube.com/watch?v=ght5eUgH3QM. I changed the friendly/enemy cover colour scheme from green/red to green/magenta to improve colourblind usability.

6 days into the 7 days challenge, I had exactly zero ways of letting the user interact with the pieces. This needed to change, and the first thing to do was implement selection and commands. Dragging boxes with the mouse is pretty awkward on a scrollable zoomable map, but I managed it. Set selected pieces to flash regularly. I didn't have time to implement complex things like orders to attack specific units or groups of units, so the only command you can give (and really the only command you need) is to set a destination box by right-clicking. The distance from the destination box feeds into the unit's value system and lets them follow orders - within reason (trying to stay out of enemy-covered squares, taking capture opportunities, etc.). I made a video of the epic battles possible with this command system: http://youtu.be/LA75nbdoZU4

At some point there was some sleep. I also started ignoring the TODO list and scribbled down a list of priorities for giving the game some semblance of strategic depth on the last day.

At some point this day or yesterday I decided that playing this game against an AI was a terrible idea, and that playing this game over a network was not something I could code in 2 days. It had to be local multiplayer. Switching control between black and white and playing against oneself or a real-life friend.

DAY 7

Epic battles are only meaningful if you can tell who came out on top. Added piece counters for both players.

Added an interface, the screen looks so much nicer at minimum zoom now. Buttons to select all units (which gave me trouble when I recorded the previous video), or to select all units of a given type, or to restrict the current selection to units of a given type. 20 minutes left.

Added buttons to switch pieces between behaviour types, with no feedback of any kind as to what behaviour they now follow. Added a key to delete pawns and earn money, and buttons to upgrade piece speed and pieces' chance to cheat death. Again, no feedback. 5 minutes left. No chance of adding feedback for these features now. Users will just have to keep track themselves...

Updated the readme, took screenshots, submitted.

I really want to add those few sf::Text objects to make the game more intuitive. Maybe a button to display the controls in-game. This will all have to wait for a non-7dRTS update.

Some other post-Monday day

Made some minor changes to respond to vague criticism. Added a help button that describes the objective and lists controls; made the upgrade/AI buttons display their current values; slowed down both movement and production of pieces, and limited production of pieces to their Kings' side of the board.

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. http://dl.dropbox.com/u/6433222/encircled.zip

 

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

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.

Download: http://dl.dropbox.com/u/6433222/encircled.zip

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

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

Changes:
 * 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
Download: http://dl.dropbox.com/u/6433222/mutantaliens_update4_arrp.zip
Roguebasin: http://roguebasin.com/index.php/Mutant_Aliens!
Roguetemple: http://roguetemple.com/forums/index.php?topic=2255.0

Encircled, version 0.4.1

Changes:
* 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.
Download: http://dl.dropbox.com/u/6433222/encircled.zip
Roguebasin: http://roguebasin.com/index.php/Encircled
Roguetemple: http://roguetemple.com/forums/index.php?topic=2689.0

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.