Jump to content
  • Advertisement
Sign in to follow this  
Escarab

Software architecture, domain-driven design and gameplay programming

This topic is 2118 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
"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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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
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.

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".

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!