From the cold snowy hill

A post before the end of 2008

Preface:
My mote-m experiment has effectively ended. Although it's still available in the store it has been superseded by team efforts from real artists looking to (and succeeding) at making it big on the app store. I wrote a postmortem about my experience about two months ago. I never published it because the iPhone App Store scene continues to change at such a rapid pace that anything written is immediately out-dated and irrelevant. In spite of that fact, I will share a few parts.

Introduction:
Let me say that these are my personal experiences and observations as an independent/first-time iTunes App Store game developer. I built Mote-M from the ground-up. I created the web site, wrote the code, created the art and answered everyone's kind emails. I consider Mote-M to be a success in it's original goals and a failure to achieve it's full potential. I might be wrong on any conclusions I make and apologise in advance for my poor grammar and inconsistent tense. You have been warned.

Development:
Mote Massacre, Mote-M for short, is a Tower Defense game in the style of the Desktop Tower Defense games. It started it's life in December of 2007 as a flash multiplayer game. When the iPhone SDK was announced the decision to port the game engine was made. After being approved by Apple in late-july (along with the rest of the non-special developers), I ported over the basic game and decided to launch the app as a fun toy-app for $0.99 in mid-August. The original goal was to build a fun game which would also pay for the developer registration. I really only expected maybe 20 people to buy the game. Since August I've watched the app store grow and evolve.

A Learning Experience:
Revelations I had as a complete n00b in the iTunes app store game business.

Quality of apps: The quality of apps and the relationship with an app's price and sales volume has been discussed elsewhere. It's still important to mention that with very low app prices a developer has to make money somewhere else or succeed in selling a very large volume.

Top sales lists DO matter: there are a set of passionate gamers who read the blogs and the forums and participate in the app store community but I'm willing to bet that the majority buy off the front page and the top paid apps lists. This is not surprising -- I probably wouldn't visit the forums and blogs if I weren't developing for the platform.

Rampant Piracy of Apps: The day you release your app for purchase is the same day anyone with a jailbroken phone can download your app for free. It's a fact of software -- you can't stop it, so don't try. The amount of time I spent trying to figure out the convoluted app DRM scheme could've been spent on developing a better app. To be fair the code signing stuff is pretty much a one time setup but from a goals standpoint it *just* fails.

The app store has huge potential: A developer can make a lot of money if they launch the app perfectly. Where perfectly in that sentence means: releasing an eye-catching, functional app which encourages impulse buys. Impulse buys fuel the app store right now. This may also be contributing to lower prices.

The Community:
This is one area where I was pleasantly surprised. The community of people who gathered around Mote-M are passionate and highly engaged. The e-mails I've received have been almost universally helpful and encouraging. Any developer not embracing their community is definitely losing valuable feedback.

Future Plans:
As I write this I have xcode open to a new super-secret non-game project for the mac. Once that project matures I'll return to the app store to see what sort of climate there is for indie game developers. Right now there seems to be a new flood of ports from existing games: SimCity (tm), TETRIS(r), Brothers In Arms(r), etc. Without users being able to demo apps they may stick to more well-known and bigger names instead of supporting software devs who create more original apps.



About gxjones.com:
Independent software developer Grant Jones started gxjones.com in late 2006. Grant grinds away creating another independent game with the experience he has gained from Mote Massacre and past applications he has written.

Mote-M v1.2

My blog makes it look like I haven't done any thing for the past 2 months. This is simply untrue! I've been consumed with my Mote Massacre project which is currently available on the iTunes App store for $0.99.

Originally called 'Mote Massacre' I shortened the name to Mote-M because the icon on the iPod showed up as 'Mote...ascre' which doesn't sound quite right.
Mote-M is actually the evolution of the two-player tower defense death-match flash game I created back in December of 2007. Unfortunately I took down the server that was running the 2pTD flash game so it can't be played anymore; maybe someday it will come back -- or maybe Mote-M Multiplayer will be released?

The gxjones.com site has all the details on this game.

2pTD - Development Part 2 (A* Pathing)

Continuing in the series describing how 2pTD was built (Part 1):
When I set out to create this multiplayer game I knew the unit pathing system would be the most integral part of the whole system. Unit pathing is an algorithm which determines the path the unit will take from a source location to a destination. There are some great resources online for learning all about graph search algorithms. I chose the A* search algorithm for its simplicity.

There are two cases in the 2pTD game where pathing occurs:
1. When a tower is placed onto the field all units are checked to make sure that a path exists from where units currently are to where they are going.
2. When a new unit enters the field.

In retrospect the implementation of the system isn't exactly the greatest. Specifically, towers should take up a 2x2 area of the field instead of the 1x1 they currently do. This would make the paths of the units more interesting and would also greatly increase the placement options because the field size would be doubled.



Here is the pathing sandbox which was built for the purpose of developing the pathing algorithm and also to develop the networking system.

Usability and first impressions

So it's been a few hours after I submitted my 2pTD tower-d game to digg. Things I've learned so far:

• 6 diggs after first submission, only ONE actual visit to the page (my guess is these are paid or volunteer moderators)


• only 2 or 3 people actually played the game :(


• because I did something stupid: I placed "New Game" above the "Single player" button -- the result is people get to the waiting for another player message and then leave (because no one else is playing!). Can't say I blame them!


• those that did play were interested in apparently getting their score in the high scores gallery


• python is a bit heavy even for this small use -- it never seems to release any memory. I chose to use one python process for all sessions because of the python startup time and resident memory size; I could startup individual processes for each session but would quickly run out of memory taking that approach (not to mention the startup time of python). What I'd really like is to be able to have an individual memory pool for each session but only have one python instance and just cleanup a sessions pool when completed. My implementation is probably to blame for any memory issues here.


• Not that I expected it to be, but it wasn't a smash-hit... back to the drawing board.


• If it did get lots of traffic the site could get killed by bandwidth usage. Weighing in at 1,883,094 bytes the SWF file is quite large. Then add in the bandwidth used by the actual game and it starts to become significant.


• There is a general lack of interaction -- there should be chat capabilities or at the very least forums

2pTD - Development Part 1

Here's my post to attempt to describe the technology behind my 2pTD game.
Basics:

• One developer (Grant), MTASC + swfmill, 2 months to develop


• Flash-based client communicates with servers using XML via XMLSocket connection.


• dmtdsrv: Custom Python/C server utilizing libevent (base game engine)


• 1 or more dmtdsrv servers acting as lobbies (where games start, high scores, current games)


• 1 or more dmtdsrv servers acting as game session servers (where the actual game is simulated)


• lighttpd web server


• memcached which holds game and misc. state info

Details:
Once the flash client is loaded, they connect to the lobby which shows current games. When they select start single or multiple, players are assigned to a session ID, which is used to determine which session server they will be connecting to. Players are internally mapped to a session as well during the transition from the lobby to the game session -- this also prevents players from joining sessions which they weren't meant to be in. All communication is done via (not so compact) XML messages.

The client is intentionally as dumb as possible to avoid cheating and to allow the server to be the authority. All the tower specifics such as amount of damage and ranges are all determine server-side. This has the side-effect of making replays and real-time spectating of games possible without making massive changes to the flash client code. The flash client code was actually written completely in ActionScript using swfmill and MTASC to build.

Graphical resources were built using a combination of custom vector editors/animators and various graphics editors. Stay tuned for more info on these tools.

After every tower wave the game session state is sent to the memcache so it can be displayed in the lobby. Each session server is uniquely named and can handle many sessions. The system is designed to be able to handle high loads by starting many session daemons across many distributed servers -- although right now it's just 1 lobby and 1 game session.

Try playing 2pTD!

Part 2 will cover the unit pathing system, part 3 will cover the dead reckoning system.

TwirlVectorEdit

TwirlVectorEdit: The first step in creating a nice symmetric image that can be rotated (or neat effects can be applied to). You can download TwirlVectorEdit for your Mac running Leopard for free. It's a pretty specific tool (I don't even think of it as an application) so it is very rough around the edges. I'm almost positive illustrator does something like this but I don't own it so I had to make this. I used this to create a starting point for making rotating selection indicators (originally for the 2pTD game). I later ended up using the output of this program along with another custom tool to create animated "pulse" graphics which are currently use in the 2pTD game. The left pane contains the filled polygon you create with the mouse, the right pane shows the "twirled" resulting image. See the contained README for instructions on how to use it.

TwirlVectorEdit Application
TwirlVectorEdit Source (not much to it really!)


I used this tool as the starting point for making flash animations like these:

More to come on the tools I used to animate these.

2pTD - update 4

More updates, hooray! Added a third tab to the lobby called “High Scores” which is a neat display of past high scoring games. The bottom section shows a mini-preview and when clicked the field is shown as it would’ve been in game. The list is periodically updated (as of right now all games will go into the high score list). Still more improvements are in the works — things like sound and the ability to see the hit points of units as well as their resistance/speed values. The game as it stands right now is definitely fun so try it out now!

(copied from tumblr to blogger)

2pTD - update 3

2pTD updates: added single player which means you play against the computer (1pTD) — everything works the same way so it can be used to get a feel for the game. The computer AI itself is pretty basic at this point and sometimes it fails miserably against a real player. Also added a new class of towers: support towers and 3 new support towers. Support towers are short duration towers which provide benefits to other towers immediately surrounding them (right now it’s the 8 positions around the tower). The new towers are: resource reduction support tower, attack speed increase tower, and an attack speed decrease tower. These provide temporary buffs only a few seconds.

(copied from tumblr to blogger)

2pTD - update 2

quick note: If you’re playing on a slower computer it helps when there is a lot of action going on to reduce the quality of the flash app (right-click and selecting medium quality or lower). To safari users, there is a drastic performance difference between local network performance (when I was doing development) and remote network performance (when you play on the gxjones server) causing some annoying lag issues with the user interface. Lowering the quality may also help in this situation.

(copied from tumblr to blogger)

2pTD dev picture

A* Pathing sandbox I used during the initial development of the tower d game.

Multiplayer Tower D - 2pTD

Just about to release my take on what a multiplayer Tower Defense game should be. Hopefully the server won’t crash and there won’t be too many bugs. This is the result of about 2 months work — which isn’t too bad considering the scope of the project. It’s interesting that the wikipedia entry for Tower Defense is to the *Desktop* Tower Defense version which is not the original tower d game (the premise of the game is pretty old). My first time playing a tower d-style game was back in 2003 with the WarCraft 3 mod. Anyway, check out my multiplayer version assuming there are other people online to play it with you.