Hi, long time no post here
My company's latest project is finally ending after 2 years of not so good code. For sure we will deliver it, but I expect to put to practise what I've learned in the past 2 years on our next project, for when I look at the new code I will not be afraid to change it, confused about what it does or just disgusted.
Game Developers been as they are, not very fond of software design or architecture, there is not so many sources directly related to the industry. So I went to our cousins "developers of normal software" for knowledge. After quite a lot of digging(said 2 years), I've come to an approach that I'm ready to commit to and give it a try on our next project.
Extreme Programming supported by domain driven design is the new approach I'm about to try. Letting alone Test Driven Development, very important in order for XP to work properly but I have no idea how to apply it on game code, I want to start a discussion about model driven design in game development, specially in gameplay code.
Domain driven design seems to support XP perfectly, in fact, domain driven desing seems like the "right" way to think about all kinds of software development, all but gameplay code. DDD talks about a lot of good ways to think about problems, use patterns etc, but as the name implies, it's all based on the domain. Your software is modeling some stablished domain, such as banking or accouting, and you draw on the knowledge embedded on that domain, it's logical inner workings, to design a model/code incrementally more supple as you unravels more about the domain you're modeling. Beautiful stuff!
99.9% of software are about modeling some stablished domain, even if abstract. You could apply DDD to, for example, game engine design. The domain of "game engines" talks about assets and asset pipelines, Renderers, Materials, game nodes, scenes and scenegraphs, I can easily see a DDD path on that domain. The domain is there, you evolve the code to model it better, crunching domain knowledge and spitting better desing and code .
Game Play don't have a stablished domain, at least iterative evolving gameplay(the best ones) don't. With DDD you aim at a target through mist, as you gain a deeper understanding of the domain, you get closer to the target, so the mist is less effective at hindering your aim. The game play domain evolves as you code the game, allowing your game designer to test stuff and invent the "game domain" and it's rules.But suddenly it's much more fun if dire rats shoot fireballs, and a gun that can stop time is very fun indeed. Game play domain is a crazy running target in the mist. DDD is not very useful if your domain is so stable as your code is, you can't lean on that kind of domain. Very sad since gamplay code tends to be the messier code.
Sorry about the long post, i've opened the discussions discussing with myself I think. Is DDD really not suit for game play code? If not, what is a better approach then?
What do you think?
Software architecture, domain-driven design and gameplay programming
"Domain Driven Design" is a very vague and trivial term: how could "domain oblivious" design be possibly good? How could previous experience at building similar systems be bad? Unless you bring specific practices to the table, I can only consider "Domain Driven Design" synonymous with "good design".
Trying to "design" gameplay as you would design a game engine is rather wrong, as fun is entirely on the player's side, not in your game: you can only tweak your game until it is good.
Proper game design can direct this tweaking activity (for example, paper drafts of levels to ensure everything is reachable or spreadsheet calculations to find good values for rule parameters); proper project management can reduce the rework effort (for example, if you suspect you might want your dire rats to shoot fireballs at some point of development, you could draw them, from the beginning, with hands and in an appropriate pose to use a magic wand or any weapon); and proper software engineering can make modifications cheaper and less messy (for example, with data-driven architectures that allow content changes without affecting code and with constant refactoring from experimental hacks to reusable and flexible capabilities).
Trying to "design" gameplay as you would design a game engine is rather wrong, as fun is entirely on the player's side, not in your game: you can only tweak your game until it is good.
Proper game design can direct this tweaking activity (for example, paper drafts of levels to ensure everything is reachable or spreadsheet calculations to find good values for rule parameters); proper project management can reduce the rework effort (for example, if you suspect you might want your dire rats to shoot fireballs at some point of development, you could draw them, from the beginning, with hands and in an appropriate pose to use a magic wand or any weapon); and proper software engineering can make modifications cheaper and less messy (for example, with data-driven architectures that allow content changes without affecting code and with constant refactoring from experimental hacks to reusable and flexible capabilities).
Author
DDD is not about using "previous experience at building similar systems", is about using the knowledge embedded in the target domain of your sistem to improve the design of your model, making your desing supple in the context of said domain. Eric Evans should explain better then I can: http://www.infoq.com/presentations/strategic-design-evans
Normal techincal refactoring(design patterns and such) is ok to accomodate requirements changes, not domain changes.
Requirement change: Make your home bank software muti currency stead of US$ only. The domain is still banking.
Domain change: Make your home bank software into a backery stock managemant software. Domain change banking -> backery
As I see it, the process of iterative game design creates a ever changing domain, a moving target(at least till the very end). In my opinion, no cheap techinal refactoring can make my code better as i go under that circunstances. Sure i could rewrite the entire game after the game designer has finished his work and the domain is defined and is sollid, but that would make no sense at all.
Normal techincal refactoring(design patterns and such) is ok to accomodate requirements changes, not domain changes.
Requirement change: Make your home bank software muti currency stead of US$ only. The domain is still banking.
Domain change: Make your home bank software into a backery stock managemant software. Domain change banking -> backery
As I see it, the process of iterative game design creates a ever changing domain, a moving target(at least till the very end). In my opinion, no cheap techinal refactoring can make my code better as i go under that circunstances. Sure i could rewrite the entire game after the game designer has finished his work and the domain is defined and is sollid, but that would make no sense at all.
If you know enough about your domain to make your design "supple", you are by definition applying your experience at designing software for that domain. At best, it is second-hand experience you collected from domain experts while working on that project rather than in previous projects.
DDD is not about using "previous experience at building similar systems", is about using the knowledge embedded in the target domain of your sistem to improve the design of your model, making your desing supple in the context of said domain. Eric Evans should explain better then I can: http://www.infoq.com...ic-design-evans
Learning whatever you need to know about an application domain amounts to collecting requirements; that's why the only potential good that can come from advocating domain-driven design are techniques to collect and organize certain kinds of requirements.
Normal techincal refactoring(design patterns and such) is ok to accomodate requirements changes, not domain changes.
Requirement change: Make your home bank software muti currency stead of US$ only. The domain is still banking.
Domain change: Make your home bank software into a backery stock managemant software. Domain change banking -> backery
[/quote]
Obviously, very little of a home bank software can be reused in a stock management software, and most of that will consist of very basic and domain-agnostic stuff, e.g. UI widgets.
No magic wand can improve this situation, so what's your point?
As I see it, the process of iterative game design creates a ever changing domain, a moving target(at least till the very end). In my opinion, no cheap techinal refactoring can make my code better as i go under that circunstances. Sure i could rewrite the entire game after the game designer has finished his work and the domain is defined and is sollid, but that would make no sense at all.
[/quote]
But your product is an evolving succession of "ever changing" attempts to make a good game, not only the one true version: your design must be good at chasing the moving target (hence obvious techniques like refactoring, testing, investing on diagnostic tools like logging and profiling, keeping things flexible in general, data-driven architectures, aggressive build automation, etc.).
You don't seem to realize that massive iteration is where extreme programming excels, nor that general domain knowledge can only inform basic decisions rather than every little detail, nor that refactoring isn't "cheap" or "technical".
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
