Skip to content
November 11, 2011 / Abe Pralle

A Neat Variable-Byte Encoding for Integers

Bard bytecode files are stored using variable-length integers – since most of the opcodes and string lengths, etc., are seven bits or less, it saves a lot of space overall.  In the past I used a system that was roughly UTF-8-ish in design but with one special modification: since negative one is a fairly common index and operand, I added one to my integer value before encoding it so that numbers -1..126 would be stored as a single byte (and a leading ‘1’ bit would indicate a multi-byte value).

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
The cool thing is that values −64..127 can be simply truncated to a byte with no other encoding processing required!  Not only that, but 15 bit patterns 10110001 through 10111111 are still available any other special markers you might need.
On an unrelated note – I got majorly busy on a big contract project just after I posted my “One Game a Week” plan, so that’s on hold.
Advertisements
September 13, 2011 / Abe Pralle

Effective Solo Brainstorming

I’ve recently become a lot better at solo brainstorming.  It’s always been fun to brainstorm with other people and bounce ideas off each other (“oh, it’d be cool if XYZ!”) but for a while there I hadn’t had the opportunity to do that and so I’d just kinda stopped brainstorming in any productive way.  It took me a while to realize that fact, but once I did I also realized I needed to figure out some way to become a more effective solo brainstormer

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

 

September 9, 2011 / Abe Pralle

Overview

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.

Read more…

September 9, 2011 / Abe Pralle

One Game Every Week

I’m currently in Edinburgh, Scotland, finishing up the last few days of my month-long working vacation in the United Kingdom.  I’ve really enjoyed the change of pace – it’s given me time to step back and think about everything – to reflect and to soul-search – and I feel like I’ve gained some new insights into my life and my career path.  Here at the end my little whirlwinds of speculative thought, sent out like robotic probes to explore new avenues of possible endeavor, are returning once more with their findings to converge into a coherent plan of action.

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!

September 9, 2011 / Abe Pralle

Moving Back!

Well my code blogging has been about zero lately, and I miss it, and I’m coming back.

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!

 

December 12, 2009 / Abe Pralle

Moving

After a brief flirtation with Drupal forums, I’ve since realized that Simple Machines Forum (SMF) is the one for me.

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!

July 26, 2009 / Abe Pralle

Automatic Properties, In-Line Classes, Delegate Properties, and caseNext

For the last couple of weeks I’ve been trying to come up with a good semi-automatic resource-loading framework for Plasmacore.  For each revision I added a new feature or two to Slag; I ended up not truly needing most of them but they’re good features nonetheless.  Here’s a quick overview of the new features – mostly by example.

Read more…