Gamasutra: The Art & Business of Making Gamesspacer
Dominoze PC Post-mortem: Nine Years, One Programmer
Printer-Friendly VersionPrinter-Friendly Version
View All     RSS
April 20, 2014
arrowPress Releases
April 20, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM TechWeb sites:


 
Dominoze PC Post-mortem: Nine Years, One Programmer
by Christopher Haag on 03/12/13 07:59:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

It is possible to give yourself too much freedom to develop a game. I learned that after transforming the development of a physics puzzle game into a personal Mount Everest of feature creep.

Dominoze
Dominoze


The story begins in February 2001 when I got the idea for a puzzle game where you have to knock down a trail of dominoes by manipulating objects along the domino path. I thought the idea was so great, I hardly got any sleep that night! Development began the next day, and ran its course over subsequent evenings and weekends between 0-15 hours per week while I worked a full-time job writing unrelated software.

My development philosophy was this:

  • Integrate only third-party libraries that are completely free to use, and do so with as few libraries as possible. I wanted to develop the game on a $0 code budget (except for purchasing Visual Studio and some other development-related tools), and to do as much of the programming as possible because that's what I love to do.
  • Work alone to maximize control and flexibility of the project; and to see if I could pull it off as the only developer. This was a largely ego-based decision.
  • Don't study other successful games to understand how they worked. I wanted to be as original as possible, and would not tolerate saying "I was inspired by to make my game" or even "I studied to make mine better."
  • Don't quit my day job; keep game development casual.
  • Develop features on a need-to basis; no need to write out a design document at the beginning.
  • Don't worry about marketing. I'll do that when the game is almost done.
  • Don't maintain a developer journal, blog, or regularly network with other game developers. I didn't want to go public until I at least had a playable demo or something close to it; and maintaining those things was a distraction from programming.
I list all the tools I used later on in the Facts Sheet section.

 

2001
This year was spent trying and failing to write my own physics engine. I learned quite a bit in the process which helped me out later on when using other physics engines. I also wrote the "glAppGrapher" which is a great debugging tool for when you want your program to render things in a separate window acting as a "graphical server."

The glAppGrapher
The glAppGrapher "graphical server" application



2002-2005

These years were a cycle of tinkering with, shelving and unshelving the Dominoze sandbox puzzle editor and game engine at the continued 0-15 hour/week pace. By October of 2004, after perhaps 3 or 4 attempts from near-scratch, I had written a fragile-but-functional game engine and editor based on the Newton physics engine, FreeGLUT, OpenAL, LuaScript and the CxImage library. That is the same month I also founded Gamieon, Inc. as the front end for Dominoze development. Four years is an awful long time to tinker around in even if it is under 20 hours/week; but time flies when you're having fun!


Dominoze Editor
The Dominoze Editor

2006
In 2006 my focus was on developing game content itself at the same pace as before. I still did not know exactly how I wanted the levels to look even for much of that year, but that's not for lack of trying all kinds of ideas. I finally conceeded that since I can't come [[up with an art style myself, I would just fall back on photorealism. Rather than focusing on puzzle design and cranking out dozens of levels which reused the same concepts in different ways, I wanted each level to be as unique as possible and have elaborate backgrounds. At the same time, I wanted 100 levels. There wasn't a story to the game at this time; it just didn't seem important. Since everything was moving so slowly, 2006 was the year I started asking people for help with art and level designs. I started by commissioning one artist and one designer to help me out. The collaboration was simply "Can you please create X for me?" We'd agree on a pricing structure, got the work done, funds exchanged; and that was that. Of course, the art assets created new demands on my engine and editor, so programming continued to stay focused there.


Dominoze Game Play
Dominoze Game Play -- Rotating Stairs Before Moving Them


2007-2008
These years saw continued level and engine development as features were added on a "need-to" basis as I came up with new ideas. Why just have turntables when you can have pulleys? Why pulleys and why not gear puzzles? Laser-mirror puzzles? Fans and blimps? Absolutely! There was no plan in place that defined boundaries on the project in terms of time or features. Dominoze was becoming five games in one! My development pace increased to about 10-20 hours/week. Despite bringing more level designers and artists to help me out, my requirements for the level count dwindled to 50 because making just one level was a big undertaking. In addition to "...please create X for me...," I invited everyone who I commissioned to have online chats and e-mail threads for sharing their thoughts on various aspects of the project. I also got the bright idea to start writing my own light mapper to make the levels appear more realistic. A developer could make it their full time job to maintain a light mapper; but hey, I wanted to see if I could pull it off! I wanted Dominoze to look as professionally done as possible, and give the illusion that there were multiple programmers working on it. I also finally came up with a story for the game: It would be about a parrot trying to rescue his friends. In return, the parrot would give you clues on how to solve puzzles.

Dominoze Light Mapping
Dominoze Light Mapped Scene
 

Some advice for new and aspiring game developers: Coming up with a story for a game six years after its inception is typically something you don't want to do.


2009
This was the most critical year for Dominoze; it was the year I finally said "I'm done tinkering with this project. I want to get the beta out and see if it's viable to even finish." By this point, I was investing all my free time into the project, and work had begun on the trailer. Things came to a head around July when I officially stopped new content development, and put all my energy into finishing the trailer, testing, and cleaning up all the existing content and engine features. Finally, in December of 2009, I released the first 30 level beta on IndieDB.com after a friend recommended the site to me as a launching point. Feedback on the site was scarce although positive. I got only a few bug reports, and addressed them all with subsequent updates while using Trac to maintain my bug lists.


2010
This year was the last year of Dominoze development under my existing code base, and the first year I opened myself up to really networking with other people. In March I went to GDC 2010 and showed Dominoze to a few people. The consensus was that it looked like a nice game, but it would fare much better if I were to simplify it and move it to the mobile market. I also spent some time in the Unity booth learning about their cross-platform game engine and development tools. I was a little disheartened, but nowhere near feeling like my world was destroyed (I explain why later in this article under "Rewards for Dominoze Development"). I decided it was time to finish what I had, and then take a long holiday from Dominoze and figure out what I wanted to do next. By July, I had released all the trailers, the Dominoze editor, and a few bug fixes to the game. As before, I only got a handful of comments; and nobody in the games press seemed really interested in it (though I didn't make a big effort because the game was still technically in beta without a release date).

I then stopped development entirely because:

  • It would never reach its real potential if I continued to approach it as a casual hobbyist and not as a committed game developer.
  • I'm done maintaining game engines.
  • There were easily hundreds of undiscovered bugs that I had no desire to spend hours and days hunting down any more.
  • I let the increasing demands of my full time job, combined with game development, turn me into a development machine with a lacking social life. I needed to break out.
  • Dominoze is only supported on Microsoft Windows whereas cross-platform games; which I've always wanted to develop anyway, were flourishing.


2011-2013
By 2011 I was comfortable using the Unity engine. I managed to create and play a very simple Dominoze level from scratch with Unity in the total time span of 2 hours. After 9 years.

To further study the prospect of Dominoze in Unity, I developed a small project called the "Gamieon Construction Kit" at http://www.gamieon.com/buildstuff which is a multi-player sandbox where you can add simple building blocks to drive falling marbles into a little box. Your creations are stored online for all to see. As the code was hacked together as quickly as possible and for discovery purposes only, I have no plans to re-use it at this time (and the gallery broke down some time in 2012).

Using the Unity engine, I developed three games in my spare time since 2010: Tiltz, Hyperspace Pinball, and Hamster Chase. As of March 12, 2013, they have nearly 80,000 downloads combined. I think my Unity skills are now ready for Dominoze...and this time it's going to be cross-platform and network-ready (but completely playable from start to end without an internet connection).


Lessons Learned and Affirmed (in no particular order)

  • If you want to tinker around and develop a game or an engine at a casual pace, then go knock yourself out. When it just goes on forever, or it stops being fun, or you're tired of seeing other developers accomplish far more in less time, then remember this: You did what you wanted to do, and you got exactly what you asked for. Stop doing it, and reassess your goals if you must.
  • When you're developing a puzzle game, all things related to user interaction must always come first. Keep other things like the background artwork simple.
  • Don't reinvent any wheels unless you plan to upgrade them into spheres.
  • Set limitations on yourself. Decide the project must be done in X months. Decide there will be between Y and Z levels, and don't be afraid to narrow things down along the way.
  • Even if you want to do all the work yourself, your chances of a successful release will increase if you set aside time maintaining a news feed and blog for your project early on. More exposure time means more new readers, and more of a chance for big media sources to take notice and write about your game.
  • Open yourself to continuous feedback during the entire life cycle of the project.
  • Let your game grow in release increments; don't do everything in the first release. Don't throw in every feature but the kitchen sink just because you think a first impression of your game is important.


Facts Sheet

  • Development tools: Microsoft Visual Studio, Visual SourceSafe (code repository), Trac (bug tracker), MS Paint, GIMP, Adobe Premiere Elements for video productions, and my old and still functional copy of 3DSMax 3.1 for modeling.
  • Video content: Contracted (see Special Thanks section)
  • Audio content: Contracted (see Special Thanks section)
  • Music: Donated by Mick Rippon!
  • Programming language: C/C++
  • Foundation libraries: GLUT for the game, Microsoft Foundation Classes for the editor.
  • Video engine core: OpenGL
  • Audio engine core: OpenAL
  • Physics engine core: Newton
  • Scripting engine core: LuaScript
  • Lines of code for Dominoze-specific libraries and Editor: 216,000 (including code generated from Visual Studio), 49,000 lines of comments*
  • Lines of code for the Gamieon-specific engine (designed to be used in other unmanaged projects): 18,800 lines of source code, 5,000 lines of comments*
  • Number of dedicated team members: 1
  • Number of contracted team members spanning the project's lifetime: 8

* Code Line Counts are approximations, and exclude blank lines. Calculated using the "Universal Code Lines Counter."

Costs of Dominoze Development

  • Total monetary costs: ~$10,000 spanning 9 years
  • Costs in order of size: Asset purchases, business expenses, hardware, website hosting and development tools.
  • Number of development hours: I can't even estimate them. I never kept rigorous track of time, so lets just say A LOT.



Rewards for Dominoze Development
Dominoze was never released as a completed product. It did not make any money. It also didn't come anywhere near the popularity of many Indie games. However, Dominoze is my "ship in a bottle." Looking back, I can now say that I programmed a game, a complex game editor, game engine, and video engine on top of lower level third-party components by myself (operative word is -programmed-; I had a lot of help with art and level design. See credits below.) While I do feel some envy toward Indies who did release acclaimed games; I think I loved programming and pushing myself against my own limits more than I did releasing games. I'll wear Dominoze as a badge of honor for the rest of my life.


The Future of the Dominoze Idea
Taking all the aforementioned lessons in consideration, I would like to take one last shot at Dominoze in 2013 using the Unity Engine. My goal is to create an app for the PC and tablet platforms that lets people create domino sets together real-time, watch as they knock over all the dominoes, and share with everyone online in a global catalog. To do this right, I need to:

  • Work with a team that shares my passion for the idea.
  • Find other sandbox apps where you just build or create stuff, and study everything about them to learn what to do right and what to avoid.
  • Gradually add new features in later releases over time instead of trying to get every great idea in at the beginning.
  • Create a plan and set goals and limitations which include a hard release deadline, milestones, a detailed feature list for the release and an idea box for future releases, a budget, and ways to gauge how successful it can be so I know I'll get a return on the investment. 
  • As much as I love programming, it sure would be nice to at least monetarily break even with all that I put into it.
  • Get myself and this project more involved with the development and gaming community in general. I've enjoyed countless quiet evenings of programming freely; but I've had quite my share of them.

I believe that a Dominoze app would reach its potential by being designed for kids, but fun for everyone. I also believe it would reach its potential by staying true to its creative core; and keeping players engaged by offering milestones, challenges, community building, competitions, sharing, and lots and lots of content.

What About the Legacy Game and Source Code?
I don't know what I will do with it; I just know that I have no plans to use it onward. Open sourcing it is one option, but I don't want to spend months training people on code where the comments and style are tailored for me and not for other developers. While the engine is designed to be lean and fast, it is too customized for Dominoze, and lacks a great deal of the functionality and ease-of-use that developers demand today. It is also not going to be actively maintained, but at least I can keep it around for reference. I'm willing to take things on a per-case basis if anyone is interested in the source, though.

Final Words
If you don't set a finish line, then you can never win a race. Even running a race will not guarantee victory; so don't postpone your happiness until you achieve it. Finally, don't work hard...work smart.

Special Thanks
Dominoze could not have gotten as far as it did if not for tremendous help with asset development from: Eric Barth, Jeff Gordon, Jordan Pelovitz, Yisroel Goldstein, Hélder Gomes, Russ McMackin, Bryan Taylor, and Jarien Strutts. Special thanks to Mick Rippon for donating his songs to the project! Special thanks to George Toderici for all the advice and web links that helped me with video engine development!

To the Reader
Dominoze PC Beta is still available for download at http://www.dominoze.com if you want to tinker with it. Feel free to drop me a line at c.haag AT gamieon DOT com if you'd like to give feedback or offer help with the project. 

Please follow my Dominoze news feed on IndieDB.com if you're interested in watching the new Dominoze project progress. If you have an iPad, Android tablet, or a PC; then I hope you'll enjoy creating your own domino sets once the app is ready!


 


Related Jobs

FableLabs
FableLabs — San Francisco, California, United States
[04.20.14]

Senior Tools Developer (C#, Unity3D)
FableLabs
FableLabs — San Francisco, California, United States
[04.20.14]

Senior Gameplay Developer (Unity3D, C#)
Activision Publishing
Activision Publishing — Vancouver, British Columbia, Canada
[04.19.14]

Principal Graphics Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States
[04.18.14]

Associate Engine Programmer






Comments


Maurício Gomes
profile image
Hey boss (I am one of the designers of this thing), great read! (and great you got featured here on Gama!)

(for those wondering why he listed me as Hélder Gomes, my full name is Hélder Maurício Gomes Ferreira Filho)

Also, I would like to also add that I used 3DS Max 7 as level design tool... not really recommended, but it worked :P

And Fireworks 8 as UI design tool (that one is awesome, wish someone made a improved clone of sorts, I am still mad that Adobe took it over...)

Todd Boyd
profile image
Awesome article! I'm about 4 years into a web-driven, grid-based game, and I think you just gave me the cajones to finally release what I have and then iterate for new features based on player reaction. Cheers!

scott anderson
profile image
What an epic journey, I remember playing a build of this in 2005-2006 after seeing it on the indiegamer forums. I had no idea you had still been working on this for so long.

Jason Wagner
profile image
A great article, and inspiring. I too have been incubating a project for a very long time, mostly solo, but that's from a design aspect. I haven't spent nearly as long working on the engine.

Babak Kaveh
profile image
Nine long years, and you still haven't given up - I applaud your persistence! I started developing a serious game prototype with a few friends (an oilfield simulation) about seven years ago and expanded and improved it for three years before I saw the light :P Then I modified the design to be more targeted and specialized, and after another three years of tinkering, like you, decided to ditch all of my code, and go for Unity - and here one full year of work later, and I am almost ready to take it to the market and see how it does.

Unity is one gem of an engine, and quiet flexible when you push against its borders. Just like you, my main takeaway from this protracted development cycle is that nothing in life is more enjoyable and important than learning, experimenting, and pushing yourself beyond your (imaginary) limits. If the simulation sells - all the better, if it doesn't, at least I learned to use four new programming languages, tens of common libraries, lots of 3d software, producing quality sound, art, etc. etc. all valuable skill in their own right.

Some software is good for the market, some software is good for you, and if you are lucky, sometimes it's good for both. Good luck with your other projects, and thanks for sharing.

Nick Harris
profile image
'If you want to tinker around and develop a game or an engine at a casual pace, then go knock yourself out. When it just goes on forever, or it stops being fun, or you're tired of seeing other developers accomplish far more in less time, then remember this: You did what you wanted to do, and you got exactly what you asked for. Stop doing it, and reassess your goals if you must'

I wholeheartedly agree with this advice. For me, the journey is the reward and its completion is merely a nice bonus were this even to occur. The whole endeavour could be seen as something to keep me from getting bored and slipping into depression, elevating it from a casual hobby to a kind of therapy - and on that basis it has been a resounding success.

I haven't had the money to employ anyone, yet over the years I have spent about $15,000 - at current exchange rates - teaching myself all I needed to learn by collecting over 100 books, before I could eventually afford to get an unlimited broadband connection and download numerous free pdfs and informative webpages, as well as expanding my grasp of the medium by collecting over 100 games for my 360 - many of which I bought to better understand genres that I normally didn't play in order to think of how they would need to change for me to want to play them and to analyse their controls to see how they could be integrated into an open world adventure that empowered player articulacy with a mix of genres that ensured that it kept fresh by having a varied pace: following flight with stealth, brutal interrogation with all out war, ordering your squad of AI driven soldiers around the battlefield whilst answering their questions with a real-time conversation system that was equally at home during debriefings, a system strong enough in its own right to allow the game to let you entangle your character in the machinations and interpersonal relationships of various simulated dramatis personae so as to cultivate a web of trust in order to afford access to an organisation's heavily guarded boss, a game encompassing colonization, commerce and combat.

Due to the scale of the endeavour I was aware that I would need to create better tools to boost my productivity than were available - mainly to support some extensive procedural generation. These needed a new multi-paradigm programming language to be developed and the Unicode glyphs it needed to represent mathematical equations and user manipulatable constraints required the creation of a new alphabetic keyboard layout.

I think the reason why it is taking so long (apart from having to teach myself everything I may need to know, only to come to the opinion that the benefits of OOP and FP are oversold insofar as they each individually represent a complete practical solution to any problem), is that I used to be afraid I would regret not spending more time on my tools/language/keyboard when I encountered some deficiency with their conception, integration, or implementation in the future and that the code base would be too large to allow me to change these foundations without incurring an enormous "ripple effect" in order to make the game-in-progress fit in these readjusted paradigms.

The ultimate goal is to write an MMORTSFPSRPG called "Universe".

So far, I have been working on it for twenty years. It probably needs another ten.


none
 
Comment: