Monthly Archives: August 2013

When working on Travelogue, at some point I crossed a threshold where it became hard to come up with new ways to reward the player. The more items I created, the less space there was for interesting, distinctive item properties and effects. This all boils down to an idea I call ‘mechanical hooks’.

A game will end up having some basic set of mechanics – you can move your character, perform an attack, deal damage, get hit, take damage, etc. Each of these basic mechanics gives you a hook that you can use to modify the gameplay later on with items, experience levels, special abilities, and so on. The number of distinctive ways you can hook into these basic mechanics determines the maximum amount of variation you can have in your gameplay – variation you can use to distinguish character classes, reward the player, allow for growth and customization, etc.

In the above example, you could have effects that change movement. If you have an overhead game like Legend of Zelda, then the character’s movement speed is probably the only real hook you have so far. But if you introduce terrain that blocks your movement, each such terrain gives you a new mechanical hook to create an ability to bypass that limit. If you have a side-scroller with jumping, now you can independently modify movement speed, jump height, and even hover time (e.g. the differences between Mario, Luigi, and Princess Peach in Mario 2). If there are other consequences of movement, such as D&D’s threatened squares and Attacks of Opportunity, then these provide another hook.

With ‘perform an attack’, if you just queue up a strike and the game computes the result, you pretty much just have ‘does it hit or not?’ as your hook. If enemies can defend, then you can now have hooks that tie into disabling enemy defenses. And so on.

Its not necessarily the case you want to maximize the number of such hooks you have – you could easily get to a situation where the game becomes too complex for the player to follow if you just indiscriminately create subsystems in order to be able to modify those subsystems later. But I think it is useful when designing the base underlying mechanics of the game to ask ‘what are the hooks that I can modify later, and do I need something richer to support a game of the length and complexity that I’m trying to create?’

travelogue_glitch

Now that the content I’m directly responsible for is done, its time to turn towards fixing things up a bit (by the way, I completely neglected to do that today and instead wrote up three new event cards…). I expect to be getting a number of bug reports from testers this weekend, but until then I’ve found one of my own. The screenshot to the right is Travelogue running on Node-Webkit right after an event card has finished. Notice the directional arrows? Somehow its getting stuck into the ‘darken’ render-mode for all the HUD elements. This also extends to the red (now black) lines that indicate the path you’re trying to take.

Mercifully, this seems to be the only major bug so far on Node-Webkit, which is really a quite gentle porting experience compared to porting a C program from Linux to Windows or something.

portrait1 Code bugs aren’t the only thing to fix though. This portrait is the replacement for the first portrait I drew – when I started, I was doing everything basically straight from my head, the result of which was the silly-looking portrait you can see on the character screen image a few posts back. After that I realized I could get much higher quality using reference photos and trying to stay faithful to actual anatomy. So the followup portraits are much better. The problem with reference photos is when you neglect to make sure to correct for size. This guy in particular looks like a giant compared to the other portraits, in which the heads are about half the size. Just more little things to take care of.

The other kind of fixing-up is editing work. Our resident writer and historian, Dangerwaffle, went over and rewrote the text for all of the ‘wandering encounter’-style event cards last weekend, which is an incredible feat considering that a) half of it is Javascript code and not text, and b) its somewhere between 50k and 80k words. I’m incredibly grateful that I did not have to be the one to do that, and you guys would be too if you’d seen my writing before that.

 

Whew, that took way too long! The Merchant Quest was one of the three remaining things necessary to do before Travelogue is in a releasable state, and it was about as long as the entire rest of the list. The final event card is 1300 lines long (a lot of those lines are ‘{‘ or ‘}’ though), which is nearly twice as long as the next-longest card. I’ve also had some time to add a few perks for rich merchants, since there wasn’t much to buy that cost more than 1000 mils or so, and you’re supposed to make 30k mils to win the game as a Merchant. You can now invest in towns to get better prices for your goods there (up to a 5k investment for +20% to the sell prices), buy a ship for 5k, or get some nice clothes for 1k that improve your skills in social situations.

I’ve also been hankering to do more content for my Ludum Dare entry Rebound Recon, though I can’t actually change the submitted entry. Following some of the advice in the comments, I’m adding some levels to space out the introduction of new objects (I’m up to 9 new levels so far) and I’ve made a demobilized version that has a better interface for PC users – right clicking to delete nodes, mouse-wheel zoom on the level maps, viewport scaling to fit the browser window, that kind of thing. If I have time I’d also like to add air pumps where you can refuel, turrets that fire another entity at you when you get close, laser grids that ‘cycle off’ for two frames each second so you have to rush through at high speed, things like that.

rebound_shot4Rebound Recon is done and submitted with about an hour left on the clock. It took a bit longer than I’d hoped to make the levels look pretty rather than sparse, and I would have liked to do custom graphics for the three endings, but all in all I’m pretty satisfied with this. The game is playable on the web (no specific plugins needed, and tested in Chrome and Opera so far), and should also run on mobile browsers, though I’d recommend a decent screen size – it will be really awkward on a tiny cellphone.

Now for dinner and to maybe play some games instead of coding them.

Link to the Rebound Recon page on Ludum Dare


I took a few hours to make music for the game, which was a welcome change of pace. I was starting to get stuck in a bit of a rut trying to decide which bit of polish to finish up next, whether to add more levels and objects, mess with the way the plot is displayed, etc, and I was just doing smaller and smaller things. Hopefully this gets me back on track!

Rebound Recon with controlsMuch like the nervous moments in Kerbal Space Program when you’re making the transition from a long fall to a true orbit, Rebound Recon has reached the point at which I think it can be safely called ‘a game’ rather than a non-interactive trajectory plotter. You can now place points at which you expel some of your supply of air, changing your trajectory and the game checks to see if you get to your destination before the 10 seconds are up (even if it doesn’t actually do much yet when this happens). You can also click to play through your trajectory, jump to different points in time using the timeline, etc.

There’s still some UI confusion, part of me trying to design this so that all interactions take the form of a single click (but the plus side is it should play fine on mobile). For one thing, clicking to go somewhere on the timeline can overlap with clicking to remove one of your ‘burns’ – oops! I think I need to make some space for a special slider-bar that moves you along the timeline, or else I need to place the ‘remove node’ button somewhere else.

There’s a little over half of Ludum Dare left, and I haven’t touched music or polish aspects at all – this will end up biting me, I’m sure. I would like to have a few tiles just there to break up the monotony, a few animated tiles, and a pass to make the game ‘juicy’ – have things squash and deform when they collide with each other, that sort of thing, but the priority for now is getting the core gameplay in.

The list of things to do, roughly in order:

  • Go to the next level when you beat the current level
  • Slider-bar for the timeline
  • Implement all three of the buttons at the bottom, not just Go!
  • Put in translucent indicators of relevant events that occur along the trajectory (collisions with entities mostly)
  • Make a main menu with a How to Play screen
  • Code up the Button, the Airlock, the Spikes, etc. Decide if I really want Bouncers to collide with Buttons (its kind of cool, but then I have to do entity-entity collisions which would slow the trajectory calculation down)
  • Animations for jetting air, arriving at the exit, popping when you hit spikes, etc
  • Make 5 levels
  • Music
  • Make another 5 levels using more advanced concepts – fans, refuelling stations, etc

rebound_shot1As I head to sleep on the first night, here’s a screenshot of my progress so far. The red line is the pre-computed trajectory of the little balloon thingy. The airlock is the target you’re trying to get to. The HUD displaying the timeline and where you’re using your fuel isn’t in place yet, but collision detection with the tiles and the trajectory computation stuff is roughly in place. I have a feeling I’m going to need to speed it up, but I can get a factor of 3x just by using fewer frames for the simulation and interpolating between them when I draw it all out.

I’m debating whether or not to cache the trajectories of every object, or just cache the player’s trajectory and figure out everything else on the fly. I probably should cache them, honestly – its not that much memory to record 300 frames of motion, and that makes play-back a breeze.

reboundreconI’m going to be participating in Ludum Dare this weekend, so either I will focus down and only work on the game for the next 48 hours, or I’ll spend lots of time posting updates and jeopardize my chances. It’ll be exciting for me to find out which I end up doing!

For the game I’ve decided to make something called Rebound Recon. I was going to call it Rebound Rendezvous or Rebound Reconnaissance but I realized that it will never be spelled consistently, even by me.

The idea is that you’re piloting a sort of scouting drone, a remote-controlled balloon filled with air that can release air to change its direction. However, you must plot its course such that it completes each level in ten seconds, before the security forces manage to close in and capture the drone and the sensitive information it has extracted. The good news is you have powerful computers at your disposal that can exactly calculate what the trajectory of the balloon is going to be before you commit to it. I’ve got a basic idea of the components, the UI, and what needs to be done.

This will be the first time I’ve used JSON tile-based levels in an HTML5 game, so that will be interesting. Hopefully there won’t be too many nasty surprises.

New UI Graphics

Character screen for Travelogue with tiny buttons and text

The old…

New character screen for travelogue with big text, bar-display stats

The new!

 

 

 

 

 

 

 

There were several elements of the user interface, particularly the character screen, which were going to be problematic for when we eventually want to port Travelogue to mobile platforms. Also, it just didn’t look very good. So I went and tried to spruce up the interface a bit, made the control elements and text bigger, etc. I was going for that hand-drawn look, which I’m not quite sure I achieved, but it definitely looks a bit more like a character sheet and less like a table

Derailed

So I got completely derailed from finishing the merchant quest, which was what I was supposed to be doing today. Instead there’s now a fairly long one-off event specifically for death-aligned (low-karma) regions. All in all its a mixed bag – there’s one ending thats good for everyone, one ending thats very good for the player, and an ending thats very bad for the player.

I also added a more strictly negative event that happens at low unrest (once the roads are safe for tax collectors…)

Tonight’s our (rescheduled) meeting to go over cards together, which I’m looking forward, though I’m skipping out on the local Go club’s weekly meeting for it.