• 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.
Sign in to follow this  
Followers 0

Black and White thinking, cognitive dissonance and your software architecture

3 posts in this topic

Hello, everyone.I really need to share this and ask if anyone else has experienced this.It's not ENTIRELY programming related, so that's why I'm posting it in the lounge.So basically, I've rewritten from scratch my game engine 7 times and I can't afford to do it again.The problem is, that every time I start out with the "perfect design, perfect codestyle, perfect performance, small as possible and clean as possible code, etc", yet some 50k lines later I start to hate the engine, I get a "This Engine Sucks"(TES) moment.I look at my code and then I look at other examples/tutorials/open source engines and I idealize them, while hating on my own work.I've also done a lot of worthless refactors and then refactored back to the original idea.Now the dissonance is back after reading this:
My current engine supports multithreaded command list generation in DX11, but the system is specific to the renderer and it's basically just thin wrappers over windows handles and a couple of windows threading-related functions.So is my decompressor for the texture streaming(placed on a free CPU core), however after reading this I envision some god-like threading system, which allows me to split everything possible in the engine into Task objects.This however would require a massive restructuring in the entire framework or to just start from scratch again and I can't do that anymore.Not sure how to get rid of this dissonence, until the threading issue came up, everything was going perfect.Even if I do somehow recode everything again, another dissonance would just come up eventualy.How do you guys deal with this?Say you coded something really hard, but it turns out to be offsetted from the original architecture you had in mind, do you start over from scratch or what?Any input would be appreciated.


Share this post

Link to post
Share on other sites
Canonical answer to almost the same question.

There is no perfect design, the grass will always be greener. There will always be some new sexy way to do it, if you haven't heard of it yet it is approaching the horizon. And just because it is new and sexy doesn't mean that it is better at everything, there will be a trade-off.

It sounds like you might be designing in a vacuum. Write the games, not engines. When you're writing a game, whether the engine has a "god-like threading system" with "Task objects" is less important than whether you can actually achieve what you need within the current constraints that your engine has (there will always be constraints). Concrete goals with obvious milestones cut down the tendency to over-engineer and to over-think some of these things.

If your goal is to have the sexiest, cutting edgiest engine around, you'll have to accept that this is a moving target.

The main thing to realise is that the engine you haven't written yet will also be flawed and irritating, as is the case with all software that actually exists as opposed to imaginary software in your head. You don't imagine the areas that your architecture makes more difficult, you don't imagine the performance problems, you certain don't imagine all the bugs. If you can accept this, you'll find the willpower to resist this temptation comes easier. Edited by rip-off

Share this post

Link to post
Share on other sites

50k lines just to see the engine does not work?

I believe you should slow down and write less better code instead. I think I am at about 90k for my system. It has been rewritten only once.

Also, I don't know why you people care about performance optimization before having something that works. Gamedev is full of smart people, I cannot thank them enough for their technological insights. But some of them do a disservice to the community by believing state of the art is something we should have at all costs. It's not.

Thanks god the times have changed and now most of the community is geared towards a "make it work first" attitude.


So, you have this feeling your system does not work.

My suggestion is: don't care about that.

Here's a list of things that don't work in mine:

  • Memory management is ankward at best.
  • Scripting is actually so flexible it shoot me in the foot several times.
  • The material system is nowhere as flexible as intended, albeit already more complex than I want it to be.
  • When I roam those forums, I see every newbie with super-fancy shaders and multithreading I ask myself: where did all my effort go?
  • It actually doesn't meet my performance target on 1st gen atom.

I don't really care about those things because the game works. Sort of.

Things I really care about are the show stoppers such as having a lighting subsystem that makes me want to run away screaming with its inflexibility. And most of all,

this new import filter which should have been out in January.

Those are the things which you should care. Feeling is a thing, but being sure of a problem is another. 


Share this post

Link to post
Share on other sites
maybe good, maybe bad, is when one is left to realize that, actually, 50kloc actually is pretty small for a codebase...

to really be able to do a lot of stuff, typically people will be looking at codebases a fair bit larger than this.

yes, "elegant" and "perfect" aren't really achievable goals sometimes.
"basically works" is much more reachable, as well as trying to keep options open and avoiding boxing oneself into a corner (though: also try to avoid premature generalization).

sometimes, what works is basically to throw out any sort of planning or up-front-design design, and instead just throw something together and fiddle with it (in an experimental sense), and see if or how well it might work, ... (then, depending on initial results, a person might decide whether to invest more time/effort into developing the idea further).

a large amount of what one does may turn out to suck, but at least if they find out early that it sucks, it can be a sort of damage control (vs spending a lot of time/effort implementing something only then to find out that it sucks...).

and maybe sometimes just "go with the flow" or "listen to what the code seems to be saying" (not really sure how to better describe it, just that sometimes it seems almost like code has its own "voice" and its own "will", but it expresses itself very indirectly, more like a sort of general sensation...).

well, and the power of making things up as one goes along.


Share this post

Link to post
Share on other sites

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
Sign in to follow this  
Followers 0