Monthly Archives: August 2013

I’ve been worrying a bit of late how to get updates to people who buy Travelogue. Our plan has been to use FastSpring for our storefront, but for digital downloads they only provide the download for a short period of time, after which the link expires. I don’t relish the idea of going and reactivating a hundred download links by hand if people want to re-download a game they’ve already paid for.

My thought has been to set something up where the purchase basically gives you an indefinite subscription to part of our site where you can download the game and all future updates. That does add a bit of a bothersome step though – you’d have to have an account on our site before you bought the game. I’m not sure how bad that’d actually be for most people. I also have a feeling that it will require a bit of a side-track to develop that functionality for the site, time I’d rather be spending on adding more content to Travelogue.

Anyhow, I’m open to thoughts and suggestions on the best way to proceed here.

The contact field got hit with spam with surprising speed, so I’m removing it. Please use the comment system instead if you want to give feedback on this issue.

Update: I set up something where when you buy the game you get a temporary download link, but you also get a password you can use on this site in conjunction with your full name in order to download the game and its updates whenever you might need to. Hopefully that strikes a good balance, though if the bandwidth usage is too high I’ll have to transition over to Amazon S3 or something for the downloads.

I’ve been thinking about the pacing of games, particularly simulation games. These games have a tendency to have a ‘desperately trying to survive’ phase and a phase in which you’ve basically caught your breath and are on top of things. I’m going to call these ‘non-equilibrium’ and ‘equilibrium’ respectively.

The equilibrium part is the easiest to understand – this is when whatever you’ve got built up is enough to keep you going. This is when you can go and build crazy stuff, because you aren’t restricted to do what you need to do to survive the game and keep playing. Its equilibrium in the sense that you could in principle set up some kind of routine and just iterate that routine forever, and nothing would change about the situation in the game. In SimCity this would be some point where growth is zero but you’re making a profit on taxes – if you walked away and let the game run overnight, the only thing that would change would be your bank balance.

The non-equilibrium parts are the ones where, if you did nothing special, you’d lose – your dwarves would starve, your ship wouldn’t make orbit, your city’s coffers would drain out. Usually the model for this is that you start with some initial boost above and beyond what you can yourself generate, and you’re trying to reach break-even before that boost runs out. These are the moments of the game that have you on the edge of your seat, wondering if you’re going to make it (well the first few times you do it, anyhow). Its not just tension though – when you’re in the non-equilibrium parts of the game, there’s a pressure to keep playing because you feel like there are things left to do to get into equilibrium. Its that feeling that you can eventually reach equilibrium if you just do this one more thing that keeps you hooked.

For something like Minecraft or Dwarf Fortress, actually reaching equilibrium is important, since the ability to build crazy stuff is kind of central to the experience. But for something like SimCity, especially in the older ones, equilibrium means that the game is basically over at that point. You can sit there and grow whatever resources are good to have for an arbitrary length of time before embarking on any risky endeavor. Once you hit equilibrium, the only limit to your resources is your patience.

Now, the ‘initial boost, try to break even’ model does leave you with the feeling of having to do things to reach equilibrium, but it only lasts as long as that initial boost lasts, which can be quite short. In Dwarf Fortress this is the first year basically – if you don’t have food production by then, you’re going to start to lose people to starvation. After that, you can basically wall yourself off and survive indefinitely if you want. Random disasters that require specific reactions is another model, but usually there’s very little you can do about it, so it doesn’t really hit that ‘feeling of more work to be done’, its more like ‘oh crap I have to react!’.

One model that I think works is finite resource depletion, where there’s only so much stuff in your immediate environment and you have to expand to survive (and at the same time increase your needs). By controlling the amounts of resources available in each area of the game, you can control the time the player has to complete that segment, and you can hold out the carrot of things that resolve the player’s dependency on resources or provide ways for the player to renew them in order to have something to work towards. There are surely other models that would work for this kind of extended play as well.

So for simulation-ey games, its important to keep this in mind and try to extend the non-equilibrium phase as much as possible while holding that carrot of eventual stability out in front of the player. Keeping the player out of equilibrium is really critical for giving them the feeling that there’s more stuff to do and more game ahead of them.

The home stretch

Travelogue screenshot with cloud shadows

I’ve read that the last 10% of the game takes as much time as the first 90%. Hopefully that won’t be true here! I’ve made a list of all the things that demand attention before we can release Travelogue as a finished game. There’s stuff I want to do on top of that, but this is the critical stuff.

  • Ending theme
  • Add character sprites to match the various portraits
  • Make a sprite for sailing on the ocean
  • Fix the art of the first portrait I did, which looks really bad compared to the followup ones
  • Make something happen after a year passes and the player hasn’t won
  • Separate background graphic for the hidden ending
  • Alternate ending for the merchant
  • Ability to import/export saves to disk, since right now they’re stuck in localStorage and would be a pain to transfer between computers
  • Create a demo version of the full game

And thats it on my end! I think thats not too bad a set of things that must get done over the next two weeks. There’s also going to be testing, rebalancing, etc of course. There’s also a few more things that Dangerwaffle and Whiskeyninja are working on: the Nomad quest, the Roc’s Nest, and a merchant house quest for the town of Omen.

If I have time, there are a few things I’d like to do on top of this list though. Given the expanded size of the display and the fact that the inventory was moved to a separate screen, I’ve got the space to make the skill/stat interface look a bit more snazzy. Right now its tiny little buttons and text, which isn’t really ideal when we do the mobile port, so that could stand a revision. I’d also like to put more ‘Hermit’-style events in the game – things that respond to what other players are doing in various regions. Right now there’s only five or ten such events and a few mechanical things besides that (places that are very popular amongst players will have easier access to skill trainers, for example). If I can get that number up to around 20 or 30 then it becomes a bigger part of the game rather than kind of a gimmick on the side.


Greetings! I’ve been rolling around not posting here for too long! The Hermit will be solitary no more! Exclamation points!

I’ve been working on additional content for event cards alongsie The Hermit and Dangerwaffle, and I wanted to pop in and let you know that we also have a subreddit if you’re interested in subscribing and asking questions/posting content in anticipation of release!

Check it out here

This week I’ve been helping Dangerwaffle finalize a Nomad quest, and work on the second level of our dungeon. Which involves birds, which is awesome.

More to come!

Heatsink update

Screenshot of air currents in Heat SinkI’ve updated Heat Sink to fix some bug reports about its performance on Firefox, as well as to implement some suggestions from helpful reviews on Newgrounds.


  • Performance optimizations for Firefox (and possibly IE). Dust and obstacles now use arrays rather than canvas buffers to do pixel-level collision.
  • Airflows are now visualized in the circuit designer
  • Compressed air now has an cursor icon that tells you how large of an area it will clear
  • Temperature graph, dust accumulation, and particles should now be reset when leaving the simulation and returning.
  • Background ‘dusty motherboard’ image now gradually fades in rather than being revealed by dust tracks (I’m sad about this, but it was a huge performance hog)

Future plans include a series of popups/milestones as you pass 50, 100, etc days. Another idea is to record the ‘best times’ on the server and do something like ‘your design is better than X% of all designs’.

Good news – at this point, we have crossed the line of our original projections of how many events will be in Travelogue. As of this post, we have 110 event cards including town events, quests, dungeons, and things that just happen to you while you wander around. The 110th card happens to be a dungeon event involving a salt circle in the middle of a burnt-out shell of a town on approach to the Scarhold Ruins.

Of course in another way this isn’t great news, since we finished the number we thought we’d need and I’m still working on one more dungeon as well two or three more quests, not to mention what the rest of the team has queued up. But since we have about a month to release, hitting that initial deadline we set back when we first started the project feels pretty good. It means that in under three months we’ve gone from an idea to what is basically a feature-complete and content-complete game – everything we do from here on is a bonus thanks to having time to spare. As part of this, I took the opportunity to make some music for traveling in different terrain types. The track attacked to this entry is what you’ll hear when you’re in the hills and mountains.

This also means though that its time to start worrying about things like testing, polish, packaging the game and figuring out the details of selling it. What we’re doing here is probably considered a bit strange – normally for an HTML5 game like Travelogue you’d release it and then make money based on advertising or in-game shops or licensing it to portal sites or things of that sort. Our plan is to package it in Node-Webkit for PC, and Phonegap for mobile, and sell it like you would a normal desktop game. Thanks to using the wrapper, the experience should be consistent across platforms so no annoying issue of buying a game and then finding out that your browser runs it as slow as tar or even not at all.

Now, there’s risk in this. We can obfuscate things a little and minify the Javascript, but there’s very little stopping someone from grabbing even minified javascript and hosting it for free on a portal site – its too difficult and expensive for us to try to constantly police that. We also don’t want to do some kind of ‘always online’ gimmick where the real game is stored on our server and you’re just downloading a wrapper – its poor form and it hurts our customers for no real reason. So we’re just not going to worry about it too much and just trust our customers to support us if they like our game.

As an aside, we sadly did not win the FiMaRu contest last weekend, but as this is a weekly contest there’s always next time!

I’ve decided to participate in the game contest FightMagicRun this weekend, a weekly 48 hour game development contest whose topic this week is ‘Dirt’. I’m going to be making a quick game called ‘Heat Sink’, where you’re trying to build a heat sink around a CPU that survives dust buildup for as long as possible. Although the game itself is pretty simple in design, there’s going to be a few tricky things inside of it, mostly dealing with the computational limits of browser-based games.

Basically, what we’d ideally want to do is solve the diffusion equation or even Navier-Stokes to figure out the distribution of heat inside the device as the dust builds up. That’d be moderately computationally taxing for a native application, since you’re solving a PDE every second or so. For a browser-based game we’re going to have to do something different.

Instead, I’m going to take a page from importance-sampling based raytracing programs like LuxRender. Every second the game will generate a single ‘heat’ particle, weighted based on the relative temperatures of objects in the game; it will then cast that heat particle in a random direction, compute the interaction of the particle with whatever it first makes contact with, and add that information to the state of the components. The game will remember old trajectories from out-of-date dust distributions, but over time it can build up an accurate heat map without completely re-doing the solution every timestep. We’ll see how it works or if I have to do an even harsher approximation to fit this into the computational budget.


Art day

A bar scene at night, no patrons.Today was an art day, doing ending screens for the various classes and some of the hidden endings. I’d include a screenshot of those but I do kind of want the endings to be a bit of a reward, so instead I’ve put up a background that didn’t end up getting used in the game. I’m not nearly as comfortable doing art as I am coding, but we’re a small studio so we need to be flexible and pick up skills as they’re needed. Thankfully I obtained a Wacom tablet from a colleague who ended up buying it but never using it, which helps immensely in doing the art.

The thing that has always impressed me in professional art is the sharpness of detail combined with the smoothness of shading. This is something that I’ve just never been able to get quite right in my own art, giving it a bit more of a sketch-like feel rather than something airbrushed and perfected. This particular graphic is a bit older, when I tended to use heavier black lines for laying out geometry in scenes where perspective lines are important. I’m trying to reduce that now since I think thats part of what makes it look ‘sketchy’. Masking seems like the right answer for sharp features, but I always have problems with the shading right around the end of the mask, getting the curvature of the object to appear to follow its outline right to the sharp edge.

There’s also an efficiency of brush strokes that I’m trying to learn – when you look very closely at good concept art, you can see the individual brush strokes, and the shape of the strokes are used to give definition to the smallest features (like drawing a tree trunk with a single movement). I find I have to paint over things again and again to slowly push the details and shading towards looking right, which then destroys the details of the brushwork.

Though trying for a more realistic style is helping me improve, I think there’s wisdom in trying to make games that best match the art style I have, unless we want to hire a dedicated artist for a particular project. Its one of those things to think of if you’re coming up with ideas of games to make, how to nudge the game concept to better fit the abilities of your team instead of sticking too much to the initial idea.

In other news, I got a bunch of ocean event cards from our other two authors, so there’s now stuff to do on the high seas. There’s only something like 4 ocean routes in the game, but they’re faster than land travel and don’t have issues of having to provide your own food (though you do have to pay passage).