Is software engineering compatible with making games?

This is one of the hundred of questions that I ask myself many times.

After some mumbling and experience, I came to the understanding that what's really misleading is the equality software engineering == O.O.P. == design patterns.

This is what it appears when reading forums and speaking with peoples around.

That's wrong. Completely wrong.

First of all: software engineering is NOT Object Oriented Programming.

Software engineering is a tool to find solutions to problems.
Object Oriented Programming is one way of solving the problem, but it is another tool.

Second: Object Oriented Programming is NOT design patterns.

The real trouble here is that people is lazy and many times not focused / precise enough to describe the problem.

A PATTERN is a SOLUTION to a known PROBLEM.

So, what's a problem?

The word problem cames from greek, and means "What cames BEFORE a project".

The real error here is the definition of the problem.

DEFINING A BAD PROBLEM WILL LEAD TO BAD SOLUTIONS.

That can be sound silly or foggy, but really is a common error I see around (and also in myself).

So going back to the equality, patterns are solutions to problem.
Our mind, that always needs to categorize and label stuff to organize data, works with associations: when we find something similar to what we already know, under a certain percentage of similarity, we assume that is equal.

This is normal and common: you know the experiment that if we read words with only the initial

and fnail wrdos we can understand them the same.

We already (normally) encounter that word, so we can understand which one is.

Using patterns is not the only way of using OOP: they are completely different domains.

Software engineering is an analysis and design mindset.

What we're really missing is to DESCRIBE CORRECTLY PROBLEMS.

Also, we have not so many patterns that are usable for the gaming industry.

That's for two reasons.

1) There are not so many software engineers/architect that have enough time to study and design a so large software like a game and an engine, with the production constraints we have.

2) Believing in this inequality, a lot of peoples believes that software engineering is not for realtime applications.

But that's hope.

Even in a strange way, some new patterns/way of programming is coming out.

Data Oriented Programming they say.

There are no explicit patterns, written in an academic way, but there are patterns.

In that case, what happened is describing the problem in a correct way.

For example, in a lot of patterns there is no mention of hardware constraints or performances.

Data oriented programming thus is becoming a new way of coding: coding thinking about data and performances.

But data oriented does not exclude object oriented.

They can co-exist!

We must be open-minded: still we need to go one level up, thus being independent of Object or Data oriented paradigms.

We must focus on each problems, and why they're there.

Object oriented programming is born to solve the problem of creating high-maintainable code used by different persons during a long time-span.

Data oriented programming is born to solve the performances issues and platform bindings that

object oriented was leaving behind.

Each problem its own solution.

Need 1000 calls per frame on consoles? Data oriented, cache friendly, multithreaded and no virtuals are the keyword.

Need 1-10 calls per frame? Object oriented is good.

Looking from this angle, the two paradigm CAN and MUST co-exist, because they're not strict and they're really a way of dealing a certain class of problems.