Saturday, 23 November 2013

TVTropes Game Jam 2013

This is a placeholder post wher you can look for up-to-date information on the TVTropes Game Jam as it progresses. I'll post links to useful websites here.

Saturday, 31 August 2013

Command - Post Mortem

Command has been on the backburner since the first version of Encircled was released about a year ago. It is now officially dead, as I've identified it as an overly-ambitious and excessively simulationist project that wants to be too many things at once. This excess stemmed from its two main aims as a game project:

  1. It wanted to enable the player to answer the question "Would I be able to take a city full of civilians with no military training, march them for several days through their own and a hostile land, curbstomp several trained armies (at a technology level similar to that somewhere in the real world at some point between 1000BC and 1000AD), and finally sack a city, without receiving any reinforcements along the way?".
  2. It wanted to be a strategy game that has a plausible model of the flow of information in a battle of such an era; the generals would have immediate knowledge only of what they can directly see and hear, and all other information would be delayed reports from scouts and lieutenants, and all orders not transmitted by loud instruments would have delayed effect.
Both of these seem like reasonable concepts for an ambitious strategy game, but doing both in the same game is probably beyond my capabilities as a solo developer. They'll go in the ideas file as two separate ideas. Maybe something to look at for the next 7dRTS, provided it happens (and preferably if it isn't hosted on the Ludum Dare site, because I don't like the feedback system it imposes on game jams).

The first of those concepts seems very similar to FTL and would likely have similar balance issues - trivial when ahead of the power curve, impossible when behind it, and challenging (but very likely to result in death) when matching it. For that reason I will probably choose to tackle the second concept first. I haven't heard of any games that do that. Apart from possibly Mount&Blade, but from what I've seen that one looks a bit heavy on the power-fantasy side of things to give much weight to the difficulties that arise from realistic information transmission in battle. I haven't exactly played it :)

Friday, 2 August 2013

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.

Overdue Update

Quite a lot's happened since the last update. In order:

  1. Failed to write The Time Travel Trickery Tshallenge's Temporal Tumbledryer within the 7DRL time window.
  2. Started on a less ambitious 2DRL project, Threaky Thriday Thieth.
  3. Completed the game system but failed to write an AI that makes the game worth playing.
  4. Moved house.
  5. Discussed 7DRL failures on Roguelike Radio.
  6. Added several more files to the ideas folder.
  7. Decided Threaky Thriday Thieth would be easier to program and easier to enjoy as a multiplayer game.
  8. Entered the 7DRTS challenge with Schaak!, a large scale real-time chess variant with local multiplayer.
Feedback's starting to come in, and it looks like the main feature request isn't to increase the depth of the production/economy side of the game, but to make it a network game. So that will have to be the priority for future development.

Friday, 8 March 2013

The Time Travel Trick­ery Tshallenge’s Tem­po­ral Tumbledryer

Reposted from 7drl.org

Partly inspired by timerogue (a 2008 7drl that didn't get very far), and Achron (a strategy game that lets units travel through time), this year I'm going to make an attempt at a roguelike with time travel-based gameplay. The player will pull off various bank/art gallery/museum robberies, until they get caught and some government people rope them into thwarting the plans of an evil genius in a volcano base.

Within the temporal bounds of each mission I'll be aiming for total freedom in time travel - just decide to jump and set a time offset or absolute time, and you go there. Careful timing and flexible planning will be necessary to get around or defeat armed time travellers and guards. I'm not sure how much to reveal about the time travel mechanics at this early stage, but suffice it to say it will be easy to generate paradoxes (the simplest option being to take a step, go back 3 turns, and shoot your past self in the head), and I've spent a lot of time planning out how they should be dealt with (ie. not with immediate failure - some paradoxes may be desirable).

I'll use SFML for display rather than libtcod, just because I haven't had any difficulty with linking it on linux or windows. I'll probably crib some display code from Surrounded.

For those curious, the Temporal Tumbledryer is a critical element in the cycle of stealing things, using the money to refresh supplies, and using the supplies to steal more valuable things. A very noble cause.

Monday, 25 February 2013

Blood Sports



That's right, if you get hurt you spray red circles and white numbers everywhere. The game's plot might mean that the blood splatters don't survive in their current form to the final game, but the system's in place and quite flexible. It also needs to be totally replaced because it's the biggest bottleneck in the game.
In other news, you'll notice the actors are all clustered around the rat-king player character rather than lounging around like the previous screenshots.  That's because pathfinding has finally been added. I've done it in a reasonably generic way - actors follow pathers, which are Dijkstra maps updated each turn. A pather is defined by a set of passable terrain types and a function that determines whether each tile is a target, so all of the AI types in the original Encircled will be expressible quite concisely in this format. At the moment they all behave as simple chasers.
There's really nothing left to do (apart from speeding up the particle system) that doesn't depend on getting Lua integrated, so that will have to be next. Not looking forward to this.

Monday, 18 February 2013

Progress!

Surrounded now loads spritesheets and Lua files from a mod directory, switches between two spritesheets (with tile sizes determined by Lua) at the press of a button, centres map displays that are smaller than the game window, and smoothly scrolls map displays that are larger than the window. The player sprite is animated, and characters face in the direction they last moved (an aesthetic effect only). Each actor has a green/red health bar on its left, but they're currently upside-down.
Not really progress, but character sprites are randomly selected when spawned, so screenshots look a bit more interesting. Character sprites are all from opengameart.org.

Wednesday, 30 January 2013

Lua

Yeah. Surrounded is going to be scriptable. Primarily this will enable mods to alter the way weapons are used and the way levels and actors are generated, but I also intend to make an event system and allow scripts to stick dialogue/narration/info on the screen.

Weapons in particular are going to be very flexible. They could require a pattern match for the user, target, both (classic Encircled), or neither (classic RL), and each square of the pattern could match any subset of up to 16 terrain types. Patterns could be transformed according to any subgroup of the octagonal symmetry group. Weapon range could be any integer from 1 upwards (but to make it fair on the player, mods should restrict maximum range to fit the number of tiles on the screen). Weapons could hit any number of targets from 1 upwards. Weapon damage could be any number (and damage could even be inflicted dynamically by the script, enabling Hydra Slayer-like mechanics). Actors could have movement types that restrict them to a particular subset of terrain types (Like the red-blue things in HyperRogue II/III or the ghosts in Angband). Ranged weapons could require line of sight that only passes specific terrain types (so that a bullet, but not an arrow, can be shot over lava), and the user and target locations could be included or excluded in this line-of-sight (so that a ghost hiding inside a wall can or cannot attack or be attacked). Actors could potentially inherit their movement type from their weapon's line of sight, or vice versa. This could lead to lock-and-key type puzzles. Some weapons could also work by counting the number of tiles matching subsets of terrain. Sprite sheets of course would be redefinable.

Depending on how crazy I'm feeling, I might allow pattern matching to include tiles at arbitrary offsets from the pattern's centre. That would be rather difficult to represent in the UI, though.

Using all of these features in the same mod would likely lead to confusion, imbalance, and unplayability, but I'll assume that modders (and I) have enough restraint to use subsets of the available features that lead to entertaining and comprehensible games*. The point is that not having to recompile every time I change game content will allow me to balance the game much faster. If it's done in time, I could even make a mod in for 7DRL this year (which I expect is going to be a busy time in real life).

* But I promise to include one mod that uses every mechanic in the game. It might be difficult to make it winnable...

Monday, 21 January 2013

Smooth Animations

Yep, I wasted few hours making actors in Surrounded slide from one tile to the next. Doesn't feel like a waste, though - the effect's quite pretty.

The moving animation is independent of the engine, so the user can interrupt it at any point with their next command. The actor sprite then jumps to the next position and resumes movement. In order to make this smoother, the game remembers the length of time the user gave the last few animations. It averages these to predict the most appropriate speed for the next animation. Thus, if the user types input at a more-or-less constant rate, the sliding will mostly be continuous, without pauses or jumps. Artefacts may be noticeable at the first of a sequence of fast moves, or after a series of fast moves.

Also, actors fade in when they first get put on the map.

Wednesday, 16 January 2013

Doing it properly

The trouble with spaghetti code is that it's too rigid to comfortably fit in a different box to its original. Surrounded was mostly working nicely, but there were missing pieces of user interface (mostly monster health), nasty bugs associated with victory/defeat, and a general inability to add all the cool new features I wanted to.

So, refactoring. I started that by attempting to write a basic GUI menu system in raw SFML. Bad idea. After deciding to use a library, and eliminating GWEN, libRocket, SFGUI, and a few others, I settled on CEGUI. Bad idea.

CEGUI was the only usable thing left though, so I struggled through it and managed to get a menu system with a decent look and feel running. The CEGUI standard skin, Taharez, is very complete and looks good, except for the default cursor which is insupportable. Luckily I managed to find GlossySerpent, which looks like a homage to Warcraft III and has an acceptable cursor. Not ideal considering the more sci-fi-like angle I took when figuring out a setting for the game, but it'll do for now.

Yes, Surrounded has a setting and a plot now. It was quite difficult to figure out a world where such Schoenbergian game mechanics would make sense, but somehow it only took a day to figure out.

Anyway, I can now define menus quite nicely in XML using CEGUI's GridLayoutContainers to avoid specifying exact locations (but calculating the margins takes some effort). That means I can actually start focussing on transferring in the game code - the 96% of the work which will probably take 20% of the effort.

Yes, I've been drinking the optimist kool-aid.