PiBot

I’ve had a raspberry pi gathering dust for a few years, but I had an inkling to do something cool with it. Over the holidays, I was gifted a PiStorms kit. PiStorms is a “shield” for the raspberry pi that fits directly onto a set of pins and interfaces with Lego Mindstorms motors and sensors.

Mindstorms is a pretty cool concept, but the entire set runs $350 and doesn’t actually allow full programmatic control over the resulting creation. It’s more of a drag and drop visual programming language.

I was able to download the OS image and flash it to my raspberry pi SD card. However, the PiStorms shield requires direct power, instead of utilizing the DC Power from the raspberry pi. This required a 6 AA battery pack and a set of brand new batteries.

Once the brain was operational, I still needed to build the vehicle. Mindstorms is supposedly compatible with all of the Lego Technic sets and parts, so I bought a basic four-wheeled mechanical car for 50 bucks from the lego store. I chose this model since it appeared to have a surplus of parts and lots of exposed anchor points for modification.

After following the directions for an evening, the car was assembled (aside from the cosmetic touches like stickers, etc). There were gears and axles propelling the rear wheel, and turning the front two. I was able to modify the frame to mount two medium mindstorms motors.

Lastly, I configured a mount for the entire PiStorms / raspberry pi assembly, which is relatively heavy. Once the OS boots up and the wireless connects, PiStorms has a php frontend website to display info allow control of the motors. You can connect to the site over wireless and remotely control the motors, driving and turning the car.

Some of the challenges:

Power

Once the Pi is wired up to batteries, it absolutely drains them. 6 AA batteries in series have about 9v. When PiStorms is turned on, you can see the voltage visibly decrease – 8.8…8.7…8.6. The motors and pi will cease to function once it drops to ~ 6.5V, so there’s very limited juice in the thing. I’m considering upgrading to use a rechargeable RC battery kit, which should extend the lifetime. But for remote robots, battery power is a real issue.

Mechanical Engineering

Perhaps one of the most fascinating challenges was engineering the mount points for the motors and the PiStorms brain. The axles themselves jutted from the frame at certain angles, forcing the orientation of the motors. The motors needed enough anchors in order by maintain torque and accessibility. The PiStorms assembly had to be elevated enough from the frame to ensure smooth turning. Problem solving the mechanical and structural issues was fascinating because it was so constrained. I only had limited parts and spatial real-estate, and the solution space was three dimensions. Choosing Lego as the base tech for building the robot was absolutely essential here. It would be much more difficult to experiment with models and configurations if the parts were permanently affixed metal.

Software Control

The robot as it stands now is hardly better than a cheap RC car. It’s able to drive forward and backward and turn the wheels remotely. The feedback loop is somewhat sluggish (manipulating a javascript-based joystick, sending http posts of the web), and the tuning of the motors is rough (often it will oversteer, over-torquing the steering column). So, there’s much room for improvement needed in the software.

One crux is that robotic motors and sensors are continuous, but the simplistic software API is discrete: The PiStorms unit works by sending a signal to the motors (run for 1 second, spin at 25 rpm, slow down to a stop in .1 seconds, etc). Driving requires iterative polling of the input (every x seconds, check the throttle, translate that to a motor command, send to the motor). Of course, motors in real cars don’t work this way – there’s a smooth continuous feedback between the throttle and the power given to the drive train. The question – how can this be represented in software?

I’d like to add in visual sensors and have the PiBot drive itself using some rudimentary computer vision algorithms. A similar issue arises – how often do you poll the sensor? 100 times a second? 500? Is it possible to act (ex: turn to avoid an obstacle) upon a single view, or is a continuous model of required? What kind of data structures and overall program architecture allow this orchestration between input sensors and output motors? These are some of the interesting questions that arise in robotics.

It’s been a fun project to complete the base model, but the truly fascinating road is the one that lies ahead.

A Year of Failed Prototypes

It’s been over six months since I released my last game, and almost that long since I’ve updated this blog.

I’ve been busy with non-gamedev stuff, but I’ve also been hacking away in my spare time. Unfortunately, most of these projects haven’t really gone anywhere. So I decided to go through the ones that had some promise, record a brief demo video, and upload the code to GitHub.

One of the hardest things for anyone who does creative work as a hobby is finding the balance between quality and getting stuff done. For most of these prototypes, I didn’t they were good enough to keep working on them. So I let them digitally rot in some deep folder of my hard drive. Thing is – there’s some good stuff buried in there. By going through and at least getting the projects into a shape to share the code, maybe someone else can take away something useful. Plus – it makes me feel slightly more productive.

And who knows – sharing these prototypes may kickstart enough motivation to turn them into full-fledged games.

Open Ocean Test


Source: https://github.com/tdonlan/OpenOceanTest

This is a prototype built in XNA to simulate an open world ocean. You swim a submarine through the ocean, underwater passages and lots of different fish. The terrain is generated using similar algorithms used to generate the Platform Hack tile maps. Some of the fish (flocking) move with similar algorithms to some of the germs in NanoDoc. I also put together some code for skeletal-based movement, and was going to have the larger fish (whales, sharks, big squids, seaweed) move that way instead of sprite sheet animation.

Challenges:

  • How the divide the sea from the air? I could never find a surface that looked good. Right now I’m just using a fat line tracing an oscillating sine curve. But if I ever used any sort of texturing on for the waves, it looked pretty bad.
  • How to handle all the fish + terrain? Running collision on all the fish would have been too slow. And I was just spawning various fish at different depths, not checking if they were in water or in rock first. One solution was to just have fish get repelled by the thickest rocks until they were in the ocean, but this led to strange bugs. The other issue was when to save the state of the world? If the world gets large enough, you can’t store it in memory effectively, so you have to come up with some sort of “chunking” algorithm for the world, which can be a lot of overhead to program.
  • How to make a game out of it? I thought the game would be mostly a sandbox with some loose missions and some upgrade trees for various tools on the subs: harpoon guns, engines, fishing rods, manipulator arm. Maybe even a flashlight. Missions could be something like: find this exotic fish in this section of the map. Catch a 500 lb marlin! Pull up the treasure from the sunken Pirate ship! Fun stuff, but a good bit of overhead to implement (questing system, mini-map, etc)

Fishing Test

Source: https://github.com/tdonlan/FishingTest

This prototype was partially inspired by a tweet for a fishing game jam, playing Ridiculous Fishing, and also fond memories of fishing minigames in videogames of yore (Ocarina of Time). I wanted to find a gameplay mechanic that mimicked the gentle tug and pull of real fishing – finding a balance between reeling in a fish and having the line break.

Anyway, the core mechanic is basic math, but the most technical part of the demo is the physics of the fishing line. This was actually done using Farseer Physics rope joints.

Challenges:

  • Getting the mechanics to feel just right. The fishing line feels a bit too floaty. And the fishing minigame feels a bit too random – like the player doesn’t have enough control reeling it in. Once both of those variables are adjusted, I think it could be a pretty fun prototype.

JSRPG

Source: https://github.com/tdonlan/JSRPG

This is a rough RPG built in JavaScript. It was actually created to try to build a RPG plugin for Twine games. I wanted to create a nice framework for building gamebooks (like Lone Wolf), where you could read through a choose-your-own-adventure style text game, but also handle battles and inventory. The pure RPG battle stuff ended up working ok in JavaScript, but the Twine integration was a nightmare (worthy of a separate post).

This demo is just the standalone JavaScript RPG functionality. Most everything is data-driven, so you can customize the game however you like, using JSON and CSV files.

Challenges:

  • Building complex logic with JavaScript: Things like – I want an item to grant an ability – which would be trivial in a strongly-typed compiled language, are pretty frustrating to build in JavaScript. Since there are no real enums, you have a ton of code to check for different strings, which can get cumbersome.
  • Display Loop: Right now the battle loop does the logic, then just recalculates all the HTML and updates the div. Ideally, there would be a way to separate it into some sort of MVC pattern, where the logic and data of the RPG was broken up a bit better from the display. Right now it’s a tightly coupled mess.
  • Everything in the browser: all the problems with doing stuff in the browser – how to save state (to disk or server), how to prevent cheating (you can’t). At the very least, I think I proved to myself that using Twine + JavaScript to make a Lone Wolf gamebook system isn’t really feasible (at least for someone with my level of skill + patience). I’m thinking Client + Server or iOS App would work much better.

SpaceTest Asteroid Clone

Source: https://github.com/tdonlan/SpaceGameTest

This is an iOS game built using Cocos2D. I had this idea to do an asteroids game where you could destroy asteroids and enemy ships, collect minerals, level up your ship, etc. Right now the prototype has the flying around part working pretty well – it feels a lot like the classic game of asteroids. It’s using touch screen controls to steer and shoot.

Challenges:

  • Does this game belong on iOS? I think my original intentions were larger than the limited screen real estate of an iPhone. The touch controls felt a little sluggish, especially the precision required for shooting and flying a spaceship through asteroid belts.
  • Parallax backgrounds in Cocos2d – there’s a built-in parallax functionality, but it’s not infinitely scrolling in 2 directions. I ended up hacking together a system to draw a background starfield and have it scroll as a function of the player’s movement. But it never felt very smooth. One of the biggest frustrations I’ve had with Cocos2D is finding a middle ground between using CCSprite to draw a static sprite object, and using low level OpenGL calls to draw lines and other primitives. Makes me miss XNA Spritebatch…
  • Realistically, I could grind on this game for a few months, find some decent art, and have something publishable on the App Store. Unfortunatly, my ADD kicked in and I was off to the races on something else. We’ll see if I pick it up again.

iOS, Cocos-2D and Heartline PostMortem

My game Heartline came out a few weeks ago.  Here’s a breakdown of how it was built, challenges, and what I learned.

Mac and iOS

I wanted to get into iOS development late last year, so I bought a Mac Mini around Christmas.  After learning the ropes of the new OS, the thing felt a little sluggish, so I dropped another 50 bucks and added some RAM.

XCode and Objective-C took a little while to get the hang of.  At first I was turned off by the incredibly verbose method calls.  Calling methods with block syntax felt ugly.  Memory management was strange as well (when to use init vs alloc?  what attributes for properties?)  But going through a few tutorials, and just spending time in the environment, I was able to manage.  I’m still not a pro at all the nuances of objective-C, but I can get done what needs to get done, and that’s the important thing.

Cocos2d

cocos2d

I decided to go with Cocos2D once I did some research and found that most dev tools for iOS App development came with a cost.  Unity, Corona, MonoTouch – all were pretty pricey to release an app.  Cocos2D was free, open source, and had a really good community.

Biggest differences from XNA:

No game loop! 

There’s probably some sort of game loop going on under the hood, but I wasn’t able to access it via Update Methods, like you do in XNA.  I think the tutorial method of managing objects in Cocos2D is to queue up actions and let the framework handle the movement/collision.  But that wasn’t fine-tuned enough for me.  And besides, I learned to make games with a game loop.  Thankfully, you can add a gameloop manually using a scheduler.

Everything is a game object

The other big challenge was that every Cocos2D object was a game object.  If you inherit from CCNode, you have a position, and can draw on the screen.  But stuff also has to be added (and removed) from scenes to be “in” the game world.

Scene system

One advantage of Cocos2D over XNA is the built-in screen system, using Scenes and Layers.  Scenes are added to a Director.  Layers contain all the game objects.  So you can easily have a Pause Menu pop up in a few lines of code, without having to worry about managing the state.  Even better, there’s a menu system, with the ability to layout buttons in grids or lists.

Drawing

Drawing is a little different in Cocos2D and iOS.  Spritebatch in XNA is pretty powerful – you can use it to scale and rotate textures, and even draw primitives (out of 1 pixel textures).  In Cocos2D, the draw method of a game object pretty much just draws the texture at the position.  If you want to get fancy (transparencies, primitives) you have to start using low level OpenGL calls, which can get tricky and feels like a bit of a hack.  Drawing a straight line requires a bunch of calls, setting different rendering modes and stuff.

Color objects are also a pain in Cocos2D.  Instead of single Color object like in XNA, there are 3 or 4 different Color structs, using different data types.  Depending on the function, you have to convert between them, which leads to verbose and inelegant code.  Alpha blending isn’t as versatile as spritebatch either.

Overall though, I’m very happy with Cocos2D and will be making some more games with the framework.

Ray Wenderlich

Ray’s blog has the best tutorials for building iOS apps, not only because he goes in such great detail and walks through the code, but includes standalone applications you can download, run and reference.  Best tips were on how to build a Save Game singleton, and info on in-app purchases.

In-App Purchases

These were annoying for two reasons – setting up the metadata in iTunes Connect and testing it through the sandbox, and then the technical challenges of implementing the API.  At first I tried to do it from scratch, using a Wenderlich tutorial.  Built a delegate class, used the notification center waiting for asynch responses from the store, was able to purchase to unlock game features.  But the entire thing felt very messy and tightly coupled with my game code.  And during testing, the sandbox was notoriously slow, so if I hit the buy button a few times, I’d get spammed minutes later with Purchase popups on my iPhone.  I ended up submitted with this first version of the code, but it failed because I didn’t include a “Restore Purchases” button.  Not sure if a bug would have been found, but I decided to implement MKStoreKit.

MKStoreKit abstracts all the in-app purchase stuff into a nice package, and wiring it up into an application only takes half an hour. The biggest step is converting the app to ARC, which is required for MKStoreKIt.  For Heartline, I ended up only converting the MKStoreKit code to use ARC, since the rest of the game, and Cocos2D was written without ARC.  Your mileage may vary.

Testing with TestFlight

appIDs

I wanted to beta test my game, so I decided to use TestFlight.  Once you make an account, you can upload a binary of the game, enable test users to access it, and even get feedback from an API (crashes, checkpoints, etc).  Building the binary was pretty straightforward, but setting up the various provisioning profiles was tricky.  Note: the provisioning profile must match the bundle ID exactly (case-sensitive!)

The only other frustrating thing about TestFlight was that once friends and testers signed up, I had to get the ID of their device, and manually copy this into the provisioning profile, then send out an updated binary.  You’re limited to only 100 devices, so if you ever wanted to do a massive beta test, you’re out of luck (unless you get an enterprise iTunes developer account or something)

iTunesConnect and Release

itunesConnect

Once the game was complete, releasing it on the store was pretty easy.  It’s a minor annoyance that you need screenshots for both iPhone 4 and iPhone 5, since they have different dimensions.  The actual review process was quick and clear.  When a problem came up with my first build (missing the Restore Purchases button), the status of my app changed and I was sent an email with the problem.  I was able to get a new build up there in a few days, and within a week it was approved.  Much better than the XBLIG lockout period and peer review.

The tools to monitor sales are also very nice, with charts and breakdowns by the day/month/year.  Of course, the app store is flooded with small little games, and since my app wasn’t really promoted, downloads dropped to almost nothing after the initial release.

But overall I’m pretty happy with the experience of building and releasing a game on iOS.

My next goals are to build some more advanced games using what I’ve learned with Cocos2D.  I’m not sure the in-app purchase model is the way to go.  It seems like you only cross a threshold of profitability if your game is very popular.  But it’s a good reminder: I’m not in this for the money 😉

NanoDoc for Windows

I’ve finally ported NanoDoc, my XBox Live Indie Games Shooter from 2012 to Windows.  The gameplay is the same, but now the nanobot is now controlled with the mouse, and the controls are slightly different.  It’s totally free, and can be downloaded here!

Check it out!

I’m in the process of porting the game to HTML5 as well, but that’s a bit more involved (and may not ever happen, depending on the performance of the swarming germs, let alone HDR effects).

NanoDocNew