Jul 05 2009


Game loads below this line...

Daytrader was my first attempt to make a game which would actually be successful. Several people released ‘stock market’ games around the time I released Microbe. I played them all, since I was simultaneously looking for content for the portal aspect of Alaskagameworks.

They were all TERRIBLE.

Most of those developers had no concept of how a stock or commodity exchange works. It was obvious that they were using a random number generator to get their price changes. And their prices had little or no relation to actual pricing when real company names were used.

When I was younger I worked on the floor of the Chicago Mercantile Exchange, one of the two largest commodity exchanges on earth. Although there is something called the Random Walk theory, and while stock or commodity prices may be unpredictable over long periods of time… they are not random! And they are not single points either. There are bids, and asks which represent the highest someone is willing to pay and the lowest someone is willing to sell at. The difference between these is the spread. There is..

I don’t want to write a long description of mechanically how stock exchanges work…

The source code for the game was lost in a hard drive crash. From memory, there were two sets of classes I was proud of, the AI and the graphing sub applet. (Class is a programming term)

I used candlestick charts for the game because I find them easy to read and they are visually distinctive. Line or bar charts have little relevance in stock trading, and tick charts are slightly arcane. Each candlestick tracked a high, low, open, and close for the time period it represented. There was a method in my class which drew the candlesticks which would accept a new price, bid, or ask and redraw the candlestick as required. There was a chart object for each time interval which the user could select between, and each chart kept it’s own array of candlesticks, and scaled its own y axis. A separate timer for each time interval fired an event which told the chart when to close the current candlestick and draw a new one.

It doesn’t look like much but I was happy with my auto-scaling charts. The code to generate them however, required the flash player dimensions to be exact. This would cause problems later.

To simulate the market, I had an ‘exchange’ class which represented the stock exchange, and ‘AI’ classes which monitored the market and would enter orders. There were several AI behaviors and I don’t remember all of them. Like in real markets, there were ‘market makers’ who would ensure the spread between the bid and ask stayed under some value, I think I set it at .10. I did include ‘retail’ buyers who bought and sold small quantities at random intervals. And then I had a few types of large buyers and sellers who would enter orders based on various criteria.

All orders entered into the exchange were modelled as real orders, either market, limit, or stop and they triggered correctly.

I tuned the AIs so that the price would be volatile and move in an exaggerated but realistic price band. I thought the game was fun. The winning strategy of the game, like in some forms of intraday trading is to recognize when enough limit orders have been entered on the buy or sell side to form strong price resistance or support and then enter orders which would let you profit.

Unfortunately, I then took this technical masterpiece and skinned it with the ugliest user interface I could come up with. :)

So the game was played, and it did find a small following. But I was disappointed with the results. I tried doing some marketing, running advertisements on websites of small financial planners and a few other places, but while this drew some traffic to Alaskagameworks.com, that traffic didn’t stick either at the game or on the site.

I then approached someone who was offering to help developers improve their games in exchange for a link from within their games back to his site (a game portal). Although sponsorships like this are not uncommon, and for an unreleased game often the sponsor will pay the developer a fair bit, Daytrader had already been released. Despite this, he was interested when I described the problem and looked at the game. He also decided it was fun, but it needed a better user interface and offered to do a mockup.

Although I’m certain that we discussed how I write flash games, and the fact that I don’t _have_ a copy of Adobe Flash… and therefore I can’t read .fla files which are the pre-compiled versions of Flash applets produced by Adobe’s IDE, I’ve withheld the sponsors name because I don’t think he understood that last point, and so figures he upheld his end of the deal. Naturally the mockup came as a .fla I couldn’t read. I registered for a trial of CS3 so I could read it and found out that he had changed the game’s dimensions. The new dimensions would have thrown off the chart mentioned earlier, and would have required redoing several pages worth of math that I had done by hand. Getting the new buttons from the .fla to a format I could use was something I couldn’t figure out at all. And writing native AS3 and compiling it, versus attaching AS3 to buttons was something I only barely understood.

I did work on trying to do the conversion for about a month and then gave up the project.

Lessons learned:

  • It’s not enough for a game to be technically good if it doesn’t look good.
  • I should have done more market research before starting the project. It’s unlikely that most players even cared whether their little stock market game was behaving rationally.
  • Don’t enter into a sponsorship agreement without being sure that the assets being provided by the other party are something which you can implement.
  • Trying to market a website and game, and simultaneously code and produce art for a game is more than I can handle by myself.

1 Comment

Other Links to this Post

  1. NightFlyer Games » Why in-game ads — May 22, 2010 @ 2:32 pm

RSS feed for comments on this post. TrackBack URI

Leave a comment