Experilous

Tl;dr:
If numerical determinism is important for your application, never use a PRNG to generate more than one function parameter at a time.

I just got bit by C++’s unfortunate underspecificity regarding the order of evaluation of function parameters. I was working on adapting a procedural generation algorithm (based loosely on my planet generator code) from floating point numbers to fixed point numbers. The goal was to ensure that regardless of compiler, OS, or CPU architecture, the same code would generate the same planet, if starting from the same pseudo-random number seed and using the same generation parameters. Despite IEEE 754 being an extensively designed and very mature standard, in practice there are more than enough other variables at play to make floating point unreliable from machine to machine if exact replication is required. Just search for “floating point determinism” for plenty of examples.

Quite obnoxiously, but not unexpectedly, the results with the new fixed point code were substantially different from the floating point results. Not completely different; I could tell that some steps were behaving nearly identically, which proved that most of my fixed point code was functioning correctly. Tracking down the source of the discrepancy was harder. Was my implementation of a cross product backwards, leading to blatantly wrong vectors? Or was it something more subtle, such as a chaotic variable tipping just enough across its threshold to lead to radically different behavior? (more…)

Okay, after a few nights of good sleep and days not thinking about coding, it’s time for a reflection on my efforts during this past weekend’s Ludum Dare. (For reference, my entry can be viewed here and played here).

As was evident in my earlier posts, I didn’t really have a clear idea of where I was going, design-wise. Even on the last day, I wasn’t quite sure where I would end up, though it was of course much clearer how little time I had left to add any additional mechanics. But I didn’t let that lack of direction prevent me from continuing onward anyway, so that was a success of sorts. All too often, if I don’t know where I’m going, I fail to go anywhere at all. (more…)

Three players running around the diamond for a home run.

A home run for 3 points!

Our Ludum Dare 31 entry is finally complete! For some loose definition of complete, anyway. It’s submitted and can poked and prodded, at the very least. Changes since the prior version were minor; I handled the game over state, added a little bit of variation to the pitch to visually indicate if it’s likely to be a ball or strike, included more animations for the runners to take them from 2nd to 3rd to home, and did some minor bug fixing. Haven’t yet discovered what rockets the ball into the sky every once in a while after hitting the back wall. Oh well, someone might find it amusing.

Play the final entry, and go rate it on my Ludum Dare entry page.

And now it is finally time to decompress!

Two more iterations today. Number seven added runners that actually run one base at a time, as well as foul balls and textual announcements of pertinent events. Number eight added regions to the play field that determine the type of play depending upon where the ball comes to rest.

I also have an amazing bug where the ball occasionally flies off into the stratosphere whenever it bounces off of the back wall, or otherwise magically teleports to a different spot on the field. I don’t think my code or my math could survive another day of game jamming. Good thing it’s over soon!

For my sixth iteration, I have added a short wind up animation for the invisible pitcher, to give the player a small heads up that the pitch is happening. I’ve also thrown in some occasionally buggy code to cause the ball to actually bounce off of the back wall, which happens to be infinitely high, despite appearances to the contrary. Sorry, no home runs.

Something is starting to come together, although that “something” is yet to be a game exactly. My fifth published iteration now has score keeping, bouncing balls, a pitching/swinging mechanic, and a wall at the end of the outfield (which magically doesn’t stop balls). It works again on mobile too, though the touch event lag that most browsers introduce causes a serious amount of annoyance when batting.

Two base runners running between home, first and second, with a ball in the air.

Base runner sprites from Jeremy.

Beginning to get some mechanics in, though I don’t like the feel of them yet. The third prototype introduced new base runner sprites from Jeremy, a “Bat” button, and a non-functional ability to specify which area of the field you wish to target for batting. The fourth prototype made the batting target functional, and added some priority options for batting: chance to hit the ball at all, the power of the hit, and the precision with which it is hit. In the background, strikes, balls, outs, and innings are being tracked, but not the score. And I seem to have broken the mobile touch interface; it will come back in a future version. (more…)

Baseball diamond with multiple blue ellipses running around the bases, and multiple balls in the air.

Out of control elliptical base runners. Who needs rules?

Last night’s brainstorm resulted in very little that was inspiring. “Entire game on one screen” wasn’t exactly a creatively compelling theme. But Jeremy and I chose to go with a baseball-esque theme, with no scrolling of the ball field or extra panels for information. I was hoping I’d be able to come up with some abstraction and modification of baseball mechanics that still retained a core element of fun, but my design efforts didn’t result in many promising thoughts. Before I went to bed, however, I insisted I throw together a tech demo of the ball/shadow graphics that Jeremy recommended. You can view that in my first prototype (just click, touch, or press spacebar to launch baseballs with random trajectories).

In order to give Jeremy something solid to work with for creating some sprites for the players, I added a diamond and some blue elliptical base runners, and subtly improved the size and shadowing of the balls. You can see that in the second prototype.

Now it’s time to actually add some legitimate game mechanics, while Jeremy works on sprites.

U+2603:  Snowman Symbol

U+2603: The theme for LD31?

Only three hours remaining until the theme for Ludum Dare 31 is announced. I’m gonna have a go at it again, preferably with far more success than Ludum Dare 30. I’ve been in a rather good mental state this past week, and am well rested, so I’m optimistic. And the possibility that the Unicode Snowman will be the chosen theme doesn’t scare me. Not that I have any idea for what I’d make for that theme or any other. I’m fully in the just-wing-it mode of thinking for this one. We’ll see how that goes.

I’m assisted this time by Jeremy Breau of Antithesis Design. The media assets he’ll be creating will no doubt be far better than any weak vector art I would throw together, and having a partner with whom to share the design efforts is always rad.

Meanwhile, the very encouraging interest from Hacker News and reddit this past week, along with a very insightful business suggestion from a friend, has me reconsidering my plans regarding my planet generator. (more…)

I tweeted about a month ago about an “interactive storyboard” that I was working on for my city builder design. But I only made it halfway through my intended development before I got distracted with my planet generation and turn based strategy shenanigans. The result was that I never got it to the point where I was planning to blog about it. Since it is apparently delayed indefinitely, maybe I should at least show what I do have available.

You can try it out yourself here, though be warned that the UI and overall user experience is far from perfect. This was in part an experiment to get a feel for how the interface would function (or not) after all! (more…)

For the past two and a half weeks, I’ve been working on a procedural planet generator.  This weekend I finally polished it up enough to talk myself into putting it online.  You can check it out here.  (It’s heavy on the JavaScript, so I recommend Chrome.  Firefox and IE are slower, but manage.  I haven’t tried any other browser yet.  Also, I’ve never yet delved into supporting touch controls, so it’s pretty much keyboard only.  Sorry mobile users.) (The above link is for version 2, uploaded April 7th, 2015; version 1 is still accessible here.)

Update, October 2015: Worldbuilder Version 0.2.2 has been released, inspired by this prototype. Includes flat map projections and per pixel detail!

A lot of different steps go into generating the planet, utilizing a variety of algorithms and techniques.  They’re not perfect, and some of them are in fact quite finicky, requiring a lot of cautious tweaking of parameters and behaviors.  Some of them are bad enough to make me cringe.  But they work.  At least well enough to make some pretty pictures, and some planets with enough variety that they might be a half decent foundation for some strategy mechanics.  So in case anyone might be able to glean some useful ideas from my work, allow me to delve into some of the details (and include tons of colorful pictures along the way). (more…)

Ludum Dare 30 Retrospective

Physical prototype with Risk cubes and LEGO axles.

Physical prototype with Risk cubes and LEGO axles.

Not that there’s much on which to retrospect, since I threw in the towel less than a day into the game jam.  My brain simply was unable to appropriately concentrate on the task at hand, no matter how much I tried.  Eventually I decided to simply cut my mental losses and not burn an entire weekend on a stressful activity that was clearly going nowhere.

Part of the problem was certainly that I had some personal stuff on my mind.  While that overall fact obviously impacted my efficacy with the jam, the details are irrelevant.  But there were some aspects of my mental processes that are very relevant to a retrospective.  First, and of course most notably, I’ll cover what went poorly, followed by those few elements that actually went well.  Such as the physical prototyping you see here on the right. (more…)

It’s time for the Ludum Dare game jam, once again.  This trimester I’ll be doing the 3-day jam rather than the 2-day competition, since I might have some outside assistance, and my schedule doesn’t really line up well with a Sunday evening deadline.

As before I’ll probably use the HTML5/JavaScript/CreateJS/jQuery combo, and take advantage of any of the code from my prior two jams or the other prototypes available here on my site.

Although I’ll note that I’m tempted by the recent release of the Unity 4.6 public beta, and the new GUI contained within.  Trouble is, I’m not very proficient with Unity, so it would definitely slow me down during a jam.  For some reason, every time I use Unity, I very quickly find myself confused by urges to fight the engine, rather than work with it.  So if I go the Unity route, the entire purpose of the jam will simply be to have any game completed to a playable state, whether innovative, fun, or otherwise.

If I focus on game mechanics, however, innovation is generally my objective.  This time around, I’m toying with a game style inspired by collectible card games like Magic:  The Gathering or Hearthstone.  Note the word “inspired”, as I don’t intend to literally create a card game.  But there are a lot of fascinating elements that I think can carry over into other game styles, and I’ve recently been working on doing that with some of my larger projects.  I don’t have anything to show for those larger projects yet, though, so this might push me to test the waters with some concrete functionality.  Always a valuable benefit of doing a game jam.

(crossposted to ludumdare.com)

A few weeks ago I introduced you to what I felt was an impressive little data structure that can provide constant time complexity for the standard operations, stores data contiguously, and provides stable handles that remain valid across all operations other than removing the referenced items themselves.  Today I want to extend the basic data structure with some additional functionality which will be focused on iterating over the contiguous items in order.  While iterating, we may wish to modify the collection as we go (such as conditionally removing some items).  We may also wish to rearrange the items so that a simple linear traversal will also happen to hit the items in a particular order (such as sorting 3D objects from front to back to take advantage of a depth buffer and reduce fill-rate). (more…)

I recently had a spontaneous idea for a card game while reading a game design book (Game Design Workshop:  A Playcentric Approach to Creating Innovative Games, very good, highly recommended).  After some playtesting, experimentation, and tweaking of the rules, I decided to write up the rules.  Regrettably, most of the rule tweaks seemed to fail at improving the gameplay experience, so what I ended up with feels only mildly intriguing, not excellent.  But perhaps someone else might be inspired and find a clever way to improve it. (more…)

I recently ran across a couple of blog articles describing a data structure that provides a set of properties that I often am seeking:

  1. Contiguous data storage, good for linear iteration and maximizing cache utilization
  2. Constant-time insertion, deletion, and relocation of elements
  3. Stable external references to elements regardless of internal relocation
  4. Constant-time look-up from external references without hashing

(The two articles were from the makers of the Molecule Engine and the BitSquid engine, respectively.)

Fascinated by data structures and algorithms in general, and lured by the appeal of these properties, I set out to study the concept and implement my own version.  It’s quite simple to implement in a basic form to achieve the above four properties, and can easily be extended to acquire some additional behaviors at the cost of additional memory or extra operations.  In this first article, I’ll walk through the basic concept, as well as a simple implementation in JavaScript.  Later articles will explore some of the possible extensions. (more…)

Jesse Schell recently requested brief videos from anyone who likes his book The Art of Game Design.  As is obvious from other content on my site, I’m a big fan of the book, so I took the time to begin learning a new skill and recorded a two minute video.  It summarizes two key features of the book that have helped me overcome periods of demotivation:  guidance on where a designer’s focus should be (helping me to get past a misplaced focus), and fresh perspectives to take advantage of the mental space freed up by stepping away from a ill-chosen focus.  Without completely repeating the short video in text, here it is (or view it on YouTube): (more…)

What a confusing tangled mess!

Ludum Dare is over, and my entry, Symptomatic, can be viewed here.  (If you want to judge the entry on the Ludum Dare site, you can find it here.)  The non-competition jammers are probably wrapping up their 72-hour game jam entries as I type, but having done the 48-hour competition, I’ve had the luxury of relaxing for a full 24 hour already.  Time to look back and reflect. (more…)

hex grid cells with channels and a path

Drawing a path.

More than halfway through the competition, and I can only now finally interact with the program.  I guess I’ve gotten to the point where I’ve made the toy.  And I’ll admit, it’s kinda fund just doodling around with the path.  A little confusing at times, though; it isn’t the most intuitive interface.  Ah well.

Now to add in the disease and symptoms, in order to give the player some information to go off of, in order to guess at the actual channel arrangements.

So tangled!

I now have a notion of a game world, consisting of both the actual state of cells and their channel arrangements, as well as the player’s guessed arrangements.  (Not that there’s yet any interface to let the player guess.)  Here’s the latest screenshot; click for a full-size version.

To be honest, I’m surprised that there aren’t too many small cycles.  Pure randomness already does a decent job of generating long meandering paths.  I was worried that I might need to massage the random data some to get it into a more useful form, but I might be able to work with this as is.