I thought about that design again today and for whatever reason a much better system came to mind.  Here’s the spec:

Leading byte:
  01111111 // 0 - 127
  1000xxxx // 1 byte follows - 12 bits total
  1001xxxx // 2 bytes follow - 20 bits total
  1010xxxx // 3 bytes follow - 28 bits total
  10110000 // 4 bytes follow - 32 bits total
  11xxxxxx // a negative value -64..-1, e.g:
  11000000 // -64
  11111111 // -1

Rubber Ducky Debugging

I took a cue from the Rubber Ducky Debugging technique.  The trick behind RDD is to explain your programming problems to an inanimate object (say, a rubber ducky).  While it can be hard spot the logic error when your thoughts are just swirling around in your head, once you’ve laid out the problem in black and white – as if explaining it to someone – you’ll usually spot the solution yourself.  It totally works!  I’ve used it many a time – though often it’s been “Instant Messenger To An Away Friend Debugging”, where I’ll type out my problem to a friend who’s AFK and then I’ll figure out the problem before they get a chance to say anything back.

Rambling

So here’s the trick: for effective solo brainstorming just open up a text editor or word processor and have a conversation with yourself.  Start rambling on about your game.  Type out questions and blurt out ideas and responses.  Fragments are fine, don’t worry too much about syntax and clarity.  Type one idea after another in a loose, informal outline and don’t hesitate to skip around as the ideas come.  The most important thing is to not worry about making a polished document because as soon as you start doing that you start killing the creative fount by suppressing the thoughts as they come in order to organize and format what you have so far.

For myself I have a Git repository called “design” and in that I have a bunch of TXT files.  The main one is “ideas.txt” and I’ll just go through jotting down whatever rough concepts I have.  As soon as a particular game idea starts taking on a life of its own – with me writing down more and more bullet points – I’ll spin it off as a new text file.  Currently I have a fair number of these text files for semi-fleshed out games and I’ll brainstorm on all of them at once, at first just focusing on whichever one sounds the most interesting at the moment and then I’ll invariably jump around to my different documents and add an idea here and an idea there.

The advantage of using actual text files instead of notebooks or paper napkins is that the text files are much easier to keep organized.  My notebook brainstorming might revisit a particular game on pages 3, 8, 10, and 19, whereas on my computer I’ll just type in the notes into the appropriate document.  Transferring ideas from napkins and notebook to your design files later would certainly work as well.

Here’s an example of how one of my design files might evolve.  I’ll sometimes use asterisks (***) to mark an idea I’m really keen on in the middle of my session.  Note: I was going to just do an example on the fly – but it turned into a really cool idea I want to keep close to the vest for now!  I’m just going to retrofit our existing game “Fish Hunter” to the rambling design file as if we’d used that system instead of brainstorming amongst ourselves.

REDNECK FISHING
Need quick, simple game for Palm OS
Hunting games (shooting) are really popular with casual players
Fishing games are really popular
Make a shooting+fishing game
Redneck in boat, shooting fish and dropping dynamite in the water
Drinks beer?
Have to shoot a target number of fish before the time runs out
- then go to next level

Control scheme?
- Could just tap on fish to shoot at them
- BUT don’t want to make it too easy
- Maybe virtual joystick
- OR Drag finger on screen to change aim to that spot.  Tap to shoot.

Powerups?
- Dynamite, rapid-fire, three-way shot
- How to get?
- Maybe power-ups in the water that you shoot

There’s no danger… time just runs out.
Water danger = sharks
***Sharks come straight for you, game over when they get to you.
No levels – just get as high a score as you can.
Lives?  Nah…

Palm doesn’t support dragging [or something like this, I forget exactly]
Maybe just tap to shoot fish overall
Maybe fish are a little faster, bullets are a little slower than I was thinking

What determines score?
- Small fish vs big fish
- Hits in a row
*** power-up idea: like Modern Warfare 2 – the longer your killstreak the better a powerup you get.  When your killstreak is broken you still have whatever powerup you were able to get to
…

After the iPhone’s touch screen came out all kinds of interesting control schemes have emerged.  After implementing my fair share of overcomplicated and frustrating schemes, I’d like to give my thoughts on the best ways (and worst) ways to implement touch controls.

Problematic Touch Controls

Never say never, of course, but we’ve had user frustration issues with all of the following:

Heavy Dragging
Dragging your finger constantly around the glass screen for minutes at a time (Air Hockey, Deathride) becomes somewhat uncomfortable after a while.  You can’t just swap out mouse movement control with fingertip control!

Virtual Joystick
Even though they’re heavily used in mobile games, virtual joysticks are a poor substitute for the real thing.  It’s easy for your finger to slip off-center or run off the edge of the screen.  Using the sides of the screen (which are easier to keep track of) can work for a slower-paced game, but the distance from edge to edge is a little unwieldy for arcade-style games.

Relative Tapping
Relative taps (tap to the right of the hero to slide or turn right, etc.) make a lot of sense in theory, but as we’ve discovered with Armageddon Rider and Zombie Conga, this idea of “it matters where you tap but not what you tap on” can be a little too abstract (for casual players, at least).

Multi-Finger Taps and Swipes
You can explain it all you want in the instructions, but if you have to do a two-fingered tap to bring up the menu or some such then you’ll just frustrate the majority of players who either didn’t read the instructions or have forgotten those special cases by now.

Elegant Touch Controls

Tap
There’s nothing easier or more transparent to the user than tapping on a big, clearly visible button or tile.  Just make sure the buttons don’t blend in to the background too much – and if you ever catch yourself requiring the user to tap a tile and then another tile next to it, consider a swipe instead.

Light Dragging
There’s certainly a place for dragging as long as the player’s fingertip is given a break at regular intervals.  The biggest danger then is in players not realizing they can drag something around!

Swipe
Swiping is one of the most elegant, most underutilized tools that touch game designers have at their disposal.  When it came to replacing the keyboard and D-Pad with a touch screen, most of us thought a little too literally and made virtual buttons.  But what is the purpose of keys in most PC games?  It’s not to type in W, A, S, and D, it’s to move the hero up, left, down, and right.  For discrete movements, nothing’s easier on a touch screen – just swipe up to go up, etc.  The swipes can be anywhere on screen and they still work just like a D-Pad!  As a bonus, you can then have a world with much smaller tiles than you could have if you needed to be able to tap on a particular tile to walk to it.

I’ve realized what the missing piece of the puzzle is for us (or at least for me) to be a successful independent and autonomous game developer.  In short it’s about establishing personal deadlines and working on small, manageable projects.  But let me take you through my reasoning.

I’ve been thinking about time management, productivity, and working for the Man versus working for ourselves.  Consider Parkinson’s Law as described in “The 4 Hour Work Week”:

If you’re an employee, spending time on nonsense is, to some extent, not your fault. There is often no incentive to use time well unless you are paid on commission. The world has agreed to shuffle papers between 9:00 A.M. and 5:00 P.M., and since you’re trapped in the office for that period of servitude, you are compelled to create activities to fill that time. Time is wasted because there is so much time available. It’s understandable. Now that you have the new goal of negotiating a remote work arrangement instead of just collecting a paycheck, it’s time to revisit the status quo and become effective. The best employees have the most leverage. For the entrepreneur, the wasteful use of time is a matter of bad habit and imitation. I am no exception. Most entrepreneurs were once employees and come from the 9–5 culture. Thus they adopt the same schedule, whether or not they function at 9:00 A.M. or need 8 hours to generate their target income. This schedule is a collective social agreement and a dinosaur legacy of the results-by-volume approach. How is it possible that all the people in the world need exactly 8 hours to accomplish their work? It isn’t. 9–5 is arbitrary. You don’t need 8 hours per day to become a legitimate millionaire—let alone have the means to live like one. Eight hours per week is often excessive, but I don’t expect all of you to believe me just yet. I know you probably feel as I did for a long time: There just aren’t enough hours in the day.

But let’s consider a few things we can probably agree on. Since we have 8 hours to fill, we fill 8 hours. If we had 15, we would fill 15. If we have an emergency and need to suddenly leave work in 2 hours but have pending deadlines, we miraculously complete those assignments in 2 hours. It is all related to a law that was introduced to me by Ed Zschau in the spring of 2000.
[...]
Parkinson’s Law dictates that a task will swell in (perceived) importance and complexity in relation to the time allotted for its completion. It is the magic of the imminent deadline. If I give you 24 hours to complete a project, the time pressure forces you to focus on execution, and you have no choice but to do only the bare essentials. If I give you a week to complete the same task, it’s six days of making a mountain out of a molehill. If I give you two months, God forbid, it becomes a mental monster. The end product of the shorter deadline is almost inevitably of equal or higher quality due to greater focus. This presents a very curious phenomenon. There are two synergistic approaches for increasing productivity that are inversions of each other: Limit tasks to the important to shorten work time (80/20). Shorten work time to limit tasks to the important (Parkinson’s Law). The best solution is to use both together: Identify the few critical tasks that contribute most to income and schedule them with very short and clear deadlines. If you haven’t identified the mission-critical tasks and set aggressive start and end times for their completion, the unimportant becomes the important. Even if you know what’s critical, without deadlines that create focus, the minor tasks forced upon you (or invented, in the case of the entrepreneur) will swell to consume time until another bit of minutiae jumps in to replace it, leaving you at the end of the day with nothing accomplished. How else could dropping off a package at UPS, setting a few appointments, and checking e-mail consume an entire 9–5 day? Don’t feel bad. I spent months jumping from one interruption to the next, feeling run by my business instead of the other way around.

The best and worst thing about working for the Man is having someone who tells you what to do.  It limits freedom but it creates focus.

I’ve finally admitted to myself that my self-directed efforts to date have involved a lot of time mismanagement.  Not as in “not doing work”, but as in following too many tangents, losing focus on what’s most important, and tackling projects that are really too large or too untested for our current means (i.e. income level).

Even though I would always caution my students against it, I have myself fallen into the trap of the Big Game Hunter.  The BGH fallacy lies in saying that “developing this game will be a lot of work… but it will be bigger or better or more exotic than the other stuff out there and it will be awesome and it will be worth it.”

That approach doesn’t work in general.  It’s not just a risk/reward thing – it’s not just about putting your eggs in one basket and gambling on one big game over a bunch of small games.  Primarily the issue is one of experience.

A modern version of The Tortoise and the Hare would go something like this:

The tortoise and hare make a bet as to who can build a small castle more quickly.  The hare starts out piling rocks on top of one another straight away while the tortoise builds a deck for his house, a shed, a guest house, and then a brick office building.  After a few months the tortoise starts building his castle while the hare’s crooked, uneven walls start falling down due to a lack of reinforcement, poor mortar mix, and spring rains.  After a year the tortoise’s castle is finished and sound while the hare’s jury-rigged efforts are only half-way done and are once again on the edge of disaster.

The point being, of course, that by working on small games first you’ll naturally work up to big games and have a lot of small games to show for it besides!

Outliers: The Story of Success estimates that it takes the average person 10,000 hours to become an expert at their work.  It notes how, long before they were famous, the Beatles were playing all-night eight-hour gigs for weeks at a time.  In short they put in their time and they earned their chops.  I’ve definitely put in my 10,000 hours… on programming.  But not on game design and development.  That’s what I’m going to work on with a vengeance, starting now.

To help gain that experience, that focus, that pressure of the deadline to clarify what’s important and what’s doable, and to become the Big Game Hunter I want to be, I’m going to start releasing or submitting a new or upgraded game every Friday, with next Friday being the first release.

I’m going to start with updating our four “Jirbo games”.  Silo, Fish Hunter, Mr. Gibs, and Guys Night Out were originally published by Jirbo on iOS but we’ve acquired them back again.  I’ve needed to do something about them for a while because they’ve all got the fricken’ keyboard bug where the virtual keyboard hasn’t shown up since iOS ~4.1 or so (the buck stopped here on my desk but then rolled under it and was in limbo for a while).  So next Friday we’ll be releasing an upgraded version of Fish Hunter for Android and submitting it for iOS and Windows Phone 7.

After those four games it’ll be a mix of upgrades and new game releases (probably saving the upgrades for times when art or something isn’t ready for whatever new game I’m working on).  But no more than one game per week!  While I want a deadline, I also want to leave some time for R&D and some time to chip away on larger projects that can’t be ready in a week (including Plasmacore) – or some time to work on ongoing contract work if need be.  Unless there’s a severe crunch, I’m going to keep doing my weekly release even when working on other contract jobs.

One-week games might have to turn into two-week games (or longer) eventually – but then again maybe not!  I could see the idea turning into Agile Development at its best, with larger games developed iteratively as a series of actual weekly releases.

I’m pumped!

In retrospect I have to say that forums like I was trying to switch to are 1) niche and 2) better for discussions than articles.  I’ve been writing blogs about other things using Facebook Notes, but blogging has never been a strong point for Facebook – in particular, it’s hard to search through old notes and people who aren’t on Facebook can’t follow your blog.

There’s one big change though – I’m gonna change this from being purely a technical blog to being a personal blog as well (travel, etc.).  I’ll use categories to keep things straight!

Here’s the new SMF-based Plasmaworks Community that I’ll be moving my codeblog thoughts to:

http://www.plasmaworks.com/forums/index.php

Sign yourself up and join me in discussions of Slag and Plasmacore!

Automatic Properties

First we have automatic properties that can be used when you have a single init method that stores each of its arguments into a property you’ve just defined.  Here’s an example of old code:

  class Person
    PROPERTIES
      name : String
      age : Int32

    METHODS
      method init( name, age ):
  endClass

Here’s the same code with automatic properties:

  class Person( String name, Int32 age )
  endClass

or even just:

  class Person( String name, Int32 age );

You can add additional properties and methods as you like.

In-Line Classes

Slag now supports in-line classes that work pretty much just like Java’s anonymous classes.  In addition, “METHODS” is now the default member category (so you can omit it if you start a class definition with a method), which makes in-line method definitions easier.  An example:

  class Operator
    method init:
    method apply( Real64 lhs, Real64 rhs ).Real64: abstract
  endClass
  ...
  method test( Real64 left, Operator op, Real64 right ):
    println( op.apply(left,right) )
  ...
  local Operator plus = Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs + rhs
      endWith

  local Operator minus = Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs - rhs
      endWith

  test( 5, plus, 3 )  # prints: 8
  test( 5, minus, 3 ) # prints: 2
  test( 5, Operator() with
        method apply( Real64 lhs, Real64 rhs ).Real64: return lhs * rhs
      endWith, 3 )  # prints: 15

Delegate Properties

Delegate properties allow you to specify that any unresolved method calls or property accesses be forwarded to one property in particular.  This is of particular use when you want to make one object that is essentially a proxy for another.  Example:

  class String
    PROPERTIES
      data : delegate Array<<Char>>
      hash_code : Int32
    ...
  endClass
  ...
  local String mesg = "Delegate *this*!"
  println( mesg.count )  # same as saying "mesg.data.count" - prints: 16

Only one property can be defined as a delegate.  Underneath the mechanism is very simple: at compile time failed member accesses are reevaluated with the delegate property.

caseNext

caseNext is handy in a which where you want to do something different every time based on a counter but you don’t really care what the case values are.  It just takes the previous case value (literal integer required), adds one to it, and makes that the new case.  For example, to load a different graphic (my plan is revealed!) each time a method is called:

  method load_next.Logical:
    load_index++
    which (load_index)
      caseNext: img_alpha = Image("alpha.png")
      caseNext: img_beta = Image("beta.png")
      caseNext: img_gamma = Image("gamma.png")
      caseNext: return false
    endWhich
    return true

If you started with “case 5:” then the first caseNext would be a shorthand for “case 6:”.  If you start with caseNext (as above) then it resolves to “case 1:”.

ITEM: We finished up Wyrmhunter for the iPhone a week ago and submitted it to Apple.  They haven’t gotten around to approving it yet, but we’re hopeful it’ll be soon.

ITEM: One of the last major things was a revamp of my dynamic texture sheet management system.  With its already limited drawing speed, the best bet for the iPhone is to place all images on one big texture (or several), queue up a bunch of triangles as different images are drawn, and then render everything at once.  Even better is if you don’t have to lay things out yourself but can have Plasmacore do it for you as you dynamically load and unload images.

My initial stab at the problem worked well in some cases and very poorly in others.  I started out with one big region of unused texture.  Then after the first allocation I split it into several chunks – one used, the others not.  I decided to make everything below the used area one chunk and then the remaining strip to the right another chunk.  If the original free chunk were:

CC
CC

Then after allocation “A” it would be:

AB
CC

The problem was that I could end up with a whole lot of “B” chunks of various sizes that didn’t quite fit together.  There would sometimes be plenty of room to put something but no chunk large enough to put it in.  It was fragmentation but worse: it wasn’t that there were used areas, it was that the free areas were adjacent but slightly disjoint.

I beat my head against the problem for about a week and tried 6 or 7 different approaches.  I felt that the key was being able to span multiple free regions, but if I used regions as they became available then they were too disjoint, and if I used some sort of grid layout then the search area was too big.

Then finally I finally hit on the solution: when I allocated a region I would split the entire layout area (including all regions used and unused) along both axes to make the allocated region the exact right size while keeping all cells lined up at all 4 edges.  Imagine an Excel spreadsheet where you’ve randomly adjusted the widths of some columns, the heights of some rows, and filled in random cells – that’s what my texture sheet would look like after some heavy cycles of allocation and freeing.  Incidentally two adjacent empty rows become merged again, as do two adjacent empty columns.

The allocation algorithm is this: scan all regions row by row.  If a region is unused and unmarked, see if it’s the corner of a space that will fit the image (ensure available width at region is <= necessary width, then ensure available height at each region is <= necessary height).  If the space is big enough, mark the all of the rows as in use that are wide enough all the way down, mark all of the columns that are high enough all the way to the right, add the space to a list of possibilities, and continue searching.

The neat thing is that by marking the possible matches as you go you really cut down on the number of candidate spots you have to check for – and each candidate region you find is a corner already.

For example, say we had allocation A already and free regions B, C, and D:

ABB
CDD

When we try to fit in a new allocation we’ll find spots B (corner of BB/DD) and C (corner of CDD) – and that’s it!  The other possible spots will already be marked as used as we find the top-left B and then C.  Between the two, we’ll pick the one that has the best {exact match, matching width, matching height, smallest area} crossed with the one that has {no gaps above, has gaps above}.

I hope you can see what I’m getting at here… I tried drawing some nicer graphics and so on but it was getting way too complicated for what it was worth.  Anyhow, the code is in and it’s working beautifully.

ITEM: I’ve now turned my attention to porting Plasmacore to Android – it’s pretty virgin territory and, like Google itself, I think Android could be a sleeping giant (albeit a slightly unwieldy, slightly dorky giant).  Over half of us at Plasmaworks now have G1 phones.  I still like my iPhone but I’ll admit there’s a lot of nice stuff about Android.

I got stuck for a while on an esoteric gcc pointer bug that cropped up in my Slag VM code.  It only happens when you have a certain optimization level turned on, which Android does by default.  Say I have a pointer to integer “ip” – I could retrieve an integer at that address and increment the pointer to the next value with:

int x = *(ip++);

This is equivalent to:

int** ip_ptr = &ip;
int x = *((*ip_ptr)++);

which is equivalent to:

int x = *((*(&ip))++);

What I really wanted to do was access a double instead of an int at that position and then advance “ip” to point past the double.  I had:

double n = *((*((double**)&ip))++);

I made it a macro and was using it in a place or two, but it was Bug City on Androids gcc configuration.  I went back to doing it a simpler way across a couple of steps.

ITEM: Finally let me tell you about an interesting discovery.  Some stray unicode characters were exposing a UTF-8 encoding/decoding bug in my compiler + VM.  What I didn’t realize is that Vim (and apparently other editors…?) load and save text files in UTF-8 already – I had assumed Vim would only operate on raw bytes.   UTF-8, by the by, is a scheme to translate text that would normally be 2 bytes per character into 1 byte per character for most symbols and then 2 or 3 bytes for the less common symbols.

There’s significant speed-up over my previous implementation, but you’ll still have to be careful.  The results:

• I altered the system to redraw at 30 fps instead of 60.  Even a blank screen can’t quite hold steady at 60 fps, so I’d rather aim for a steady 30 fps on iPhone.  No changes required to your Plasmacore programs.
• iPhone Plasmacore can draw about 9280/x square images in 1/30 second, where x is the size of a single dimension of the image (16 px or higher; smaller images are roughly the same).  [Edit: make that "9280 / sqrt(x)" where x is the number of pixels per image].  So around 580 16×16 pixel images, 290 32×32 images, or 145 64×64 images.
• Sound effects will probably slow it down a bit more; I need to do some further testing with that.

Looking good for modestly complex games!

Turns out it uses a graphics chip that renders different tile sections of the screen in parallel.  I couldn’t find any info on how big the tiles are offhand.

Here are my very informal results. [Clarification: I'm drawing tile/sprite images as a series of individual calls, each with its own 2D transform]

In 1/60th of a second, the iPhone can draw about:
24 textured polygons in the same spot, quarter-screen size or less.
OR 75 spaced-out polys (32×32 in this case)
OR 6 full-screen polys.

Notes:
- This is with a tight drawing-only loop.  Logic & sound adds a bit of overhead – not an excessive amount but then again every bit hurts.
- Things that didn’t significantly improve the speed: turning off texturing, turning off back-buffer clear, turning off alpha blending, using texture formats with fewer bytes per pixel.

In light of this I’m gonna tweak Plasmacore for iPhone so that it’s CYOB (Clear Your Own Backbuffer).  Not to save time clearing the backbuffer, but to allow you to get tricky (if you want) and only redraw altered portions of the screen.  The good news is that Plasmacore (as usual) will still update() at 60fps no matter how slow the draw() is going, so things might get a little rougher but they won’t get slower.

A final tip will be to avoid drawing font-based text – use prerendered words!