What's your take on Software Complexity?

All software grows in complexity as it matures and new features are added. The question is how does the increased complexity impact the development of new features?

Does complexity add to the Cost/Time of development?


Article on the subject from a ten year software engineer at Microsoft

What is your experience of complexity and game development (graphs optional)?

 

It shouldn't if you are doing OOP properly Sure if you are building a game world it is like the matrix, a simulation for the clouds for the sun, for the grass and the trees... all of these simulations tied together into a controller to manage the time of day.... but each individual simuation should not "complicate" the next, only add to it. That is the beauty of OOP.

 

Oh it most definitly increases in cost when you need more work done, the more simuations you want, the more time it takes to test, to code and to optimize.

 

Does simplicity add to the cost/time of development?

The answer to both is "yes." How can this be, and what does it mean?

 

My experience is comment the hell out of your code. And design a layout and flow chart ahead of time. Understand what your goal is and have a plan to achive it. Your plan may get altered as you find the original concept doesn't work or you formulate a better approach, so I keep backups of all major revisions and lots of notes.

 

It's all relative really. On the one hand, very few developers are really developing truly complex games. They ones that are will face those issues, and have to make the economic choice as to whether the additional costs associated with the complexity actually improves their game in way that justifies the extra cost. That is a design choice, and could go either way.

On the other hand, a lot of new developers perceive lack of knowledge as complexity. You see it all the time with saving data or inventory systems or whatever. Something that isn't actually complex, but seems that way due their current level. Then the choice becomes about investing in your own knowledge or not. The costs issue then is about where you intend to go with game development in general.

 

You arent kidding ... Im basically trying to build the "matrix" right now lol.. tessellated terrain, directx grass.. day night cycle.. sometimes issues arise that take a mind boggling amount of time to figure out depending on the experience level of the developer. The more complex it becomes as far as the number of systems, the more time consuming it can be to resolve issues when systems break others. I am not a professional game developer ("yet") and sometimes things take me sometime to figure out when I get stuck.. the forum is a big help.

I am a professional web developer however and the principle is the same.

 

Most games are somewhat more than skins on databases.

 

I don't think people should be allowed to use the word 'complexity' anymore.

If Eskimos need two dozen words to identify the different kinds of snow, programmers need two dozen words to identify the different kinds of complexity. Really.

The only thing that's certain @Arowx's image is wrong. Whatever it is, it's not logarithmic, it's exponential as ****.

 

This. I would even go further and say, that with very rare exceptions, ALL games are just that.

I have worked with a small handful of excellent game designers, who after paper prototypes, built their games out in a playable spreadsheet. We started doing this later for features as well. It's brilliant, and easy to test, play and then translate to actually building it out.

 

They have three.

Literally nobody has said this curve is logarithmic. It has only been described in the initial article as "convex."

That's literally the opposite of what I said.

 

Fair enough about the eskimo thing - I will rephrase, "If the Sami have 300 words for snow, programmers need at least 20 for complexity!"

The image I was referring to is that big image in the first post, the one with the chart of functionality and cost... the chart that's logarithmic... the only image in this thread.

PS: on the eskimo thing, saying 3 definitively is a dramatic oversimplification, the way root words work in those languages is very different than how we think of them. You really cannot compare their idea of a root word to ours. good source

 

Ah, I didn't read it in context of the quote. In that case, I disagree. . All games at the core are shifting values and doing calculations against a dataset. The interaction on top of that (fps,rts,puzzle,etc) is an abstraction of that data. If the core math doesn't work, the interface can't save it.

 

Got to agree with zombiegorilla here. The deeper I get into gamedev the more it reflects my experiences working with datasets.

 

No, it's convex. Without knowing the scale of the axes, you can't actually tell whether it's logarithmic.

You seem to have this perverse inclination to oversimplify things until you've erased all the meaningful distinctions. If you can't tell games and web applications apart, what kind of productive discussion can you have about games? You'll just end up arguing about whether Trello boards are actually deathmatches.

 

I've never understood this particular complaint about English. I can understand plenty of complaints. There's loads of silly stuff going on in our language, like the lack of a gender-neutral pronoun.

But with the way our language works we do not need additional words to mean more-specific variations on one thing. Our language already supports that. If you need to be more specific than "complexity" you can easily specify that you're talking about "time complexity" or "computational complexity" or "functional complexity" or "compositional complexity" or whatever other type of complexity you can ever think to specify. We don't need extra words to do that.

If someone is describing things too vaguely that's not a problem with English. The communicator just needs more practice at being meaningfully descriptive.

I've never developed a piece of software that's Microsoft sized or that has had a Microsoft life cycle, so my perspective is going to be different to whatever is in that article.

On the topic of complexity, I agree in principle with the general shape graph in the first post about general complexity to time/cost. As a project grows you get increased overheads and certain tasks just take longer because there are more "moving pieces" to account for. There's tools to mitigate all of that, but you'll never get rid of it all entirely.

In my experience, after I reached the point where I thought I was actually alright at software development, the problem has never really been the size of a project. With enough understanding of various approaches and a decently experienced team you can design a solution to a problem, break it into pieces, identify which pieces need further research (if this isn't needed then why are you writing software?) and how to account for the unknowns, and then start piecing stuff together. That's not to say that it's easy or that it'll be perfect, but generally speaking a half-decent team should be able to do that and get good results.

(Edit: To clarify, I'm not saying that project scope doesn't matter as long as a team is competent. I'm saying that it on its own isn't the whole story.)

The real challenge comes from the realities of software development in the real world. The above paragraph basically assumes this fantasy wonderland where software developers are experts in their software's applied domain (that's rarely the case) and the originally designed solution never has to change (hah!). Lets examine each of those.

If you're sitting there thinking "thankfully that doesn't apply to game development"... think again! If you do think that then I don't think you playtest enough. I've never playtested a feature, level or concept without coming away with some set of changes I'd like to make. (Though that doesn't mean I always make them. At some point you need to decide you're close enough and move on, or you'll never complete anything non-trivial.)

 

But he's not erasing the distinction between games and web apps. All he's saying is that they have in common that they're datasets with a fancy UI. That's not claiming that there are no differences.

For starters, I'd expect anyone reading this thread to easily realise that the interactions performed with the dataset, via the UI, vary dramatically.

 

Exactly. Moreover, the application and interaction of the data differs. With a game you have control over some variables with the goal of manipulating others. Like unit production to influence score ultimately. Web apps are largely data storage and retrieval.

 

More importantly, the complete ambiguity of the second-person pronoun. When I say "you" do something, do I mean "you-personally" as in you-user-angrypenguin or "you-collectively" as in you-game-developers or "you-generally" as in you-iff-you-do-this?

It's really simple to maliciously misinterpret the message and fly off the handle. Sure, maybe the misinterpretation is unintentional, but trolling is a thing that exists primarily because it's so easy to pretend you aren't doing it on purpose.

One of the things I've found over the years is that you can spot the fumbling of someone who doesn't know what they're doing rather easily. They'll write a completely backwards attempt at solving the problem, and then tack a series of fixes onto the end for what went wrong because they didn't do it right in the first place.

Like someone will try to load a given DLL by name and discover that it doesn't exist on some client machines. Then they'll check around and find a different DLL, and load that one. But sometimes that one doesn't exist. So they write an if() block that looks to see which DLL exists and loads the one they find. But sometimes both of them exist! Now the logic starts to get really complicated, and we're seeing all these detailed checks and conditions to figure out which DLL to load, when we smack headlong into the wall because we run into a machine that doesn't have either of them.

Hopefully, the code eventually makes its way into the hands of someone who knows there's a system call which loads the proper DLL whatever it may be, and replaces the entire convoluted mess with one line of code that never fails.

I can and will end up on either side of that line. Sometimes I'm the guy writing a hundred lines of code because I don't know the system call, and sometimes I'm the guy erasing a hundred lines of code because I do. This is because when I don't know whether a system call exists, it is frequently easier for me to just write it myself than to find the system call. Which is why I read system documentation recreationally: because it's often the only way for me to learn certain functionality exists.

I said games are somewhat more than that. He disagreed.

That most certainly is erasing the distinction.

How is that not what I said? What is the disagreement, exactly?

 

I'm surprised you'd take that stance. I consider ambiguity to be one of the most frequent problems we all deal with in software development. In fact, I really think a huge part of what we do as programmers is a kind of disambiguation (making distinctions between things clear) and the rest of what we do is add detail to vague goals. I think that the reason programmers tend to be so damn argumentative (hat tip @cdarklock) is because we are constantly disambiguating (drawing distinctions between things) while also inferring stuff (filling detail into vague goals) - a recipe for reflexive judgement backed by a tendency to make strong declarative statements.

But back to your direct point, the problem with relying on multiple words used in conjunction is that you have so many cases where one or more is neglected (perhaps implied but not explicitly stated). A good example is this thread "what's your take on software complexity"... perhaps this is an ambiguous question?

Wouldn't it be great if we had a few words that were broadly agreed upon and commonly understood that made some of the distinctions between the different types of complexity clearer?

 

And when we try to be unambiguous, it becomes almost impossible to talk with non-developers. I tend to use the engineering shorthand "iff" for "if and only if," but sometimes people assume it's a typo and go off on some tangent where if that's not true it totally isn't the case.

Well, yeah. I said that. Very precisely. If and only if. But if you're not familiar with the term, you don't know I said it.

Those are the best kind to spark discussion, because the lack of specificity allows multiple interpretations.

However, the discussion doesn't always settle into a productive or meaningful discussion. Sometimes it just turns into squabbling over what the question really is.

 

whatever man, I would happily argue for 5 or so posts about the eskimo thing. As long as I could avoid looking at more code for a couple hours

 

Dude, I'm not criticising. A discussion does not need to be productive or meaningful to be fun.

 

And consider how many pre-defined words the programming languages we use have in order to do that. It varies by language and version, but the numbers are tiny compared to even a simplified English dictionary. For example, in C# there's ~100 keywords. Lets call it 500 for arguments sake, to cover all of the things that aren't words as well - math symbols and such. Compare that number to the ~171 thousand words in the Oxford dictionary... and that's just those considered to be in "current use".

I can't at all see how "more words" is a solution to "some sentences are vague". I for one do not have a vocabulary of 171 thousand words, so adding more in there is unlikely to make me more linguistically capable. On the flip side, I seem to be perfectly competent at being clear, specific and unambiguous with just a few hundred at my disposal. (I don't use all of those regularly, either!)

 

How is making up a new word any better than saying "time complexity" or whatnot?

If you came up with and started using such a word, I'd have to go and learn what it is before I could understand what you're saying, let alone make a useful contribution in response. On the other hand, you and I both already know what "time" and what "complexity" mean, and joining them together also has a fairly clear meaning.

It's precisely as clear as any other similar thread. Software complexity is its own field of study, so the question is just as (un)ambiguous as if I asked "Whats your take on colour theory?" Personally I wouldn't call either question "ambiguous", but I would certainly say they're "broad", potentially to the point of uselessness because neither is particularly useful without further context.

It could be made more specific by asking something like "what's your take on software time complexity?" or "what's your take on software cost estimation with relation to required feature sets?". But if we needed new words to communicate those concepts then all we're doing is making our dictionary bigger - any which way all parties to a conversation need to understand the concept being conveyed, and I'd assume a language scholar could tell us there's many ways to skin that cat.

 

I guess I didn't understand what you are trying to say.

My point (which is what I thought you were saying), is that all games a their core are essentially spreadsheets (or relational databases). Everything else on top of that is just interaction with that core.

--

To the larger topic of complexity, understanding that base concept will reduce complexity. Often newer developers will start building in a more granular area of the game, like building the inventory, or how troops move or whatever. Unanticipated complexity arises building that way. Planning reduces complexity.

 

I'd agree that games have data, but that's not appreciably different than saying data exists. Fundamentally all computer programs are code and data, which amount to verbs and nouns. I don't see how that leads to any meaningful insight on games in particular.

My point about web applications is that they rarely do anything more than provide an attractive interface to SQL queries. You just wrap one up in a stored procedure and hook it to a button with a friendly-seeming label. It's not really an interactive experience; it's just a series of transactions. If you can reduce the desired action to an atomic operation, it can be operated in batch mode.

Does it, necessarily? I mean, if you understand a game to be an interface layered on top of a collection of data, separating the two layers might actually increase complexity.

 

I could point out a variety of web apps that do a lot more than view data. I can point out a lot of computer games that are no more complicated than most web apps. I can point out a huge variety of critically acclaimed web-based apps that are more complicated than your average endless runner. I can point out a few games that are in fact nothing more than SQL interfaces.

You're just making broad, sweeping declarations without any factual basis. A dangerous habit in a field that's so hazily defined in the first place.

 

And I will simply point out the word "most" in what I said.

If you would like to assert that more than half of all games are nothing more than a skin over a database, please, commence your argument.

 

Absolutely it does. Any game is nothing more than a set of values modified over time. The more complex the game, the more values and complexity of the interactions. It's similar to mvc. Take your run of the mill rts, there are tons of values that affect each other and vary over time and state. You put all those values in a spreadsheet (database, etc), you can define and test the model. You can build and play an rts in excel. Building the model first informs the technical architecture, and allows for tuning and testing before actually coding too deeply. For deployment, that can delivered by whatever method fits the need, xml in the client or remotely to allow adjustments live.

You often see new developers jumping and wiring things too quickly without planning. Making static classes for score, using on collision, for example, on an arrow to change the score. The realizing later the DOT or AOE or shields or whatever, and building a ton of special cases to handle those things. Increasing complexity, bugs and challenges to maintainability.

Moreover, by having that separation, adding and manipulating data down the road is no longer something that is addressed in code or inspector, it can be done via cms or whatever in a single location. Doesn't matter if you are talking about an fps, a match 3, infinite runner, rts, rpg or mmo, separating values that impact game play and storing in a seperate, shared location reduces complexity across the board (codebase, maintenance, flexibility, expanability, design and overall usage and development). Adding new functionality becomes less complex as well. It also makes bug hunting and tuning much simpler.

Certainly in practice, nothing is completely perfect, some hacking or shame code could still happen, but that's just life. Still, bolting on crafting late in development to a well separated architecture is much less complex (and time consuming) than hunting through spaghetti code and values strewn all over the place.

 

So could Unity do with a spreadsheet view/prototyping feature?

Or are there other approaches that could be used to handle game complexity in Unity?

 

It does, it parses json and xml. And there are scriptable objects. There are also several assets available for additional needs.
https://www.assetstore.unity3d.com/en/#!/search/page=1/sortby=relevance/query=Spreadsheet
There is no one size fits all solution.

Game complexity / architecture is very case specific, though unity already handles a ton of it by its very nature. And it will continue to improve. But it isn't solveable as it is a moving target. It's a concept, not a feature.

 

Yeah I can definitely see this the more I flesh out my game. And really, the art of balancing the game is all about making sure that the interface is constructed in a way that prevents the player from adjusting one or several of the dataset values in such a way that they become incoherent with the rest of the set.

 

Man, I am really torn on if I should agree or disagree with you.

On one hand, a program will never do anything other than read a bunch of data, apply a few rules on how to transform the data, and spit out some result. Most programs have a couple data feeds in the back. The user is really just another data feed the code needs to read and respond to.

On the other hand, you may not realize the degree of difference there is working on game code compared to more traditional apps. And there are massive differences in many cases.

The biggest differences in my opinion:
1 - There is more data being transformed faster than in any other domain. Games are focused more on write (rather than read) more so than in any domain I've ever seen. By a huge amount.

2 - As a programmer, you have less direct control over the state than in almost any other domain. You have so many rule based systems that take their own state as input (AI, physics, etc). Games that allow more simulation, or allow for many agents tend to be the most extreme examples, but most games still have a far wider breadth than more traditional applications.

In other words, often, the code and the input data is less descriptive of the result than in most domains. Especially so in areas that allow for more simulation.

So yeah - on one hand you're right, games are nothing more than numbers being crunched. But there are real differences between how the numbers in games are crunched compared with most other software.

Worth noting: I've worked in a fairly wide range of very different kinds of software. So I'm not talking out of my ass here.

 

Never said there wasn't any difference. (I actually said specifically said there was a difference in general) I am well aware of the differences in different types of software, having done enterprise software development for years (client, backend and simulation/industrial). I was only describing what constitutes the structure of a typical complex game.

I'm not even sure there is value in comparing "game software" to "all other software", as one is subset of the other other. It would be like discussing the differences between "hatchbacks" and "cars". There are many categories of software that are virtually identical to some types of games (industrial/analytical/data modeling/simulation), and some that have very little in common. And some types of games are virtually identical to non-game type applications (async social games are not much different than social apps). Uber for example is a fairly advanced mmo by any perspective. The last half decade has seen the gamification of many vertical apps, (heck, even wal-mart uses a lot of game-like functionality in their shopping app). And many apps are just an interface to data-stream. The lines are less and less defined.

But since we are talking about games here, my prior comments are all specifically about games, I kicked the not making game habit over a decade ago.

 

This is all true. But we are dealing with generalizations here right? In general, game code is dramatically more focused on changing data than most other domains.

It's not a coincidence that one of the most fundamental tools we use is "lerp" - we use lerp friggin everywhere - everywhere. This happens because games do so much blending and transformation.

Let's take this out of the abstract and into the concrete right.

So in a traditional DB driven app, the vast majority of the data is kept verbatim from the data feed (either imported from something, or user entered). Your "phone number" field is never changed, it just hangs out. It gets either: replaced with a new value, deleted, or maybe assigned to someone else. But it generally just ... is.

Very little of the data in games works like this (at least relative to most other domains), much less of the data fed into a game is 'verbatim' - it's often being blended, or combined, or manipulated. We are always lerping. Always combining. Always trying to get more out of the raw input data by applying other data to it. This is deep in the DNA of games.

From the very bottom of 3d where we combine vertices with triangles, textures, and lighting. All the way through the top, where the player is combining the long range of his sniper rifle, to the tower where he's camping, to shoot at the other player he's fighting against. Or combining different skills and equipment as he levels up his character ("if I combine this whirlwind ability with the crit chance bonus then ....").

In a way, what many games are is the opportunity for the player to work with data that they can combine in interesting and clever ways. The ability to combine and explore is fun. Working in a creative space has many moments that feel like playing a game. The main difference is that playing a games tends to allow you to hit goals much faster and easier. But now and then, when you're really in the zone, writing code, or working on art, making video, those moments can feel the same way that a great game experience feels. Doesn't it?

It just tends to take way more effort and the rewards are less frequent. But there's a similarity there.

Uber is an impressive system for sure. But still, even here, most of the data itself is verbatim. Positioning data, user feedback data, request data. Most of it is just taken from A and assigned to B. It's being mapped from one entity to the other. I imagine that only a tiny fraction of what uber's back end does is transformative. That's not to say that Uber isn't amazing, or huge or complex. But I think it's worth noting the differences in how different systems work with the data.

I guess, more so than any other type of software I've personally worked with, games are much more than the sum of their parts. Everything is always being combined and transformed.

 

It is actually way, way more complex than that. Significantly so, simulation/prediction/ai/ml across multiple live and statistical data streams (both client and backend). And there are many apps in the social sphere that do much more than just read from a database.

But again, I'm not sure why we are discussing comparisons. I was only ever talking about game architecture.

 

You have any links on this? I'd love to read. I have years of background in financial apps that run simulation/prediction/ai. I like built programs that bought and sold stuff without a person telling them what to do, so the idea of some pretty complex business apps isn't foreign to me.

As to comparison - cuz it's interesting no? Maybe it's just me. I love looking at the differences between things. If nothing else, it beats the hell out of arguing about semantics

 

There is tons of articles out there on Uber and some of the others, some is just from living in the Valley, if you work here, by default you know people that work at google/ea/uber/facebook/twitter and apple, it is a requirement of residency I believe. The Walmart ml/ai stuff is personal knowledge, though there may be some info out there.

That's cool, but you initially quoted me, and were seeming to counter an argument I never made. It was a bit confusing. Personally, for me, if it ain't about games, it holds little interest for me. "Not games" is my own personal dark backward and abysm of time.

 

To be fair, you did say something like "games are a skin on a db" and while that's got a lot of truth, I pointed out some of the differences between how really DB centric ('traditional') code works and how it's kinda different from how a lot of game code works. So it was relevant

To come more full circle, I think that one of the main sources of complexity in game code is the fact that different systems really do need to be blended together quite a lot.

For instance, the player sends input to character and runs around, but then the character hits a sharp slope and needs to slide down. We are reading data from the player's controller, but blending it into animation, which is blended into the slope of the hill. Whenever I go from writing code like that to working on game gui, it's always a culture shock, because suddenly I am reading data, sticking it in a label, and presenting buttons. Game GUI feels like more 'traditional' app development. Making it so the player can control the slide downhill is such a different kind of process.

Some of the most 'complex' stuff in game code is like, "ok so we've combed the hill making the guy slide with controller input -- but what happens when the player gets hit in the head with a rock while he's sliding? How should that effect the controls?" and suddenly now we need to blend our damage system into the slide system into the control system into the animation system. We're blending different amounts of all of those things together. Lerp Lerp Lerp.

 

Yes, it is.

Consider a basic clicker, where you click this icon and your score goes up. This is pretty straightforward.

Now imagine that you implement MVC in this. Your model is just a single number: the score. It doesn't know or care about the icon you're clicking, because that's in the view. Then in between them you have a controller, which recognises when you click the cookie, updates the number in the model, then sends the number to the view - which renders the icon and the score on screen.

How has that reduced complexity?

You have to reach a certain critical mass before MVC actually does any good. Before that, it's actually making things worse.

 

Well this gets to the heart of the various design patterns architectural and otherwise. One of the reasons I challenged this stuff the past couple of years. Far too many times I've seen people learn design patterns, get super excited and go on a mission to use them anywhere and everywhere for anything and everything. I hate that. The most important part of design patterns is knowing when to actually use them and when not to. If someone is always using these patterns it leads to classic over engineering.

One thing though... the purpose of these patterns isn't to reduce complexity now... the purpose is to reduce complexity later. Where later may be tomorrow, next month, next year or several years from now. At some point... when the requirements change / scope increases and the software needs to be updated accordingly. Well I suppose one could see it as reducing complexity now in the sense the patterns give a sort of cookie cutter pattern to follow. And quite possibly a lot of people using the patterns the most often may have lacked the knowledge how to actually achieve the goal any other way. So the pattern made it possible for them.

MVC in itself is a good architectural pattern. Let's face it... it is just the same ole thing that has been around for a long time with some proprietary naming conventions and such thrown in. It is the old N-Tier/3-Tier/MultiTier approach enforcing separation of concerns. I don't have a problem with this approach really. I think it lends itself quite well to any kind of software including games. As far as using it in Unity though... umm.... I know there are people who do but it does seem like it would be adding complexity on top of an already complex architecture.

I am actually just starting to get back into Unity again. Well not even really. More like just thinking about it. Previously I had torn it all down and came up with a purely procedural programming approach that actually worked really well. Before that I was trying to use everything I know with Unity. Writing Messaging Systems, object pools, focusing on making a clean architecture in an OOP way relying on interfaces, etc. I wasn't happy with the results of that. It all worked but seemed convoluted.

So now I am at the point of just starting to think... so... how in the hell do I want to approach this? I greatly dislike the collection of loose snippets that make up most Unity projects. Of course, the composition model drives that. But for me there is just a disconnect in the architecture of the majority of projects I have seen. Too much reliance on "magic methods & systems". Way too heavy on the coupling particularly with most projects hardwiring up dependencies in the Editor almost randomly and with little thought no rhyme or reason. What I mean is although it is very simple to do it adds yet another layer of complexity to a project. "Where the hell is this initialized?" Could be in the code someplace. Could be buried out there in the Editor. Anyway this time I need to put some more thought into it up front and try to find a solution.

 

I think there's value in comparing "game software" to "specific variety of non-game software." There's even value in intersecting the two.

For example, is Twitter a game?

But I always get in trouble when I talk about that, because when I say "not really because XYZ," a bunch of people jump up and say "that means this game is not a game" and I say "yes, exactly, it's not a game, even though we call it one." And then we never get anywhere because people are personally offended that I said their favourite game is not a game.

I think there's productive ground there to understand a particular distinction in entertainment software, but for about fifteen years, every time I try to talk about it all it ends up doing is hijacking the thread. I have this notion that if I ever happen to release something that people actually recognise by name and consider somehow revolutionary, I will finally be allowed to talk about it, but I don't see that happening anytime soon.

How do you "level up" on Uber?

When you really dig into it, Uber might look like a game, but it's not. The common perception is that Uber is not a game because it has substantial non-game applications, but so do pretty much all kinds of games.

What makes Uber "not a game" is the lack of any meaningful way to compare one user's progress to another in a way that each can independently agree on who is doing "better."

Let's say I call for an Uber, and so do you. Your car arrives first. Are you better at Uber than I am?

What if you arrive at your destination first? Then are you better?

Even the "better" distinction isn't the real issue. The real issue is that we can't agree on how to play Uber. Uber provides us the tools to play a game, should we decide to invent one, but it is not itself a game.

And this is usually where I start to get in trouble, so I'm going to stop now.

Absolutely! It basically works like this:

If you know your project will be complex enough to benefit from a design pattern, it is better to implement that pattern sooner rather than later.

If you know your project will eventually get so big and complicated that it needs MVC, putting MVC in it now will be easier than the rework you have to do cramming MVC into your initial slapdash approach.

And you can expand that, too. If you know you have a project coming down the pipe which will use MVC, implementing MVC in this current project - which doesn't need it - can give you valuable experience in putting MVC into the early stages of the project that does need ti later.

It's about network effects. If you have two ad hoc pieces you need to knit together, and each of them has n contact points, then you can have as many as n^2 integrations. But if you make a third layer to put in between them, you only have 2n integrations. It's the difference between connecting your monitor with a 15-pin DIN connector, and just having a bunch of bare wires hanging out of the back. Instead of having a boatload of potentially-dangerous configurations, you have exactly one that always works. All you had to do was wire up the plug on one side and the socket on the other.

And that can be valuable in your design. But there's a point where it becomes valuable, and before that point, it's just wasted effort.

 

Very well said. And yes I agree completely. Of course, if we didn't take the time to use MVC (or whatever) from the very beginning then we can make use of the Bridge pattern to decouple and separate things to support easier updates. Possibly use Adapter pattern depending on interfacing with other things, etc.

The thing is though these patterns we know they have value (like you said...) when the time comes. Unity presents a rather unique challenge because it already chose the composition architecture. If we look around the web it is easy to find masses of people who have shared their struggles with trying to create a better architecture. Many different approaches of course as with anything else.

I guess I am wondering if maybe the key is really to just embrace the composition (which I do like and have used many times before Unity but never to the scale or the manner in which Unity does it). I think it is the degree to which the composition is used in Unity that makes it a challenge. It is so easy to knock out very simple stuff like the examples in Learn, etc. But it is also very easy when using that approach to end up with just a complete mess as the example turns into an actual complete albeit tiny game and even more so as the scale of the increases.

I think using MVC in Unity could possibly have some value in managing that complexity later on but at the same time to implement it in Unity would likely create a mess and bunch of overhead (beyond normal) in itself. So I think I might consider approaching it kind of like I did the first time around but favoring composition much more and just tying everything together with Interfaces.

Like that's it... just use Unity as the examples and all beginners do except use Interfaces instead of hardwiring references. Maybe that is the best architecture for a Unity project. I find it interesting that there seems to be no best practice for this. There are many people who suggest their preference as a best practice but seems to not be any one or even two or three approaches that are universally supported as being the best practices. I think the reason for that is due to the overall complexity of the Unity architecture and the underlying composition model.

 

most of the best practices in software are aimed at isolating problems not reducing complexity.

One of the most difficult and expensive phases in software is the period near release, where software goes through a massive set of testing and bug fixing and stuff.

After you clear that period, a guy goes, "I want another button" or wants a few small adjustments. The worst thing that can happen while making those small tweeks is that other functionality breaks. Regression. Especially if that functionality is in a seemingly unrelated part of the system. The cost isn't just fixing this next bug, it's having to do large scale 'battle testing' again, dealing with endless 'whack a mole' on regressions, etc.

Almost all modern 'best practices' are not about reducing complexity really, they're about preventing the above scenario. Things like testing, mvc, more layers of separation, etc. The real pay off for almost all of these techniques is that making a small set of changes or enhancements is far less likely to cause massive problems or regression. Each of the components in a system are highly isolated.

There's a cost though. By isolating and separating to such a degree, you end up making the system really resistant to changes that are more significant. Big changes.

So when a bigger change request comes, it's often a major problem. For example, you spent huge amounts of time building out a ton of tests, and now not only do you need to change the functionality itself, but also tons of the tests which are now testing for the wrong sets of conditions and results. Considering how much time and effort goes into test writing, this can be a huge additional cost for little to no gain. All you did is both take longer to build the initial system, and then take longer to accommodate the change. A significant net loss with no up side.

This is a big part of the reason that sooo many programmers are constantly complaining about changing requirements. They traded away the ability to make large scale changes, for safety when making small scale changes.

At least, that's how I see it. YMMV.

 

Absolutely that is how I see it as well. The design patterns are precisely for this. When change comes how to minimize the impact of making those changes.

 

@frosted you have made what appears to be a fairly large game in Unity (by Indie standards) I'd like to get your view on architecture.

How did you structure everything (overall high level view here) in your game?

Also for some examples of details... I see a lot of games using Tags when processing collisions or at least when gathering info from raycasting, etc. I've used that approach as well but then I switched to using interfaces. I'm curious how you gather details from the game world such as the specific type of enemy, terrain objects, etc. Or maybe you don't even need the information and are filtering it out using the layers or possibly not even considering it at all in the case of terrain scenery.

One thing I've had a very hard time wrapping my head around in Unity is to make a game and not explicitly "read" everything in the gameworld. I am just used to dealing with everything. Like in a platform game or the little sub adventure game I was working on I wanted to know exactly what the player collided with so it could react accordingly or when torpedoes hit the scenery I knew if that terrain was destructible or not and more than that what was attached to the terrain that could be released (plants were blown away spinning around, etc).

 

Agreed. Many of the challenges I face in my projects are not because I don't know what to do, but because I don't know how to do them in a way that works well with Unity.

Unfortunately, getting the answer to that question kind of requires me to find someone who has already answered it.

 

I didn't, and wouldn't say that. I said that at their core, games are a set values that change over time base on user interaction.

 

You level up on uber by ratings (user), and by performance and ratings (driver). The amount of calls you take, your rate of response/rejections, response based on predicted availability, your variance from estimates, your time matching delivery, and so on. Your performance in the metrics affects future assignments and calls, assignment to other services and premium services. It is a very complex system, with deep performance metrics. Performance is adjusted in real time, and affects distribution of calls. On top of that there is much larger range of services available to those who perform higher. While not technically a game, it is an example of gamification and uses the same techniques and metrics. With uber, the drivers are the players, the users are the resources/quests.