Archive for the ‘Uncategorized’ Category

Laser Spigot postmortem

March 30, 2010

Laser Spigot didn’t make a huge splash (the pond of roguelike gamers is pretty small anyway), but it was well received by the judges at the Roguetemple challenge evaluation and the early testers on #lispgames. It’s unfortunate that I’d declared it done except for bug fixes by the time I’d released a test version, because the #lispgames folks made some suggestions that would’ve improved the game, and the challenge judges offered some critiques and ideas that shed light on the game design and how to improve it. I consider Laser Spigot “frozen” for the time being (I really need to restore the focus on my primary project), but maybe I’ll do an enhanced version for the Roguelike Release Party this fall. I definitely want to do another hex RL.

Here’s my thoughts along with what I’ve come away with from the feedback I’ve received:

  • Text prompts should persist on the screen longer than a single turn.
  • You should be able to access the help screen while playing.
  • A look feature would be useful (I was going to do one with the mouse, but cut it due to time constraints and the very small number of items/monsters in the game).
  • Another day spent adding a few more enemy types and adding more variation between the levels could’ve really improved things.
  • The laser controls are a bit wonky – maybe the laser beams should move first, so they don’t (sometimes, inconsistently) block the player moving behind them.
  • A move to fire the laser and step backward would be cool (suggested by one of the anonymous judges).
  • I really should’ve spent the five minutes it would’ve took to make sure the game doesn’t try to play the same sound effect twice or more simultaneously, resulting in clipping distortion.
  • The map generation algorithm isn’t ideal, usually resulting in the player entering in a central hub and having to explore the outer edges for the next stairs down. It would be better to start the player near a corner of the map, so that the direction to explore in becomes more clear.
  • I have doubts about the basic energy conservation mechanic as the sole physical constraint on the player, since most or all of my successful runs have involved some boring recharging in a remote corridor (usually following a RepairBot around to drain tiles as he fixes them). Adding energy capsules would provide some motive for exploration, but might make the game too easy.
  • Foiling idle recharging by spawning additional seekers (or worse) over time was my original, unimplemented idea.
  • Items, along with the aforementioned map generation changes, would make the exploration aspect of the game more interesting.
  • The major unimplemented idea, which I originally envisioned as central to the gameplay, was to be the ability to project a forcefield in a straight line outward to block pursuing monsters.
  • Amusingly, someone complained that the monsters were too smart and outwitted the laser, but they contain no logic to avoid the laser at all! It emerges as a consequence of their path-finding – the laser beam blocks the path toward the player, so pursuing robots route around it unless they’re trapped or the cost is too high.
  • Was one screen of introduction text really tl;dr?

Thanks to everyone who played Laser Spigot.

7DRL “Laser Spigot” and February Diversions

March 15, 2010

Lots of work done during February (and early March), yet silence on the blog. In fact, I’ve gotten some interesting things done over the last few weeks, most of which aren’t directly relevant to the game. Game-wise, the progress has been toward the ship designer and a fair bit of work put toward some general graphics routines which took more time than it should have.

First, I’ve gotten a development environment set up on Windows and ported the game to it. Previously, I’d been working exclusively in Linux. There’s a few issues and bumps along the way, but everything basically works.

I’ve done quite a bit of work that’s entirely off-topic – a few days spent sketching out what a Lisp to C++ translator might look like, a simple pixel art animation tool called McPixel (not useful for this project, but definitely for things in the future, including an idea for a side project I’d like to tackle in the near term), an NSF player, etc. A few days wasted toying with a bot for the Google AI challenge right before the deadline, which I never bothered submitting because I knew I’d need a few more to produce something competitive.

More interestingly, I spent last week doing an entry for the 2010 7DRL contest, called “Laser Spigot”, which was a lot of fun to make. It is minimalist as roguelike games go (no lighting, inventory management, or experience points), but fast paced and with a polished presentation. It uses a hex-based map layout. I was skeptical of this idea but wanted to try it, and it turns out to be a real joy to control, as you can map the movement directions to a 3×2 region of keys such that they fall under your middle three fingers naturally. Much more intuitive than, say, the Nethack control scheme.

I’ve had reports of compatibility problems with some people’s machines running this, which I haven’t investigated yet. If anyone finds this won’t run on their machine, I’d appreciate an email with details (whether there’s a message box with an error, or if the screen just flashes and nothing happens then the contents of the file “errlog.txt” if it exists). It’s probably an OpenGL issue, but I’m sure I can work around it once I identify the problem. I plan to release a Mac version, but I can’t promise when, as I do not presently own or have access to a Mac.

I enjoy the hex-based controls and the general style I’ve developed for this game enough that I’d love to build a more full-fledged roguelike around them. Laser Spigot was feature-complete on its fifth day of development – the sixth day was spent finishing the introduction screens, packaging the Windows binary, doing the web site, and fixing a couple last minute bugs, so really you could call it a 6DRL. There’s only so much I can do in five days, and at that point it felt like just piling on more stuff (monsters, items, etc.) wouldn’t do much to enhance the game play.

Download Laser Spigot now! (7 MB, WinXP or later, requires OpenGL 3D accelerator).

Battleship Art

January 30, 2010

Here’s the battleship, a new ship design I’ve just added to the game:

Surely, a ship like that must have “Bad Mother Fucker” printed on the other side.

Recent Progress

January 26, 2010

The blog may have been quiet for several weeks, but I’ve been steadily working (and tweeting). Tech research is finished, I’ve integrated sound and music (although plans for the soundtrack are still up in the air), and made a number of UI improvements. I’ve implemented the code for normal-mapped sprites which combat will use, and I’m pleased with the results. Right now I’m using a shader (via ARB_fragment_program). It occurs to me that I could get the same effect on some older cards using the dot3 bump mapping support that’s probably been around since the original Geforce, but I think I’ll stick with this approach.

One thing I’d wondered is how to deal with different player colors for the ships in combat. For UI elements, which are generally text or monochromatic vector art, I modulate by the primary color, but that doesn’t work for ship textures where you want them to be mostly metallic gray, with accents of the player’s color. My solution is to permute the color channels using a swizzle in the shader, so that grayscales are preserved but the source texture can be transformed to match the player’s color scheme. I’m happy with result, aside from having to compile a separate version of the sprite shader for each player.

I’ve been working on the artwork for ships in combat. I’m doing modelling in Wings3D, then importing the models into Blender to generate normal maps. I do exturing in Gimp, using the normal map as a guide. The workflow was rough at first, with some import problems (most notably, smoothing information being lost/ignored by Blender), but I’ve steadily refined the process. Most recently, I’ve simplified things further by painting material colors on face by face in Blender and generating an initial texture from it alongside the normal map, so that all I have to do in Gimp is add final detail and grunge. Painting colors by face is great for littering a starship hull with panels and variation. It also sucked having to trace curved geometry by hand for the first few ships.

Next on the agenda is the ship design UI. To design ships, you’ll start with a basic class/type/hull (haven’t nailed down the terminology yet) as a template, and fit equipment. This uses a blueprint-type view. Equipment choices include weapons, armor, engines, shields, and miscellaneous devices. An idea that only recently occurred to me is supporting carriers with fighters by adding a fighter bay tech that can be researched and added to ships. The idea is that you’d design fighters based on the smallest ship classes, leaving out an interstellar-capable engine and using the space saved to add better weapons and shields. Carriers add a fighter bay, and the amount of unused space in the design determines the number of fighters they can carry. This has to be abstracted somewhat, otherwise it’d always be a bigger win to load the capital ship up with extra weapons rather than carrying fighters.

The mechanics of combat in the games I’m familiar with strongly favors the largest ships. In MOO, ships in the middle of the scale are often neglected. I want to avoid that with a balanced interplay of ship maneuverability, firing ranges, and biases in the suitability of weapons toward certain ship types. I haven’t worked out specifically how yet, but I have some ideas. The brute force approach is to make larger ships less cost efficient, but that just constrains the space of useful designs without adding richness to the gameplay.

Here are screenshots of some ship designs that are finished so far:

New Screenshot

December 17, 2009

Rather than continuing to maintain radio silence, I’ll post a new screenshot showing the controls for directing fleets. When you click a fleet, that panel pops down, telling you where the fleet is going. You can adjust the numbers and break portions of the fleet off to a different destination. Clicking the destination and closing the panel works, as does just hitting “Next Turn”. Alternately, you can middle click the destination, which sends the selected ships off then shows the remaining ships in the panel. This is handy when you have several ships and want to send them all to different destinations. It’s subtle, but this screen also shows that star systems within movement range glow blue when you open the fleet panel. The effect is animated and fades in and out. It’s a nice touch.

Fleet Movement

Now I’m working on the backend simulation again. I’ve been fleshing out technologies and linking that in with various aspects of the simulation (range, speed, special abilities) that had been stubs before. Defining the technologies is the fun part of this. I’ve vaguely sketched them out on paper, mostly to brainstorm names and their approximate ordering. Now I get to define them in code. The next major task will probably be the UI for research controls.

Still need to put together some fancier nebula-ridden backgrounds…

Funcallgames now on Twitter!

December 12, 2009

I’ve set up a Twitter account at providing an exclusive window into the design and evolution of the game. Far from the sputtering, banal minutiae typical of Twitter, it is destined to be regarded by future generations as a historical artifact rivalled in significance only by J. David Markham’s landmark 3,591 page volume assembling the meticulously recorded daily inventory of Napoleon Bonaparte’s sock drawer . Follow me and witness history in the making!

Planet Renders

December 4, 2009

All the planet types have unique images now, which makes it much more fun to scroll around the starmap and see how the universe was populated. For debugging, I have a cheat key that explores all the stars on the map so I can see them quickly. A couple of them could use some tweaking, but on the whole I’m happy with them. Here’s a nifty chart of the 13 planet types: