Do you think software engineering is needed by (indie) game programmers?

I have been thinking of something that’s been troubling me recently.

We’re a small gamedev company in the Philippines and we’ve gotten intern applicants from schools offering gamedev and it’s just as we’ve experienced before, I feel like we’d need to spend time training them on things their schools should have taught them already.

Just to give you an idea: They don’t know what a resizable array or hashmap is, they don’t know what design patterns are, etc. Even they told me, they’re generally disappointed with their school experience.

The gamedev industry in my country isn’t much to speak of, so I certainly wanted to take steps in helping improve it.

I was just about to go and make a case to their school about the importance of teaching software engineering for gamedev, then I thought, “Wait, I wonder if indie game programmers out there really actually care about software engineering in the first place?”

Now when I say software engineering, a major part of it is software architecture: how you design organize your classes, which classes talk to which, do you group them into sub-systems, do you modularize? It’s that skill that I feel is important.

Other stuff about soft eng is how to measure feasibility (i.e. “is it worth the trouble to do this?”), being mindful of deadlines (i.e. when to cut corners, and which).

I am not into stuff like UML and lengthy documentation, although that is considered part of soft eng. I prefer Scrum.

For me, soft eng (excluding the bit about lengthy docs) is invaluable when making large complex systems interacting with each other (i.e. the moment you add RPG elements).

I was wondering if other devs really care about that, especially the successful ones. We’re from the Philippines so I don’t know the game dev culture there in the western world, which is why I wanted to ask you guys.

Does it really matter to you?

For example I’ve heard that Binding of Isaac had lots of bugs when it first came out, but hey, it sold well. Edmund concentrated his efforts on the theme the gameplay mechanics, and seems like it paid off that he did that.

I guess one way to look at it is, as long as the game is fun, and lots of people are buying it, the devs can afford to be (varying degrees of) sloppy and just fix the bugs afterwards? I mean, is that something you would impart to students and would-be game developers?

I personally don’t like that idea. But I do wonder how many do it that way.

I’m mainly referring to indies, because indie style development is what I know (mostly working solo, less on proprietary tech just use 3rd party libs/engines, etc.). But non-indies, feel free to share your opinions.

tl;dr just read this post’s title

With Unity I have found myself having to re-learn my development approach as there is no inner loop or main() to work to instead there are a group of self contained components that can have scripts attached with fixed function hooks e.g. Update() / FixedUpdate() / Start() / Awake()

Therefore Unity managed the objects in the game, I just script their interactions.

Why use a re-sizable array when you have an ArrayList or Generic List, a Hashmap when C# uses Dictionaries.

Yes using the correct data structures and design patterns can be a great help, but they can also add layers of complexity that just bog you’re progress down.

IMHO Unity allows a much more iterative and ‘agile’ approach to games development, which is great but also can lead to a lack of design or the requirement to re-factor the design and object structure of the project.

Maybe if the game development courses covered aspects of best practices in game sub-systems and the patterns used therein, this would equip the students with a better understand of software design but also give them a ‘toolkit’ that could be used in multiple projects.

But as very few games are completely new ‘genres’ then surely just a game design / architectural / pattern book or wiki could allow new developers to learn from the best practices in the industry.

Yes! it is absolutely needed.

Being an indie game developer is no excuse to have a crap code-base. Actually, having a poor codebase will only go on to harm you more in the long run; not only will it increase costs by taking longer and being more unstable in general, but you’ll tend to lose help more the worse it gets.

As a programmer by profession, let’s say you interview me, and it’s a pass for you. One of the things I’ve been taught to do if something goes this far is to ask for a code sample, so I know what I’m getting into. If I see an unmaintainable codebase, chances are I’m going to ask some questions, like what problem the poor coding practices are supposed to be solving. If I don’t get a satisfactory answer, I’ll move on. If I get one, I’ll honestly try to work on the code to the best of my ability, because that’s what a professional does…but if I see a pattern of poor code failing to be moderated, chances are I’m going to go somewhere else (this very scenario wound up unfolding at my previous job.)

First, I do suggest taking those students on in internship positions, and taking a few minutes to teach them good coding practices - as the business world is not some classroom that insulates you from consequences, these students need this valuable, valuable experience.

However, I also recommend pushing back on the local learning institutions you have. If your internship candidates are consistently failing to demonstrate knowledge of key concepts, that institution needs to change what it’s doing - and tell them that in no uncertain terms.

For good measure, throw in the first lines of this message: Indie games are no excuse for crap code. Quote me on it, if you like, I’ll stand by it - bad code does no one any good.

If you’re implying we don’t need software engineering because Unity manages the objects already, that’s not what I meant. Say you’re making an RPG, you’d need systems to structure the level-up system, the skills, the inventory, the classes, passive buffs, etc. Do you just put all their functionality in Start/Awake/Update/etc. of your scripts? Would you put an abstract concept like a skill or perk or class in a game object?

My point is I wouldn’t.

When I said resizable array I was indeed referring to generic lists and array lists, same with a hash map. I was referring to data structures in general. It seems they weren’t thought that.

Indeed, but it always depends on the particular situation. Do I leave this value as a constant in the source code? Or something that’s loaded from a config file? The answer is, it depends on the situation at hand. And it’s that wisdom to decide that I think should also be taught.

I’d say it’s equally important to know about the advantage of experimentation and prototyping (we call pre-production), and when you should “formalize”: refactoring and organizing the code (when software architecture comes in; when you’ve finished experimenting and found your own set of best practices for that project).

When I make prototypes, I can afford to be sloppy, cause I’m just experimenting to see if an idea is worth it. Focus on “finding the fun” as they say. And you can’t really anticipate that beforehand in some design doc, so what you do is just… dive in, throw stuff at the wall, and see what sticks.

(Even then, I’ve collected quite a handful of cleanly designed, reusable code from past projects that not everything in the prototype is that sloppy!)

It’s only when us on the team decide to take a prototype further that I take the coding seriously, and put on my software architect hat, so to speak.

My point is I believe there’s a time for both quick-and-dirty and the formal architecturing (is that a word?).

The thing is some people learn best with books (i.e. reading), and I’ve seen some pick it up better when they’re talking to someone who’s explaining it instead.

People who use StrangeIoC/mvc libraries, what are your thoughts?

OK Asvarduil I’m not disagreeing with you here but would like to look at this from a different perspective.

Take design patterns, a set of design blue-prints that let you do more advanced and flexible processes in your games. Once you learn about them you just want to apply them, but they come with a cost in time and complexity, and if overused can make your code harder to debug and manage than much simpler structures.

What I’m saying is that maybe we should view design and architecture through the same lens as optimization, it should be used sparingly and only where the cost in time, effort and debugging of adding complexity is outweighed by the gains in flexibility and extensibilty.

Also weighing the costs and benefits of design patterns only comes experience, but ideally with that experience you will be building up a library of re-usable components that will solve the same problems in different projects.

My caveat to this is that it depends upon the tools you use, for instance if you have used some visual object modelling and development software like Borlands Together, then re-arranging class hierarchies and links can be as trivial as a few mouse moves and a re-name. Then using design patterns can become a trivial process, however this more complex code base still needs to be bug free. :wink:

Maybe what we should be talking about is the Quality of the code base?!

You know what, we’re really both in agreement here. Because all that stuff you’re talking about? That is what software engineering is at its core.

It’s not about getting caught up with design patterns. Every design pattern book I’ve read warns you about that (“hmm gee I wonder what design pattern I should use today??” that’s dumb). It’s not about concentrating too much on planning and documentation (at least in the context of game development).

Weighing the feasibility and cost-effectiveness of one solution over another, that’s software engineering. I would not say it only comes from experience; I do believe having read Code Complete was still a big help for me.

It’s about equal parts fore-sightly planning, and adapting to discovered opportunities and restrictions while coding.

Thats why a lot of game companies/game related look for computer science instead. My role is heavy on game making however someone from a gamedev school probably wouldn’t of even been considered for the role.

It’s becoming less important for mainstream programmers to understand hash tables or resizable arrays. It’s more important to be able to script logic and behaviour for the vast majority of game developers entering the industry today.

You’ll find that the specialised code will always require expensive and experienced programmers. These guys make stuff like unity, engines and so on. But what about a door and a character? This is a far more common behaviour for any level in a game. Stuff like that we’re seeing is being offloaded to lua, or blueprint or whatever other creative-level programming tool there is.

So I’m not sure about the whole intern thing here. It’s like comparing a car engineer with a professional driver. The driver just needs to be really good at driving and have a basic knowledge of engineering to function at his best, while the engine designer needs to understand every micro concept. Both can drive, but one is more common than the other.

As I get older I want to stop making engines and start driving cars.

In answer to the OP’s base question… it depends entirely on the complexity of the game you want to make.

At its simplest, Arowx nailed it: "Unity manage the objects in the game, I just script their interactions." As long as your game can be described in terms of simple interactions then you’ll probably get away with little more than Programming 101 level stuff.
Once your interactions start getting complex then some software design skill certainly wouldn’t go astray. Once performance starts to matter understanding how CPUs, memory access, and data structures work wouldn’t go astray. And so on.
Note that plenty of people around here don’t get even as far as Programming 101 and persist in metaphorically “bashing screws with a hammer”, simply because they never learn better approaches and instead try to “scale up” the methods they already know. This typically leads to long, complex code that’s hard to maintain.
Learning programming and learning a set of tools (such as Unity) are related pursuits, but nevertheless they are distinct pursuits. I strongly recommend at least picking up a good C#* book and working through it so you’ve got the basics of programming down alongside your Unity specific learning. It’ll help you a lot.
[quote=“Arowx, post:2, topic: 527322, username:Arowx”]
Yes using the correct data structures and design patterns can be a great help, but they can also add layers of complexity that just bog you’re progress down.
~~[/quote]
~~
This implies to me that you’re not using those tools appropriately. The entire purpose of the tools is to minimise complexity and to keep you moving at a reasonable pace. If they’re getting in your way then I expect that you could use them differently such that they’d help rather than hinder.
Or, possibly, you’re designing on the fly instead of pre-planning a set of coherent systems that work in unison.
To roughly quote Einstein, “Things should be as simple as possible, but no simpler.” When I apply this to software development, what I’m thinking is essentially “What is the least work I can perform to get this task done?” Think about carrying heavy objects. Under what circumstances would you carry them by hand, and under what circumstances would you first fetch a wheelbarrow? How can you apply this to your code?
Under ideal circumstances, any complexity you add to your code will save you greater complexity elsewhere. Ergo, your code will be “as simple as possible, but no simpler”. :wink:
* I say C# purely because it’s the most generally used of Unity’s languages. It doesn’t really matter what language you end up making your game in, as the general principles are applicable to all of them.

First thing, making a game isn’t just: make a door here and a character there and that’s it. We both know that.

I mean, they want to be making games themselves, not just wire the level logic of an already existing game.

Let me put it this way: they can’t even drive properly. The school was supposed to teach them at least that. Not good at driving, and no basic knowledge of engineering to function at their best.

Yes, I don’t expect them to be able to write their own hash table class. But they don’t even know how to use one, or what it is in the first place! They never heard of C# dictionaries, or generic lists, stacks, etc. (they are taught C#)

I don’t make engines; I don’t know how. I’m just a driver too. I just make games. But I know when my code gets messy, it becomes a nightmare to maintain. Which is why I was saying software engineering is important.

I guess… I don’t know. Should I have low expectations? What the hell were their professors doing for those 4 years? (sorry for the rant)

There is definitely some confusion going on here.
“Software engineering” is nothing more than a fancy word for “programming”.
Kind of like how “domestic engineering” is a fancy word for housekeeping.
Do you need a degree in software engineering with a full knowledge of design patterns and design methodologies before you write your first Unity script? of course not. But the more you know about designing (engineering) programs (software), the better you will be at coding. This is in fact a tautology.

Being a highly skilled software engineer has nothing to do with using the fanciest data structures and design patterns known to man.
Being a highly skilled software engineer simply means that for any given programming problem you face, you will be able to figure out a clean, efficient solution. You will want to know design patterns and algorithms so that you don’t reinvent the wheel, but if you use complicated techniques when simple ones would be better, you are a bad engineer.

So asking if software engineering is needed by indie game programmers is like asking if knowing how to write is a required to become an author.

His point is that a novice starting to learn those things will go “when you have a shiny new hammer, suddenly everything looks like a nail”, and I was saying earlier that it doesn’t have to be that way.

Having skimmed more of the OP, I think it’s most likely a case of a school focussing more on sales than on education. Alternatively, it could be a game development course taught by someone who is in fact not an expert themselves. I am biased, but I don’t have a particularly high opinion of “fast-tracked” game development courses. I shan’t jump into why, as I’ve done so plenty elsewhere.

I agree with you, that’s what I’ve been saying in my posts. But why did I ask? It’s about people who could come up with games that still sell without knowing clean efficient solutions in code.

Like I said, take a look at Binding of Isaac. Riddled with crash bugs on launch, but shit, it still made more in its 1st week than a game that I made that doesn’t crash.

And I’m sorry, I’m not familiar with indie culture in the west, so I was asking.

(Software engineering is, should I say, “disciplined” programming, when the word “programming” alone doesn’t connote that, but this is nitpicking on semantics.)

Indeed. And they do that because they know how to use the tools, but don’t understand how to make the decisions about when to use them. Or because they only know one tool, and try and use it everywhere instead of learning about more tools and learning the pros and cons of each and how to make decisions about which to use.

I should have figured people were not reading my wall of text :stuck_out_tongue:

It’s a 4 year college course. I’m not sure if that’s fast-tracked. I’ve met at least one of their faculty and I really think he just wants to help the fledgling game dev industry we have in our country.

Well nevermind then, the answer from you guys is pretty much what I had in mind too. At least this thread is something to show them if they don’t believe me.

I totally see what you’re getting at, but I don’t really agree with it. Any form of engineering is by definition about problem solving. Or, said differently, covers more than just the “build” phase of a project. Programming in and of itself is just giving instructions to a computer, it is strictly the “build” phase. Someone who lays bricks or pavers is not a “civil engineer”.

I’d love to read it, but I’m at work and reading/responding while waiting for other things to happen.

Otherwise I’d give you walls of text right back. :wink:

I think this is one of those things where once you know what you don’t know you’re at least on the right path.

Or maybe that’s just me, but the more I learn the more I realize how screwed up the last thing I did was. In the end though, I got the screwed up code to work, but I would be embarrassed if anyone else saw it.

If you come out of 4 year college focusing on programming and don’t at least have a comprehensive idea of all the basic components that go into software(even if it’s just so you can google them later) I would consider that a ripoff.

Agree that if you were to have two people working together to build software, one who did all the problem solving and algorithm inventing, then wrote detailed psuedocode, then hands the detailed psuedocode off to a less-skilled person whose job was just to transcribe it into actual code… Then you have two programmers, one who is a real engineer and another just a trained monkey.

I hadn’t considered that scenario. Are there really teams that operate this way?

My experience has been that the managers split up the overall job of writing our application into smaller single-person tasks. Each individual programmer/engineer has to analyzer his task, decide on an approach, run feasibility experiments, implement a solution, run the test suite to check for regressions, and send the code out to the group for peer review before checkin. Some of this work is definitely engineering in the sense of figuring out solutions to problems. A lot of time is spent debugging, but the same people do debugging as do engineering.

I’m not the one designing the overall structure of the product, but that’s not engineering anyway, that’s architecture.

Anyway, what good would a programmer be if he can’t do any problem solving?