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:

Christmas Update

December 25, 2009

Progress on the game continues, although I really ought to pick up the pace. You can build new ships now (you could before, but there was no UI to change the type, so all you’d get are scouts). I’ve largely fleshed out how technologies work and coded definitions 60-70% of them – weapons, shields, armor, engines, power sources are all done. Research is half done, with some UI work left to finish. I’ve also done various optimizations, tweaks, fixes, and other uninteresting work.

Combat will be tactical and turn-based. It will be  halfway between the combat from MOO 2 and what Gratuitous Space Battles should have been, if you could control the ships rather than idly watching them. After mulling it over for several weeks, I’ve settled on using normal-mapped sprites rather than plain sprites or 3D models for the ships. This will let me add a high level of detail to the ships, with lower system requirements (maybe), while still being able to light them realistically in 3D as they turn and move. The trade-off is that it forces a fixed overhead perspective, but I think that’s fine. You’ll still be able to zoom in and out, and 3D cameras in a 2D battle space don’t add much value. I dismiss the alternative of conducting battles in full 3D as being cumbersome and inappropriate given that combat here is just part of a larger game. I’m excited and eager to get working on the battle engine.

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 http://twitter.com/funcallgames 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!

First screenshots, interfaces, thoughts

December 8, 2009

Work on the planet and  colony interfaces has made great strides over the last several days. This has taken longer than it should have, possibly because I believed it would be more difficult than it really was. I’ve had to rework the economy simulation somewhat to incorporate the spending controls, but the result looks good and will minimize micromanagement. Construction of ships and missile bases now works. With that in place, I’ve decided to post a few early, work-in-progress screenshots. Tomorrow’s project, once I finish writing detailed descriptions of all the planet types, is to work on the fleet panel which will let you issue movement orders.

First, the colony panel. This drops down when you select a star system which you have control and shows you all the vital information about the colony. Spending controls allocate percentages of the remaining production in a cascading fashion from top to bottom – you can see here that “Growth” is taking the bulk of the funds. You can rearrange the sliders to reflect different priorities. On the right you can see that the colony is building Scout ships. Pressing the Shipyard button will open another panel allowing you to select which kind of ship to build. A few finishing touches, like an ETA for ship completion, still need doing. Notice the UI elements match the player’s color choice.

Second, the planet panel. This describes uncolonized planets which you’ve explored. You can also toggle between it and the colony panel once you’ve colonized a planet, although it isn’t necessary (everything you need to know is available on the colony panel). The terrain distribution is unique to each planet, with trends determined by planet type. Presently the terrain amounts determine the planet’s maximum population and  its natural capacity to absorb pollution. Among the various alien races which you can choose to play, some will be better suited to terrains other than solid land, and their preferences for which worlds are most desirable will differ. I’d like to do both an aquatic race and a race modeled loosely on the Mycon from Star Control 2 who will prefer volcanic terrain, provided the experience of playing as them sufficiently distinct from the other races without unbalancing the game.

A vision of how the combat system will work has started to materialize, and I’ve some good ideas about the ship design UI as well. Combat is tricky, because it must be fun but brief, and supports ship design by giving you an opportunity to see your designs in action (which likewise give you an opportunity to apply your researched technology). The danger of putting too much detail into combat is that if battles become very involved, it slows the game down and detracts from the higher level strategic gameplay. Combat should involve huge fleets pounding each other into oblivion and not degenerate into protracted maneuvering and evasion. I’ve also thought about whether it makes sense to build the AI around something resembling a blackboard system, versus what I think is a more conventional design using multiple layers of decision-making and thresholds applied to weighted sums of various evaluators. Writing the AI will be very interesting.

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:

Planets

Planet panels, AI musings

December 3, 2009

I’ve made good progress on the panel UIs for viewing stars, planets, and colonies. These slide down from the top of the screen when you click a star system on the map. Which one appears depends on whether you have explored the star and have up to date information about it. I’m really happy with how they’re looking. I’ve finished the star and planet information panels. The colony panel presents its information about the colony but doesn’t implement spending controls. I’ve sketched out a design in Inkscape, but I want to think about it more before committing the details to code. Having a working planet panel led me to spend some time scrolling around various random maps, inspecting planets and tweaking creation parameters for the planet types to make them bigger, smaller, more or less hostile, and adjust the balance of terrains. I also added planetary mineral wealth to the map generator. The panels look great but highlight the need to finish artwork for all the planet classes – only half of them have unique images so far. I’ll take a stab at that today, along with some work on the colony controls. I’m eager to get that done and move on to fleet controls.

Once I have ships flying around, I could piece together a playable subset of the game with a few days effort. There’d be huge swaths missing (research, ship design, tactical combat), but it would be a useful milestone. I suppose I’d have to add a crude AI in there too. I don’t think that would take very long. It might even be a better approach versus putting the AI off until later, as it would give me a manageable starting point and shake out the worst of my ideas early. If I put the AI off until the game was closer to feature-complete, there’s the risk that I get paralyzed trying to juggle all the game’s aspects simultaneously and don’t know where to start. Growing the AI incrementally seems worthwhile.

I’m tempted to post screenshots, but I think I’ll wait until I can spruce the space backgrounds up. I’d also prefer to wait until there’s more going on in the star map to show off.