A game in progress.

#Game Design #Programming

So I’ve been working on a mobile location-based game for about ¾ of a year now, and thought I should share more details.

When starting out on the project, I wanted to try creating multiplayer functionality. Mainly because it's really fun playing with friends, but also because it's a tough nut to crack. But I also didn't want to jump into the deep end of 60fps/physics/vfx network transport — after checking out the Unity and Unreal solutions (both built-in and third party), it just seemed like too much to tackle with the limited time I had.

But I love turn-based multiplayer games (see: Pocket Tanks, I love that stuff), and it seemed like an easier place to start.

Next, I wanted to do something with mobile devices — specifically, something physical. I wanted to see if I could make a game that requires movement.

So the gameplay I ended on is this:

Players run around the real world, and use their devices to place virtual markers that create virtual territory. The team with the most owned territory at the end of the time limit wins.

This comes with some interesting challenges:

1. Keeping track of players. Okay, so let's learn the iOS Core Location service, and possibly the Google equivalent. I did look into MapBox, and it looks great, but I couldn’t get it to work with any tech stack (see below).
2. Keeping track of state, with multiplayer replication. For this, I thought I would give Firebase Realtime Database a go. I've never worked with JSON-style or NoSQL databases before, so there's a thing. But I was intrigued by the potential for pseudo-realtime networking.
3. I didn't want to force players to define territory with outlines — that seemed like too much busywork. So I went with a single marker placement at a location. That meant defining the territory programmatically. My instinct was to use Voronoi Diagramming, which I think turned out pretty well.
4. Lastly, I wanted the territory to be dynamic throughout the game — so that markers would “expire”, and give up their territory. This also meant that the score couldn't be based only upon territory, but rather a territory per timescale value (currently per second).

With all of those expectations, I researched a lot on potential frameworks to use. Cross-platform is the ultimate goal, but not the primary restriction. Although I’m very familiar with Unity, I wanted something that didn’t explicitly tie to that ecosystem — it felt unwieldy, unnecessary, and just heavy. I didn’t need all of that.

So I tried a bunch of mobile frameworks.

• Flutter. I was really hoping this one would work, and I tried it a lot. Ultimately I couldn’t get those external packages to play nicely. And the text-node-based UI design was driving me looooooooopy.
• Ionic. Yeah, I can see it for business apps. Didn’t sing to me.
• Xamarin. See Ionic, but more.
• Corona/Solar2d. I have experience in making games with Corona (now Solar2d), and really like it. But getting the hardware/database stuff working didn’t happen quickly.
• RubyMotion. In a surprise find, I tried RubyMotion — a framework that lets you use Ruby to create iOS and Android apps. I was initially sceptical, because the codebase looked “old”, and you have to pay to use it. But my fears were unfounded, as I was able to get the basic operation going very, very quickly. The Slack server is small, but quite supportive, and the main developer is constantly bringing it up to date (when not working on the also-impressive DragonRuby).

Slowly RubyMotion proved its mettle, allowing me to bring in CocoaPods for the external stuff, and visual UI with XCode (XCode isn’t even needed, which is a huge bonus — but it’s nice to use just for the UI).

After setting up the initial UI scaffold, my main goal was to get locations, markers, and voronoi working.

I had to create the Vonoroi code in Ruby, as none of the available libraries ticked every box. But that’s okay, I understand more about the sweep line algorithm now. Getting it all together was very satisfying.

Next came the real-time database. Connecting was easy — the long process was figuring out the best way to treat the data, and how to replicate it to clients. Again, I wasn’t used to NoSQL, so the idea of just duplicating data all over the place made my skin scrawl (I like normalization, okay?), but eventually I got a good schema. Client replication was hard too, mainly because Firebase docs doesn’t do a good job explaining when and why replication happens — so I’m probably totally over-forcing updates. But the data is tiny, so I’m not worried about it.

The hidden bugbear — the thing I really wasn’t expecting — was how hard matchmaking would be. It’s probably worth an entirely different post, but ultimately I wanted matchmaking to happen behind the scenes, based upon location. There were a lot of edge cases and other interesting factors. And I had to make bots, because I can’t just get humans at all hours.

In short, matchmaking was a total beast.

But I got some successful playtests, with timers, scores, and ultimately other real humans.

Right now the project is a bit stalled, as in the move to the US my priorities are elsewhere. But I also no longer have a Mac to work on. Anyone have a spare MacBook Pro they want to donate?

On using a classic game as a basis for further development.

#Board Games #Instruction #Game Design

In my game development courses, I will often ask my students to take an existing game – blackjack, hopscotch, Jenga – and try to make a new game from those basic rules. It's a common exercise, and quite a good one for beginning designers, as you have a clear and well-defined game rules.

At the start of this semester I asked my student to riff off one of the oldest games ever, Rock Paper Scissors. There are quite a lot of variants, all known as “ken” games, from the Japanese word for “fist”.

This year, students looted my supply of prototyping stuff – a vault of cards, tiles, dice, tokens, etc. that I use to throw a game together for testing.

One team grabbed the Personal Oracle deck, a cool deck of loaded symbols primarily used for divination. Their game revolved around memory and card-swapping.

One team gravitated towards the hex tiles. After making a suggestion of corrolating the six sides with the three throw choices, they were off.

Here are some photos from the initial playtest of the game they developed:

Vive la france!

#Game Design #Games

This post on Snit's Revenge made me ponder about asymmetry in games – both in terms of design and context. For design, I thought it might be cool to create an ongoing list of ways in which a game may be asymmteric:

• player goal
• player movement
• player behaviour
• board layout
• etc etc
  

It's another list in my array of Field Notes books. I'll type it up when it's more robust. I was also reminded of the French Military Game. Which is a terrible title for a game, but there we are. It was a game popular with the French Military in the 19th century, more recently written about my the amazing Martin Gardner in Martin Gardner's Sixth Book of Mathematical Games from Scientific American.

The FMG is asymmetric with number of player pieces, player movement, and player goal[^1]: The three white pieces can move sideways, forward, or diagonally forward; the single black piece can move in any direction. The white pieces want to trap the black so that it cannot move, and the black piece wants to get past the white (which cannot move backward).

The FMG sits in the set of “Hunt Games”, where one player is hunting the other. By their nature, hunt games are asymmetric in at least one way. Other traditional hunt games include:

• Bagh Chal and Bagh Guti, from Nepal
• De Cercar La Liebre, from Spain
  
• Fox & Geese, from Britain
  

I'm still on the fence as to whether I would consider hnefatafl a hunt game. But that's just semantics – it's still asymmetric in player movement and number of player pieces. But hnefatafl deserves a whole post unto itself really.

[^1] not so sure about asymmetric goal in this game. It's more of a mirrored goal.

When sounds make the game.

#Link #Audio #Game Design

For a group show opening in December I am creating an audio experiential game world. The idea is that there are no visuals for the game — the player needs to navigate a world using only 3d positional audio. I will attempt to create a narrative from the movement and interaction of the player in this world.

In researching my concept, I came across this article on Audio as Gameplay by Aaron Oldenburg. Good stuff.

Note: this project can be seen here.

Audio landscape narrative gallery installation

#Audio #Game Design #Artwork

Installation • The Lodge Gallery, Portland November 2013.

Aumission is an audio soundscape , traversed using a customized Xbox controller.

Interleaving historical 8-bit audio and realistic quadraphonic sound, the participant is invited to explore the narrative in an nonvisual game.