• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
  • comments
  • views

Refactoring and Mad Ramblings

Sign in to follow this  
Followers 0


A few weeks ago, I posted an article on OctTrees. I put two days worth of effort and time into creating it. It needed to satisfy my own criteria for what an adequate article on the topic should cover and how it should cover it. It was kind of fun to get the exposure and I'm happy with it, but I'm also kind of silently questioning the point of it and the value of writing the article as it pertains to the progress of my game. If anything, it was a distraction and waste of time because it stopped me from working on my game. I could justify it by saying its my way of giving back to the community I've taken so much away from, but... at the end of the day, game progress wasn't being made so its just an excuse (I'm hard on myself).

Moving one step forward and two steps back, I decided that I needed to create a fancy, new system for rendering simple primitives. I had an existing one in my engine, but it was written a few years ago and I was finding that the capabilities it offered were now inadequate and didn't sufficiently take advantage of the new stuff I now knew how to do (like hardware instancing using HLSL). My dream was to create a super powerful, robust, one stop shop type system for doing all types of primitive rendering using hardware instancing. You'd be able to render point sprites, quads, billboards, lines, textured and untextured triangles, etc. using one system for it all. This "primitive system" could be extended by a particle system as well: The particle system would pretty much be responsible for telling the primitive system when, where and how to render a primitive and the primitive system would take care of everything else and render it using hardware. The only bottleneck would be the GPU, and going by the advancement of modern hardware, it's quite a fat pipe to throw triangles around in before performance becomes an issue.

Anyways, that was my half step forward. I started implementing it, and as is typical to true programmer fashion, I found so much "stuff" that needed to be fixed/reworked before I could go forward. I decided to reorganize my game engine by sorting classes and name spaces into a more logical manner. For example, I have this static "Calc" class which has a buttload of handy math functions which was stored in a generic "Utilities" namespace. I also had an XML parser stored in there. "Wait a minute, that makes some sense but not enough sense!" I said to myself... "The calc class does math, so I should create a "Math" namespace for it!" and "XML has to do with reading files, so it should go into an IO namespace!". A "utilities" namespace is too vague and smells like a trap which can collect too much garbage if I'm undisciplined.
I know I'm getting into irrelevant minutia here, but it just goes to show how far into the weeds I'm going with this refactoring effort. The reorganization makes a lot more sense and leads to more clarity. Clarity is good, even if it takes a step back to gain it. My usual programming methodology is something along the lines of "Just get it working, get it done, doesn't matter how or if its ugly -- figure out how to make it pretty later!". As an agile practice, it's alright... but as I'm seeing now, if I take any sort of sloppy approach, it just means I'm going to have to go back and rethink & rework that area of code at a later time. I think its unavoidable though. When you're taking a first stab at something, you barely know what you want or need so you can't expect yourself to get it perfectly right the first time. If you aim for perfection the first time, you're going to take too long and you'll probably over engineer parts which end up unused. Hence, Lazy + sloppy design + refactoring = more efficient?

Anyways, this primitives system is going to be a large backbone in my game and game engine, so it's worth it to put in just the right amount of effort to make sure its done right. And to do it right, I have to make sure the framework its relying on is up to snuff. At the end of the effort though, you really have to take a step back and honestly ask yourself: "What did your game gain from this effort?" and if you don't have a good answer, maybe it was a waste of time and effort which could have been used more wisely elsewhere. That's a harder call to make when you're working on more abstract, intangible bits, right? The trap you want to avoid is fixing things which aren't broken or over engineering things beyond whats necessary.

Oh yeah, when I decided to reorganize, decouple, and rearchitect everything, I also didn't make any backups of my working game (probably not wise). It certainly doesn't compile right now and it's got a few dozen errors right now. It's also required me to revisit previously working classes and update them to the new architecture, possibly breaking them completely. I wildly estimate I have about 150k-200k lines of code and have exactly 170 classes. I have every confidence that I can get my game to compile and run correctly, but its going to take a lot of time and effort on my part. The game will only grow in size (probably quadruple the class count?) so it's super important to have everything well organized before it grows any further.
I recently got interested in watching Chef Gordon Ramseys "Kitchen Nightmares" television show on netflix. The gist of the show is that he goes to visit failing restaurants and tries to help them get back on their feet before they have to close their doors. Surprisingly, I find that this show is less about kitchen problems and more about the people problems in and around the kitchens. He'll walk into a kitchen and it is filthy. The cooks are arrogant or incompetent. There is no leadership. No organization. It's pure chaos and confusion, everywhere, every day. The nightmarish kitchen is just a manifestation of these people problems. The core tenants Chef Ramsey adheres to seem to follow this theme: "Simple menus. Clean kitchens. Fresh, quality food. Good cooks. Good communication. All brings good food and happy customers."
I feel a lot of those same principles can be applied to making a game: "Simple code. Clean code. Commented and documented code. Good programming discipline. Good consistency. Good design, good vision. All brings good games and happy players."
You don't want to have a nightmare game project, so when things get dirty and out of control, it's time to roll up your sleeves and start scrubbing that dirt out. Coding further is like cooking in a filthy kitchen: Whatever you create will be contaminated and unsanitary until the underlying problems are resolved.

Heh, one advantage of working alone is that I don't have to hold clarification meetings or try to sell other people on my ideas. On the other hand, if I'm about to shoot myself in the foot, nobody is there to stop me... It's a true test of competence and capability.

Enough rambling! Back to code and coffee!

Sign in to follow this  
Followers 0


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now