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.
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:
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."
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!
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 conceded 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.
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.
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:
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)
Facts Sheet
Costs of Dominoze Development
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:
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!
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.
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 "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!
The Dominoze Editor
2006In 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 conceded 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 -- 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.
[url=http://www.gamieon.com/blogimages/dmscreens/1.png]
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
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.
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!