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

1 Like

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?

5 Likes

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.

1 Like

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.

3 Likes

You arent kidding :wink: … 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.

2 Likes

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

4 Likes

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

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

1 Like

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.

1 Like

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?