Developer Interview - Star Trux

In my article "A Brief History of Video Game Development" I focused on the long history the developers of Star Trux had together.  As a follow-up, I thought it would be interesting to get more specific details on exactly how they made the game.  I asked the developers questions regarding their development process and compiled the answers together here.  Hope you find it as interesting as I do.   - Matt Powers

Ken Balthaser and John powers started making video games together in the 1970's.  They continued to work together at Atari in the early 80's.  Recently, they thought it would be fun to make a game together again.  That game become Star Trux.  Ken as designer, John the engineer and Rob Powers as artist.

I recently got the Star Trux team together to answer some questions about the making of this game.

How did you all meet?

JOHN:  I had met Ken in the late 70's.  I was a founding partner of The Authorship Resource, Inc. in Columbus, Ohio.  Our initial goal was to produce software for the Plato system.  After starting our company, we got involved in developing the OS and applications for the new CyberVision 2001 home computer being sold by Montgomery Ward.  My business partner and I had created an authoring system that did not require any programming expertise.  We needed creative people with excellent design and writing skills.  Ken was our first hire. He was exactly what we needed.

What was the inspiration for Star Trux?  How did you come up with the concept?

KEN:  Way back in 1977 we created a game called Bulldozer in which you pushed blocks around the screen into a goal.  I thought that it would be a neat idea to take this basic pushing theme and put it in space.  Unfortunately, the company went out of business before it could be tried.  A couple of years later, while at Atari, I presented the idea of Star Trux to the Atari marketing department.  Then, Atari went out of business.  I was beginning to think that Star Trux put a curse on companies so I locked the idea up in my head to prevent further carnage.  Besides, video game consoles became ever more sophisticated and soon it took legions of people to make them and they cost about as much to make as the Space Shuttle so I gave up on even trying to revive Star Trux.  Then, along came the iPhone and simple games were back in vogue again.  Hoowaa!  In the meantime, John had been programming iOS apps and I knew from previous experience that John was a programmer extraordinaire.  I laid the Star Trux idea on him and he bit.  Given Star Trux's history you might want to sell any Apple stock that you own.

How many people did it take to make Star Trux?

JOHN:  There were 3 principal contributors:  Ken, the game designer and sound engineer; Rob, the artist; and me , the software engineer. We had help and encouragement from Matt Powers and Eunice Balthaser Wlcek. Edgar Allen Crow (a rehabilitated bird my wife rescued) perched in my office and oversaw code development.

How long did it take to make Star Trux?

KEN:  38 years, but that included the time it took Apple to come up with the iPhone.

KEN:  Actually, it took about 15 months, but that included the time it took John to learn the iPhone game whatchamacallit, for me to learn new sound editing software and for Rob to learn new graphic software .

JOHN:  We started with the game idea in July of 2012 and completed development in November of 2013. I started my research into what software to use to develop the game in July of 2012 and had a working proof-of-concept app in September of 2012. By January of 2013 we had a release that began to look like Ken's game concept. We spent the rest of the year refining the game play and testing.

ROB:  But if you think about when Ken first came up with the idea for Star Trux from the ARI days until we had the technology to make it - then 38 years isn't far off.  

What tools/middleware/licensed software did you use in the making?

JOHN:  The development environment was Xcode and iOS SDK on a Mac Pro.

I had developed and published a handful of apps using UIKit.  The apps were primarily SQLite and Core Data with lots of UITableViews.  I was excited about Star Trux because it was a chance to do something entirely different.  At first, I didn't even know what tools were available.  I looked into OpenGL ES and decided that it was overkill for Star Trux.  Apple's iOS Core Animation was not appropriate for games. I finally came across Cocos2D and Box2D.  I decided that Cocos2D would provide the structure for the game, Box2D would handle the physics, and UIKit would provide embellishments to the user interface. The final game is a mixture of all three.

We had locked-down the game just before Apple announced the Sprite Kit in iOS 7. The Sprite Kit was similar to Cocos2D and Box2D, but with a lot of class name differences and method differences. A last-minute conversion would have been a risky and time-consuming process.  It was too late to use the Sprite Kit, but if I were to do it again, I would definitely look into it.

We also used email, Skype, and Dropbox during development.

How was the art generated?  What was the art pipeline?

JOHN:  Rob created the art. I used Graphic Converter to rough-out placeholders until Rob provided the actual art. We used Dropbox as a way to share files.

ROB:  John drafted me into doing the art for Star Trux.  Not that I minded . When I found out that he and Ken had cooked up the idea for an iOS project, I was looking forward to getting involved.  You could tell early on Ken had some really strong ideas for the design of the game.  We talked about the look and style of Star Trux quite a bit.  He pointed towards the work of Simon Atkinson who did illustrations for 2001: A Space Odyssey.  Simon’s work was great but the challenge for me was communicating those design ideas into tiny little sprites for the iPhone and iPad.  My previous game projects were all 1^st person shooter / RPG titles which let you create models with lots of minute details in three dimensions.  Even so, I went ahead and created all the in-game objects using Autodesk Maya.  The Star Trux ship had a detailed cockpit and a pilot who I dressed in a bright orange space suit similar to the one Dave Bowman wore in 2001: A Space Odyssey.  You can’t see it in-game but it’s visible on the title splash screen.  After rendering the objects out, I then tweaked the images in Adobe Photoshop.  Photoshop’s ActionScript feature turned into a huge time saver when I found out I had to do seven different versions of the title screen and game icon to meet Apple’s submission requirements.

What was the physical work environment?

JOHN:  The three of us worked from our homes. We used email for daily communication, used Skype  for weekly phone conferences, and used Dropbox for transferring files.  App builds were distributed iOS OTA (Over The Air) distribution.  I would do a build every week and put the app and release notes into Dropbox.  The release notes were in HTML with a link to download the build directly to an iPhone or iPad.

What was the most difficult/challenging part of making Star Trux?

JOHN:  Cocos2D and Box2D were all new to me. Fortunately, there were a lot of good tutorials, especially by Ray Wenderlich, about the software.

We decided right away that the app should be for iPhone and iPad. This required three interfaces: 3.5-inch iPhone, 4.0-inch iPhone, and iPad. The underlying game play code was the same for all three, but the views were optimized for each device. Each view was a separate class and corresponding IB document ("nib").

Dealing with Ken's creative side was also a challenge. I liken it to getting behind the wheel of a high-powered sports car. Sometimes it just goes too fast and nearly wrecks. Fortunately, Ken is easy to get along with and we stayed on the track the whole time, but he's definitely an all-wheel, 8-speed, supercharged V-12.

KEN:  Deciding on the price was another challenge.  Our initial price was $499.00 but we gradually worked our way down to free after some focus groups stormed out of sessions when asked if they would pay real money for any apps.  They were very convincing so we opted for free and decided that we'll make up the difference in volume.  Seriously though, for me it was sneaking feature creep past John.  As a designer, I always wanted more but that needed to be regulated by schedule and engineering capabilities (damn those practical engineers).

ROB:  Though Ken was joking, pricing for an iOS game is tricky and we had many discussions on this.  With our free-to-play version just out I think we have the best solution/compromise.

What was most rewarding?

KEN:  A cold brew during our weekly Skype calls.

KEN:  For me it was working with my long-time friend, John and just having fun without the real-world pressures of meeting deadlines and keeping investors happy.  Nobody's job was on the line.  We didn't have to worry about meeting some arbitrary company deadline.  John and I are both retired so this was a work of pure enjoyment.

JOHN:  Working with Ken and Rob. Learning about new ways to do things in iOS. Adapting the standard iOS library to fit our needs. Ken would propose something and I had to find a way to bring it to the iPhone/iPod. This happened over and over again. It was difficult and stimulating.

I also enjoyed translating the game concept into object-oriented code.  I wanted to build something that was architecturally solid enough to handle ad-hoc game improvements without requiring major code re-writes.

Another rewarding thing was coming up with a way to give Ken unrestrained control of game play.  It became apparent during development that Ken was going to constantly "tweak" the details of the game's behavior.  He would ask for a change in some small parameter and I would have to change the corresponding constant in the code. Instead of having Ken ask me to make changes to the internal game constants, I created a property list file containing a spreadsheet-like data structure describing all the internal game parameters. I also created a user interface so that Ken could edit the parameters while he was playing the game. When Ken made a change, it updated the property list file as well. There were 23 parameters he could change for every Challenge, Mission, and Level, well over a million possibilities. He could make the changes and see the results immediately.  When he was happy with his changes, he would send me the updated property list file and I would drop it into the build.

ROB:  Working with John and Ken was the highlight of the project.

How did you handle the testing/QA?

JOHN:  Ken and Rob did most of the testing. We had to be careful to distinguish "Anomalies" from "Enhancements". An anomaly  was something that was not expected. "It should behave this way, but it doesn't." If we had agreed in advance how it should behave and it didn't, then this was a bug report (an "anomaly"). Sometimes it morphed into "I want it to behave this way, but it doesn't." If this was a new desired behavior, it was a feature request (an "enhancement"). We agreed to treat anomalies as must-do's and enhancements as maybe-do's. There were frequent animated discussions about what is a must-do and what is a maybe-do. If we hadn't been disciplined about managing the must-do's and maybe-do's, the game would have taken an extra year or maybe never finished.

KEN:  John writes such perfect code the first time that we hardly needed testing.

But, even as good as he is, and he's very good, we ran the game through rigorous testing cycles.  One of the challenges was getting John to see in real-time what a bug was doing.  You see we don't have an office so we all three worked out of our homes and communicated via email, Skype and sometimes by phone.  I got so good at the game that I was able to reach the outer limits, so to speak, and I would find an esoteric bug that John was unable to reproduce because he was so busy coding that he had scarce time to play the game.  So, sometimes I would do screen captures or video captures and post them on Dropbox for him to look at.  We didn't use any formal testing software but rather Rob and I would play the game and if we ran into a bug we would document it in a formal style with as much information as we could provide to John.  A Typical bug would be structured like this:  Game Version; System Used to Test (iPhone, iPad, etc.); iOS version; Detailed Description of the Bug, including which Challenge; which Mission and which Level; How to Recreate the Bug; Expected Result - to let John know what we expected to happen.  And I think this was fine for a simple game like Star Trux.  It seemed to work.  The game is very solid.

ROB:  My kids were a big help with testing.  Watching them play and getting their reactions were good for both tuning and finding bugs.

What tips/recommendations do you have for other people interested in making an iOS game?

JOHN:  There are lots of good books and tutorials available. Start with something simple. Build from there. Once you feel comfortable with the tools, throw out all all of your early work and start fresh. Build a strong code foundation for your game.

Work with people that you really enjoy working with. It makes it a lot easier and much more fun.

KEN:  Jump in and try it.  What do you have to lose besides a year or more of your life?  Start with something simple and small.  Think through and document as much as you can about the game, i.e., the game mechanics, the game play, the game style, the game genre (what kind of a game to you want -- action, strategy, role playing, etc.).  Do some mock up art.  Get a small prototype up and running as quickly as you can to see if the game has any merit.  Sometimes things that seem good in your head or on paper do not turn out to be fun when you actually code them.  Do not design by committee.  A good game needs a strong visionary who can articulate to the team members what their vision is and then keep the game on spec.  It's okay to get feedback and ideas from others, but in the end there has to just one person to make critical decisions about whether something goes into the game or not.  But, always include your programmer(s) when deciding on a feature.  They will know whether the feature will be easy or hard to implement or whether the feature will impact performance and so forth.  If it's something that you really feel strongly about and the programmer digs in his heels, ply him with beer and keep wheedling.  He'll give in eventually.  Just joking about the beer part.

What would you do differently if you had to do it all over again?

KEN:  I also had this idea for a game that involved birds that were contented.  I called it Happy Birds. Maybe we should have done that one.

KEN:  I would have rethought the control mechanic of the Trux and spending some more time on trying  variations of our control.  It works good but I have a feeling that if we had spent some more time at the start on tweaking how the control works the game play would have improved.

JOHN:  If we were starting an all-new game now, I would look at using Apple's Sprite Kit.

Where can I find out more information about Star Trux and the development team?

ALL:  See the game web site - http://www.startruxgame.com

Do you have questions for the Star Trux development team?  This is your chance to ask your own questions of this small development team.  If you have any questions you would like to ask about the making of Star Trux (or anyting else) go ahead and write a comment and I'll get you an answer.  

If you liked this article or have any questions about it please leave a comment.  For more articles written by Matt Powers you can visit:

http://www.gamasutra.com/blogs/MattPowers/951858/

If you would like to contact Matt Powers you can email him at:  [email protected]">[email protected]