Sunday, January 11, 2015

[MMc] Solar Golfing

I'm Morgan, a professor of computer science at Williams. My jam games are frequently space-themed and usually driven by a graphics or input idea. I'm staying with my science fiction obsession for this jam, but this time I'm going to lead with a mechanic instead of I/O.

Mechanics

I will make a game of 2D minigolf on small planets in space, Spacewar meets Desert Golfing. The tee and hole will often be on different planets, requiring the player to exploit orbital mechanics to negotiate the course. I'd like to procedurally generate the levels, but I'll start with just having a single level. I've long wanted to make a 2D physics game like this and Desert Golfing recently gave me the right mechanic metaphor. Longer term-inspirations include the Ender's Game Battle Room (at least as described in the book, I haven't seen the film) and The Little Prince.

I think I want gravity to be mostly constant near the surface of planets, and then fall off fairly quickly. I can't use realistic gravity because the scale of planets, the ball, and spaces between planets is inconsistent...the ball would either fly off the surface too easily or smash into planets too hard. I'd like players to play around a planet, like a conventional minigolf hole, and then hop up to another planet, occasionally banking around smaller satellites. A single set of mechanics and algorithms should then lead to two different kinds of play.

I plan to have the UI involve dragging backwards and releasing, in the manner of Angry Birds and Desert Golfing. One important question for the UI is whether to draw an indicator going backwards (likely not), forwards (like Desert Golfing), or forwards in the arc that the shot will take (like Gravitee).

Spacewar, originally developed in 1962. The spiral is a black hole whose gravity draws the ships and missiles.

Desert Golfing, 2014 procedural minigolf in the plane.

Art Direction

The graphics will be solid-color or simple gradient polygons and the UI a simple drag mechanism, maybe with a choice of clubs if I get fancy. I could imagine polishing by adding some simple comets and scrolling starfield in the background but am going to try to prevent myself from polishing graphics for this jam to focus on mechanics.

From looking at the reference art that I've collected, there is a particular way of drawing tiny planets with a white-blue-black radial gradient behind them. This implies an atmosphere and avoids the desolation of a pure black "space" background. I'mg going to try to avoid drawing any interiors on the planets, maybe filling them with a gradient to avoid too much flatness.

There will be only a generic swing and hit sound in the game. A future polished version could have music, sound on each collision, and reset sounds. Sound production is not the problem here--I don't want to invest time connecting the collision response system in Box2D to the audio events.

Collected reference art for small planets

Technology

This design of this game is a natural fit for Javascript via codeheart.js, using either hand-coded physics or Box2D.js, which codeheart supports directly. A web-based game is an easy way to get onto tablets and phones, which the gameplay suits well. On the other hand, I'd like to try releasing a game on itch.io and Steam to learn about that process, so making a binary using G3D would be a good way to do that. But at the start I'm leaning towards Javascript; if tuning Box2D or defining complex geometry in it becomes a time sink then I'll switch over to C++ and roll my own physics.

Monument at Tufts University by wealthy lunatic Roger Babson, which along with the Institute for Centrifuge Research ("gravity is a mistake") will be my totem for this jam.
I updated codeheart.js to use a better Javascript port of the Box2D library and familiarized myself with it. This will handle the physics, which are mostly collision detection (since there's only one moving object, the ball!) I'll have to disable Box2D's built-in gravity and instead explicitly apply gravitational forces via world.ApplyForce. This will also require executing multiple physics steps per graphics step, since Box2D assumes forces are constant throughout an iteration, but gravity will be a function of ball position in my implementation.

If there is any raster art for the game at all I'll draw it in Photoshop, but I expect almost everything to be vector based and procedural.

I intend to use Subversion for revision control. I prefer Mercurial for new projects, but codeheart itself is in Subversion and it will be easier for me to keep the game in a private fork of the codeheart repository in case I need to update codeheart itself.

Related Games

Desert Golfing and Spacewar were already mentioned above.
  • Gravitee (visualizes the ball path, mostly about hopping between planets instead of playing on them. goal is a hoop to shoot through)
  • Orbital (launch multiple projectiles to hit specific targets)
  • Galaxy Golf (space themed mini-golf with regular gravity and interesting environment interactions)
  • Fuzzy's World of Miniature Space Golf (3D minigolf with a space theme)
  • Space Mini Golf (3D minigolf on the equivalent of MarioKart's rainbow road)
  • Galactic Gravity Golf (Like Gravitee, but with bank shots off walls sometimes. The "hole" is a black hole. UI allows adjusting previous shot and there are bonus coins to pick up; all about making hole in one. Allows flying the ball while in motion.)

Schedule 

I plan to work four hours during the work day on Friday for the jam, and then another four hours late at night. Saturday I'll mostly work in the late evening, with a few short sessions during the day, and Sunday I will put in a block of time in the middle of the day as needed. I'm estimating 12 hours of total development time. My milestones are:

Before jam: prep Box2D.js and learn to use it, collect reference art, revise this plan in a few passes.

Friday 11am: complete one-screen of a Desert Golfing clone. Tee, hole, procedural ground, ball physics, UI (mouse/touchscreen only)
Friday 3pm: Golf on the surface of a planet. Add UI code for auto-adjusting the view transformation to keep the golfing position always with the ground down
Friday 5pm: Multiple planets

Saturday 1pm: Sufficiently tuned for first play test
Saturday 6pm: Reasonable graphics. Planets of different colors with simple gradients, some simple star parallax in the background when the view moves

That leaves late Saturday night and Sunday for playtesting and mechanical polish.

2 comments:

  1. Will you try to keep the aesthetic appeal of desert golf? The endless wandering, the incredibly slow changing background color?
    I just imagined you using real life distances in space golf and each turn taking like 20 - 30 years.

    ReplyDelete
  2. The graphics are pretty minimalist, but not quite as desolate as Desert Golfing. I'm basically using golf as an excuse for a game that is really about exploration of a procedurally defined universe. Like, "No Man's Golf" :)

    ReplyDelete