Design patterns in Game Development: religion or tool?

It's a balancing act. Stuff needs to be done well enough that it does a decent job of solving whatever it's meant to solve, without striving so long to be "perfect" that the thing is never finished - because then it also never solves the problem!

The point is that a practically alright (and built) solution is better than a theoretically perfect (and still coming soon) one, because you can't render an image with a theory.

 

Hence the title and the initial post of my thread. I'm glad that everyone is on the same page LOL.

I have a very thick skin, you need more to do that. Besides, you forgot the lemon slice

 

They aren't, a lot of them are on page one and now we're on page two. Welcome to the new era.

 

Damn, we will need the Lithium to fix that. I'll start a movement to get it back. You're welcome.

 

Absolutely, also I'm the first one to point out when someone is overdesigning. For example when I started my new assignment at my current day job customer some 3 years ago they had a crazy layer structure often just passing data through some layer without doing nothing to the data in that layer. Layer architecture is a thing of the past. On my initiative we rewrote to CQRS so that queries actually did their stuff most of the time directly in queryhandler.

 

BURN THE HERETIC!

 

Yes. But he didn't have to invent it.

 

Anyone who thinks that design patterns are god's gift to programmers hasn't played around with MVC. Jeezus, that is one horrible design pattern, particularly the way that Microsoft has implemented it.

It's a great example as to why cut'n'paste is sometimes still a quicker way to get things done.

Maintenance is one thing. But what's the point if you have to trawl through several files to find the one that needs modifying?

 

Try having your entire application in one file and see what it gets you

 

There is this concept, you know, how they call it, middle ground? Programming isn't black or white, it's 50 shades of gray (and I always wanted to write that sentence down...).

 

Seperating view from logic isnt hardly extreme though. We do it already with monobehaviours, more so with ECS

edit: I'm not that fond of the MVC pattern either btw, like the MVVM pattern better

 

No, but sticking to 100% (literally) to a pattern or writing everything in one file are two extremes.

I personally usually do something MVVM-like as well. The only difference is I drop the patter in any case it creates interface classes, not useful abstraction or other maintenance and/or performance hindering garbage. And since I haven't started today I always do that, so I always know where is what.

I don't do that in my day job though, too many others should be able to read my code and since it's an enterprise application (actually more than one, but it's not important), does not matter, it's more important that if I fell out of an airplane some fresh, random college graduate can take over my code.

Which is not true to my hobby projects.

 

I skimmed the thread, but another case of where patterns can be useful is if you're trying to run a team of coders.

Since coders tend to be highly individualistic, it can be like herding cats. If the project is to have any hopes of being readable and/or maintainable when it's time to ship, the team needs to agree to coding conventions, principles, and patterns to keep everyone on the same page. When you account for possible turnovers with coders leaving mid project, then their work needs to be picked up by someone new. It's a lot faster to hit the ground running with unfamiliar code if it has some sort of a structure behind it.

To some people, I suppose this could be seen as blindly sticking to a pattern for the sake of sticking to the pattern. Of course people are encouraged to speak up against the pattern if they feel it's hurting the project, and to come up with better alternatives. However those alternatives still need to satisfy the original requirement: Team cohesiveness and maintainable code in the end.

Or put another way: I really really really don't enjoy trying to untangle someone's spaghetti code to fix a bug only to find I just created 10 more bugs because the code is just that horrible.

 

Minecraft was a hobby project once. This is actually very important, if you believe in your project maintain it as it was a big team, one day it might be.

Also spaghetti code becomes unmaintainable for small teams too pretty quick, depends on the scope offcourse. But scopes can grow too.

We are very agile even at game design we have changed alot of core mechanics on the request from the community, something that could be very costly or impossible in a carbonara project

 

This ignores the possibility that treating it as such could prevent it from getting the chance to grow.

A finished project with functional code and design is far more valuable than an unfinished one that will theoretically be better in the future...

True. Heck, spaghetti code can become unmaintainable in a matter of days for a solo developer!

But there's a huge gap between choosing not to implement patterns strictly by the book and "spaghetti code".

 

Good design does not prevent you from shipping its the opposite. It even means you will ship earlier because less problems down the road

 

Sure, but "good design" does not mean "dogmatically adhering to every rule or best practices guide". That's what the thread is about in general.

More specifically to the quoted section, it certainly does not mean approaching the implementation of Space Invaders as if it were GTA V. I've had projects fail to meet simple objectives in the past because of insistence that we must plan to meet mammoth objectives in the future. There is nothing wrong with taking your project's scope into account when planning your implementation. In fact, that is something you absolutely should do, lest you end up over-engineering to account for cases that aren't even in your scope... in case they end up being in scope later.

This comes to mind.

 

Some were invented, mostly as specially OOP ways of doing something old. "State" uses sub-classing and virtual functions as much as possible to run a state machine. "Decorator" and "Visitor" are similar - OOP versions of old tricks. Compound and Bridge were invented as ways to solve problems with strict old-style OOP.

If you go through the list, only a few are common names. For examples, the Design Pattern name for Tree is "Composite". A Manager is officially called a "Mediator" (sort of). Then several aren't very descriptive: Observer describes a problem, but not the solution; DI has several definitions; "Builder" is a general term for any multi-step creation process.

Even Factory is funny. Anyone seeing Cat c=cs.spawnCat(); would understand you're creating cat subclasses with a subclass of a plug-in spawner. Knowing that's called Factory doesn't communicate any more. And "Factory" and "Abstract Factory" blur together (almost everything is technically an Abstract Factory).

Design Patterns had the _goal_ of a common vocabulary, but you have to dig into the details to see if they really do.

 

Sure, but that's not what it's for. If you've already implemented the solution then knowing what other people call it isn't going to tell you anything new.

The idea is that if you haven't found or picked a solution yet, someone can say "Have you thought of using the Factory pattern?" rather than "Have you thought of..." followed by a description of what a factory is and how it works.

 

The following passes of the salt will be very swift, and pretty soon those 20 minutes will be regained and after that any future salt passing will be pure win.

But to relate to the thread title, no I do not think patterns and practices are religion, good design and architecture is. Patterns are just a tool to achieve that.

 

Programmers solve problems in the environment or domain they are working in. If bailing wire, duct tape and a shot of ether get"s the engine running like a hot rod and/or solves the problem then that is the ticket. Coders follow language factory specs and tend to drag the problem into their domain and apply their design pattern paradigm. In this case coders act like C# is the runtime language when it is actually a scripting language. Ergo the way this engine uses C# is not necessarily MSDN factory specs and the quirks and variances should be taken into account and approach the engine as though it is a fine tuned hot rod engine with lots of after market bolt on parts and the whole engine config should be considered when solving problems in its domain.

 

This line of thinking is an excellent example of over engineering. A major driver of projects going way over budget on time and money.

If every single bit of a project is built to handle far more than it needs to that multiplies the cost of a project significantly. Sure some of it maybe can be reused in future projects. But often there isn't a future project because the first one fails in that it is never completed. Funding runs out. Deadline expires & project is canceled.

A person can approach things this way if doing development completely for fun but it has killed many projects in a business environment where someone else is paying for all of this work that is not actually needed for what they are buying... along with tarnishing the image of and sometimes even killing the business itself.

 

Maybe but the only reason for that is because most projects has a too high ratio of noobs vs Kings. I always design my solutions and I always deliver before schedule and are always faster on delivering features than the others on the team.

 

I think you're imagining how you'd like it to work - ideally there should be several Design Patterns for a problem, which fully encompass every good way to do it, with Factory as one option. But for real, Factory is the only pattern for what it does (spawning 2+ types which need be in-synch, for example a wall segment and doors that fit into it).

It says to define an interface with makeWall and makeDoor, then to make a subclass for each wall/door pair that work together. That's old-style full-on OOP. In Unity we'd just make one ScriptableObject class with prefab links for wall and door, making an instance for each pair. In other words, if you have the "in-synch" problem, the one Design Pattern for it is weird, and the other ways we'd do it aren't design patterns.

 

Fair enough. IF a person is truly a highly experienced highly skilled developer compared to the bulk of developers then yes I don't doubt they can do this and still be faster. Personally I've been a developer for a long time and went from embracing all of the formal patterns and best practices to questioning them (more the rigidness and examples given than the actual concepts & goals which like I said earlier and @Owen-Reynolds just covered have been around for ages) to finally just throwing out the bulk of it. I approach things with design and the concepts in mind but not rigidly following everything ("looks like I need to use injection here", "this must implement so-and-so pattern", this could possibly extremely unlikely but possibly be reused so I should make this a super generic thing", "oh no! I just created a dependency by directly referencing so and so!").

I believe that for you it is the case where compared to the people you have worked with you are able to strictly follow all of these things to the letter and still complete things as fast or possibly even faster. I'm just saying you have to realize if this is true then you are the exception and many others far less experienced who are still struggling to even know when to use a pattern or not will quite likely end up with spaghetti by trying to follow the same things you are recommending. And there are also people who are experienced who look for the simplest way to completion keeping the concepts and same goals in mind but not rigidly following all of the formal approaches.

 

Also in a project with a high ratio of juniors it's even more important with good design (because good design and architecture helps juniors write less carbonara code), sadly I know that many projects have zero experienced designers and the juniors get to design. I have been called in a few times over the years to save such projects and it ain't pretty.

A good aritechture helps the developers in their daily work, that can never be a bad thing for productivity.

For example I was a arcitecht at a major Swedish bank, we had alot of backend events being fired on our backend bus and picked up by the web application and forward to the clients using signalr. Alot of similar and duplicated code. I wrote a API that completly abstracted signalr and on the client you just subscribed to the backend bus event. The Devs were thrilled. That's how arcitehctue should be, not 18 layers just because.

 

It sounds like you aren't forcing complexity into everything as much as I had the impression from your posts. Completely agree layers sure sometimes they are beneficial but overall this is one of the things I dislike about how people engineer things with the patterns. They often end up with code at the top that goes to some lower layer that does something and then goes to another layer and another layer ultimately to some super generic piece of code that has absolutely no meaning in and of itself. This kind of thing just takes a problem with an often simple straightforward solution and adds unnecessary complexity to it forcing developers to learn a broad range of the codebase just to understand how one little piece works.

 

Layer programming is obsolete. It hasn't been used my knowledable people for years. And you don't abstract for the sake of abstraction you do it for the benefits down the road.

Plus game domain arcitechts have a pretty easy job, their domain is not abstract lika that of the corporate business arcitecht. It can be really challenging coming up with good agregate roots and domain entities in a business domain but pretty trivial in a game. For example in my VR shooter a fireselector is a fireselector component, the trigger a trigger component, the hammer a hammer component and so on, it's very often 1 to 1 to the real world.

 

I agree with you I think the bolded part is the point where myself and some others differ.

It's usually not truly abstracting for benefits down the road; it's often abstracting for perceived possible benefits down the road that may or may not ever come about. And if there is a never a need for those benefits then the work done early was a waste of time.

Anyway you are making great progress and this stuff has people split up into so many different "camps" it is a bit insane. As long as people are getting stuff down efficiently then I'd say stick with what they are doing no matter what it is. If and when they run into an issue then definitely look into refactoring and making use of design patterns and general abstraction etc to see if it will help. Adopt what they need as they need it. But mainly have fun and get stuff done.

 

If you abstract it for perceived value you are a junior arcitecht not a senior one a seasoned arcitecht has a six sense for these things, sometimes I don't even reflect over it. "Nice that I abstracted the explosion logic into a component for that hand grenade, now I can use it for my C4".

Edit: and even if I didn't extracted the relevant code to a component it would have been designed in a way it would have been easy to abstract it later.

Edit: btw to a degree I don't think you can learn this, you either have it or you don't

 

Well not everyone knows how to use their powers of precognition. Lol Definitely as a person gains experience they become better at identifying which things are most likely to be subject to change in the future and can do a better job of focusing on handling those things from the beginning and can refactor as the need arises to handle others. Anyway it's working for you. A good motto if it ain't broken don't fix it.

 

I think the state machine is an example of a pattern I use where it isn't strictly needed. For example, I use it for the application's overall state (Start menu, pause menu, play mode, etc.) where a bunch of if/else probably could've done the job.

Yet, I use state machines because:

a) It's pretty lightweight.
b) I've used them so often they're now intuitive and can create a new setup in minutes.
c) Don't have to worry about extensibility because I know it's already built-in, and I know exactly what I need to do should I reach and cross that bridge.
d) I've seen what happens when you don't use a state machine and you're asked to either add/change/or update a transition of sorts.
e) They can more easily be nested. Nested if/elses go out of control pretty quickly.
f) Enforces cleaner code. States are naturally more modular.

Do I sit down and think through all this each time I work on a new thing? No. I just stick a state machine in which I've used a million times over and move on. However, all this may be new to newbies and they may wonder "Huh? Why not just do if/else or a switch statement instead?"

I think that as you gain experience over the years, you may fall into the pattern (heh) of using patterns without even thinking about it.

 

The more common problem is guessing wrong. Say version 1 has no crafting system, but you wisely did extra work to be ready. Then the crafting system turns out to be very different than you thought, and that prep was wasted.

Struossup mentions this in his old C++ book, and it's also what "You're not going to need it" refers to. I've personally done it plenty. For one mini-game I might use a utility class, tweaked with a 5-minute hack on my end. Later another mini-game needs to same thing. "Twice is a pattern" I stupidly think. I'd be a fool not to take 6 hours expanding the utility to have that general-case option. But I almost never need that option again - cutting and pasting the old hack to the new mini-game would have been much better. In fact, I often rip it out of the 2nd mini-game after just a little testing.

Many Design Patterns are about planning for future expansion, so can have that "whoops! Guessed wrong and all this is wasted" problem.

 

Yeah I used to be an adventurer like you... erh, I used to did the same thing, tried to predict if the project more likely grow a certain way or not and then I accepted my current day job where they thought me reluctantly that it is bad. If the current code does not need something, you should not put in there. There is no code commented out, there is no useless "we may need this" abstractions. Just the bare minimum to do the task. And when you need something, you put in there.
With that said, it's a giant code base, so it could go out of control real quick otherwise.

 

Yeah I agree. To me it is same thing though. Whether you took the time to just "implement for future" and didn't need it at all or ended up needing it a completely different way. Both happen.

I try to plan and cover things to a degree but mainly I just am not hung up about tearing out huge amounts of code and refactoring it IF and WHEN the need arises. It is often just not nearly the bjg deal as people make it out to be.

I definitely agree with you. And is a big reason why I don't think trying to plan and code for everything up front is good. People seem to hate change and want to try to plan for every possible thing. In my experience the nature of products whether it is business at my job or games for personal... the nature is always to change in some way over time. Change in ways never known at beginning rhe idea could only come from seeing the project at a later state of some % of completion. So I just embrace change. I expect it. Refactor as needed along the way.

 

But note that state machines are _not_ a Design Pattern. The "State" Design Pattern is a particular way to make them: each state should be a hand-written subclass of the State Interface. To change states your subclass creates a new instance of that other subclass, replacing yourself with it (you have a back-pointer).

 

I agree with you premature design is as dumb as premature optimization. And refector is really great, we do continues refactoring both at the game and our day jobs. Though some things will be hard, costly or even impossible to refactor at a later time.
For example we really made sure our core architecture was really solid, did a little video here easier to show. Imagine refactor something like this if you didnt make it from the start

 

OK, that's not really important though. The point is using a certain architecture/structure where it may not be necessary and can leave others scratching their heads. I've given one scenario of how and why that can happen.

 

You're fundamentally missing the point.

The person asking for salt does not have any salt, and now their meal is cold! This is an utter failure. While the engineer is sitting there feeling groovy about their showy solution the world has kept on moving around them and the problem in question is no longer relevant.

Not only has the short term objective been failed, there are now flow-on effects damaging things elsewhere. If this were a business objective being failed then this has an impact on your bottom dollar. Worse, in this case the value of the long term objective being chased is questionable at best... which I won't go further into as it's worth several threads of its own.

Lets say for example that I asked an engineer at Google for a lift to the airport. They respond by starting the self-driving car project. Years have passed and I have long since missed my flight, regardless of the value of the thing that they built.

Being a good engineer isn't about showing of how much of a "King" you are. It's about getting problems solved. Problems often come with a time constraint, so recognising the value of short term solutions vs. long term ones is a really important skill. And, as I've said earlier, I've had projects fail because managers insisted on chasing long term mammoths instead of getting practical.

Also... this is a game dev forum, so lets talk game design for a moment. As @Owen-Reynolds points out, you often don't know in advance the details of what you actually need. This isn't because of code design, it's because of game design. With that in mind, on top of judgement calls about how to best balance short and long term goals, there are also judgement calls about how likely a particular thing is to change. If something won't change then by all means, put in the effort to reduce work later. But that's wasted effort if you end up changing the system, or dropping it, because the game's design changed. And that's not even getting into the psychological impacts on the design (eg: sticking to an inferior design because you don't want to throw out the shiny code you made).

I'm describing how it has worked for me, and how I was taught to use them. I think we're looking at things from different levels of abstraction, or different perspectives.

 

The thread mutated from Design Patterns, which are often an over-design, to the general topic of over-design, which is "making too-complicated frameworks too soon." So your comment fits right in as "but what's the definition of too-complicated"? If everyone on the project is good at a state machine framework, using if for 4 stages doesn't seem overly complicated.

But the title of the thread is still "Design Patterns". I wanted to be clear, for future readers, that liking State Machines has nothing to do with liking Design Patterns.

 

You live in the common missunderstanding that good design will make the project overshoot it's release which is not most often true good design will make things easier for the developers making them release before schedule.

Even if it did mean it would overshoot the released date I would prefer good design, I have played too much buggy crap released too early

Edit: take my video above as example, the core aeitecthure took a month at that time we didn't have a single item implemented, but once the core design was there it was very easy to create items of very different types because we had the support of a good framework.

 

No, I don't. That's wrong on two fronts, both already covered.

• If it is the cause of missing a deadline then it's not "good design", because you have failed to take constraints into account.
• I agree that "good design" is the best way to completing projects on time. I simply disagree with you about what "good design" is.

It seems to me like the root of both of the above is that I consider time to be a resource and/or constraint like any other, and you don't. I've also worked on projects where time isn't a concern and I agree, in that scenario, that spending extra time to get stuff "right" is awesome. But those circumstances are luxuries.

So I've got no salt, my dinner is cold, I've missed my flight... the project has slipped and it's costing your boss (or you) money... but hey, the solutions that failed to solve those problems are technically superior, so who cares, right?

 

Well, the analogy the other way is you got no salt because the guy delivering it it slipped on a banana peel.
You still fail to understand that good design will help you meet the goals. If it does not help you the developers meet the goals, its BAD design. I cant help if the majority of developers write bad code. I write king code and deliver beautiful maintainable code on time, that helps my developers (Or my code monkeys as I call them) in their daily job to be more productive.

edit. Btw, you cant choose between having design or not. A software always have design, its either good or bad or somewhere between.

 

And yet you advocate for a solution that does not meet the goal.

 

No I dont, never did. You just use a silly analogy that has no anchor in the life of real IT projects. No feature needs to be delivered real time like salt to a restaurant guest

 

You argued that it's ok to pass someone salt more than 20 minutes late because you would gain the time back later.

You're right that it's a silly contrived analogy, but the core point that time needs to be considered is absolutely valid. Project deadlines can't be ignored because you can deliver something better later.

Edit: This is getting sidetracked and repetitive. I'm out.

 

Yeah sure. But it wouldnt take me 20 minutes to come up with the most optimum way to deliver the salt. Good design will always triumph over bad design. If you think otherwise you are fooling yourself.

I've been the architect in over 20 large team efforts over the last 18 years since I went professionell and countless more as a hobbyist before that. All delivered on time.

 

All I see of your game design is a hand and several pistols and a ghawd awfully complex system for trigger pulling and some sparsely decorated terrain..in like a year or more. Perhaps you would like to share the deadline for release. This would allow us an honest assessment of your actual capability to drop the king code routine and actually get something done.

 

We work full time jobs. We dont have a deadline.

 

That trigger finger IK drives not only trigger finger, it also trigger any kind of finger interaction since its dynamic and well designed.

Like thumb on hammer

Or ejector

Or the finger on fire selector, etc, etc. Plus since its IK driven it works when the rest of the hand chanes. For example when transationing from single handed to dual grip