Is a computer game anything other than a very large program?

Edit: The reason I made this topic was the start a discussion about the often understated, nitty gritty details of how games are made. As I said, I feel that I've wasted years that should have been spent learning to code. Nobody ever told me that games are basically no different than any other programs. I thought that some magical program was going to come along and that it would make my game for me, I thought that was what Unity and Unreal Engine were... Nobody ever said this was going to be work. I'm
passionate about telling newbies "Look, it's not fun. But if you're serious, this is what it's going to take..." And I would tell every one of them that you sukrainehould start by learning C because you will have to understand computer memory to ever be a programmer worth a damn. Until you understand computer memory, it's pointless to even try to learn C# because you're going to get so many Null Reference Exceptions you're going to need a therapist. The industry has one common entry path... education system, I get that. But for those of us who grew up poor or came from areas where kids carried more weapons and drugs than school supplies, it would be great to have a sign posted that says, "You must be this competent to ride."

Original:
Here's the thing, I've been circling the task of "making my game" for so many years now and I just haven't been able to get my arms all the way around it. I've started a lot of little projects but then they always tend to bloat and become overly complex and then die on the operating table. Granted, I've spent the most of the last decade focusing on other things (family, my job, etc.) but in the last few months I've buckled down and done a lot of reading and study on the subject of games, programming.

I've gotten to the point where I think I get it.

Games are just very large pieces of software that don't conform to the same rules as other software. Instead of a static interface whereby users manipulate data, you have a moving interface where all data manipulation is done behind the scenes, or is in effect "hidden" from the user so as to allow for the illusion of some simulated world view. Sounds complicated, but its actually simpler when I view it this way.

What I have struggled with is that computer games do not serve a functional purpose and therefore do not follow the whole "everything is a solution to a problem" paradigm. Which sucks, because that's exactly what 100% of all programming languages are designed to do. Solve problems for businesses. Compute. Manipulate data.

It's almost humorous to me, though, to think that every single person who ever built a computer game is basically abusing the computer. We've taken the most sophisticated piece of equipment mankind has ever devised and turned it into a slave for our own amusement.

But I digress, I am specifically considering the large number of games I have seen over the years that never made it to project completion or saw any sort of successful commercial release. I don't think the designers were lazy or anything, but that the common view of game development as being something you just "dive into" and learn as you go is perhaps a bit misguided... its like diving into the construction of a jet fighter. It'll work out, if there's any problems just "wing it"... amiright?

Anyway. I just recently got done learning about the origins of c, where c++ came from, other programming languages and just computer software development in general and I think there's a huge lack of appreciation for how blessed we are to have OOP languages, extension methods, lists and arrays, dictionaries... binary serialization with a few simple lines of code.

I believe I have found the solution to my problem in finally viewing the entire game as just a piece of software and nothing else, at all. No different than any other kind of software (except that it doesn't yield any useful output).

I looked up software layout and found a way of designing a piece of large, confusing software in modules, through a process known as step-wise refinement. Just so happens to be a *perfect* fit for C#, which I'll be using.

I'll accept any thoughts, advice or whatever I'm seeking additional tips as well as I prepare to tackle this beast.

 

Yup, that's actually correct. Thus the scripts you create are generally not based on anything real, and you literally have to make stuff up as you go (Player script, Enemy script, etc).

 

Yes, computer games are exactly "very large programs".

If you don't feel that your game serves a purpose or yields any form of useful output, though, I don't think you're making the right game for you. Sure, the computations performed might not be directly of use, but there's so many other layers to what you're doing.

There's plenty of abstract ways a game can provide value - it can provoke thought, entertain, change perceptions, teach people, be a social medium, etc. etc. Even with all of that aside, though, the vast majority of games I've made fall under the "serious game" category and are primarily and directly about training and learning outcomes. Aside from that I also do a lot of simulation work, which is the same tech as games and also with concrete outcomes.

As above, I think that games can serve a functional purpose. Moving on from that, though, I absolutely see game design, development and programming as 100% "everything is a solution to a problem". Every piece of software I write, including the games, starts as a definition of something I want to achieve - something that can easily be stated as a "problem". The process from there, starting at design and going through to release, can be considered entirely as an iterative cycle of identifying problems and proposing solutions.

Whenever in doubt about anything at any point, one of the first things to do is take a step back and consider "what is the problem that I am trying to solve?" If I can't state the problem then I know immediately that I don't properly understand the task I am performing. And that goes for anything - UI design, programming, game mechanics, level design, character design, story, audio... Everything serves a purpose, and all of the components build towards the greater purpose which is the reason you're making the game - to entertain, to teach, to train, to provoke...

So, a question then: can you give an example of something you've tried to do that's not derived from a problem to be solved?

 

You have to understand the #1 rule for any game (or program). People go to work, and they work using Excel or Microsoft Word. The reason you exist, is to put that behind them. The reason you should make a "game" is to allow people to have fun with the program you are making. I have made 100 programs, only recently have I made games. You have to come to the realization, that the game you are making is not so people have to work. The entire goal of my company, which makes games, is to make the application you start (via windows or android or whatever platform)


FUN@@@@@@@@@@@@@@!!!!!!!!!!!!!!

That's why you exist.

To make programs fun.

You are certainly correct in realizing that a game is just another application. But you have missed the bottomline point. Make it enjoyable for someone to sit down, and enjoy the creativity you are bringing them. Don't make it a ....

.... CHORE.

 

Coming from the olden days, where computer games were things where you had to type in "go west", "take ladder", "go north", "use ladder", it may have been more obvious that computer games are just programs.

It never occurred to me that in these days with modern computer graphics that the difference between say Batman Arkham Asylum and Microsoft Excel would be so stark that only one of them would be considered a "program".

But then again, is a game just a long program? Not really. It is also art, creative writing, music, acting, imagination, animation, directing, and many other things that are not found in a typical office spreadsheet program.

So is a game just a long program? Technically, yes, you can express a whole game as a binary number to be interpreted by a computer. But is a human just a bunch of cells, or is it so much more than that....?

 

Sorry Misterselmo, but

"It's almost humorous to me, though, to think that every single person who ever built a computer game is basically abusing the computer."

No. You aren't making any sense at all, nor is that correct. Game programming is problem solving. If you don't think so, you're probably doing it wrong.

To program a game you need to solve problems.

Computers have gotten faster and cheaper due to people buying them mostly for entertainment. They (especially with GPUs / Carmack etc) have evolved very well in order to run games and entertainment. That's not abuse, that's design.

In fact most of the performance innovation in computers is strictly down to games. Games actually advanced the entire computing industry, created cash flow where there wasn't any, and is the prime reason we are where we are today, thanks to consumers and... games.

Games are the reason why we can afford a PS4. They're the reason anyone can afford a laptop. They're the reason you even HAVE a computer that powerful.

So yeah, you've got this back to front.

 

I think it does yield an useful output.

Think about the entertainment industry. What does it do for the people? It doesn't provide food or shelter, it doesn't save lives.

Sports, music, movies, traditional theater, travelling & tourism, etc. None of that is essential. Nor are video-games.

BUT, without any of those, life would be less interesting. And video-games belong to the entertainment industry. So don't think they're just big programs with no purpose.

 

"Step-wise refinement" says not much about the architecture you use. And how you architect, aka organize your code is very important above a certain size.
You should probably read some game dev architecture books and articles about component based design (not one, many), if you haven't already. There are many good articles where AAA studios explain their lessons learned from specific titles with regard to architecture. There is also a huge ogre3d forum thread about component based design (but more about implementations of these, still you can learn a lot), but for that you should probably read many articles first.

 

If you are coming from a normal software development mentality, yeah, game development is kind of weird. Most to all of the problems are of your own making, and a good chuck of features are added purely on the rationale that it would be cool.

The philosophies of the two are more often than not diametrically opposed. Games strive toward grandeur, constantly expanding feature sets to squeeze every ounce of performance out of a machine to do something. The ultimate goal for software however is to solve a problem so perfectly that you will never have to work on it again.

 

Really, a game is like any other program. It simply presents a large dataset that the user wants to view and edit in a certain way. Its a polished and intuitive way, to be sure, but the Legend of Zelda is the same as Microsoft Word in that regard.

 

That is only true in the sense that both are huge software projects. But in game design today almost everything is component based design (because of flexibility and for rapid iterations), while that cannot be said about business software design.
Read some AAA studios report about component based design, you will quickly see why a "standard" design with fixed interfaces like you would probably use it for MS Word would kill your productivity fast.
Game design requires agility and flexibility, so better choose an architecture that supports that well.

 

I agree about the part where it's difficult to get a sense of what problem is being solved by this piece of software. It seems so vague, like, as if the problem is 'how to solve people's unhappiness'? 'how to entertain people'?. .. and then it seems so nebulous like you're trying to do it for the sake of something that isn't really a problem to begin with. I've definitely found it much much easier and more productive to make an app or tool where it's clear and obvious what the problem is and what you can do to solve it or make things easier... but when it comes to 'people' being the problem - it's as if games are trying to solve human psychological needs, which are all over the place and unpredictable and difficult to understand. Makes it a real shot in the dark it seems... but probably I guess you can get more of a sense of what works and what doesn't with experience.

 

My game definitely serves a purpose, to entertain.

Software doesn't have to "solve problems."

High-level programming languages aren't designed to "solve problems."

They're designed to represent digital logic circuits and allow you to interact with them, organize them, and manipulate their stored data in an intuitive way. That is literally all. Assembly exists because binary register manipulation is too labor-intensive to do as a human, and C++ exists because Assembly is also too labor-intensive for most design goals. You can write software that creates problems, just as easily as you can imagine: Step 1) "I get the eggs out of the fridge" ... Step 2) "I intentionally drop all the eggs (and upload it to YouTube)".

(writes a batch file that deletes system32)

 

Ha, ha ha; I don't know how much programming background some of you have, but no.

The Legend of Zelda isn't a massive pile of text parsing and I/O functions. It is a video game. It accepts inputs and makes draw calls.

They are both software in the same way that a motorcycle and an airplane are both vehicles. They are completely different and can be objectively differentiated on a basis of their logical operation. They are not the same just because they are both made of aluminium. One does not design an Oracle server database in the same way one designs the Legend of Zelda.

Games involve much more artwork and deserve the title of works of art. Microsoft word is a tool. No matter how well designed a tool is, that's what it is: an object designed to serve a practical purpose. Now, the definition of art is a nebulous term; and certainly some of the most sophisticated tools could be considered works of art in their own design merits, but video games fall squarely into the most pure and early interpretation of the term, they exist for no ulterior motive than to captivate us.

This is why video games are so impressive to me, it requires both artistic sense and logical grounding in game theory.

 

Zelda *is* a massive pile of text parsing (all the conversations, inventory, etc plus localization) and I/O functions - streaming, object management, data management and so on.

Some of the replies in this thread are making me baffled at the complete naive innocence on display.

Maybe it's because Unity hides a lot of this you assume it's not there...?

So one dives into game development with no planning whatsoever and no respect for the issues that require robust bug free code? I'm sensing a lot of arrogance here. I'm pretty sure some games are bigger than some operating systems. Take World of Warcraft for example.

 

Really? Must be joking. Reading conversations and inventory names is like 20 lines of code out of a million lines of code in Zelda. 100 lines if they chose some stupid approach for the localization. But I think they are on the lower end, they did not even check for buffer overflows (that's how I hacked my Wii, creating a horse name that is too long).
If you think the code architecture of business software and the gamplay code of larger games like Zelda is the same then you have some reading to do. There are countless articles of game studios that tried business software like architectures first to realize this is just a bad idea. There are many reasons why Unity uses component based game objects. Many other approaches just fail miserably.
Edit: and if you think MS software is component based (in game object system component sense) because of MS COM usage, then you miss that there are many different usages of the word component.

 

Saying that game programming does not serve a functional purpose is kind of like saying an artist is abusing his pencils because a painting is useless and he should stick to painting his walls instead.

 

Such a philosophical topic. Of course your games will bloat as you add more stuff. I think your problem is that COMPUTERS are stupid and you have to tell them everything down to the smallest detail. It's easy to tell yourself "Ok so I want to have a drunk piranha collecting old gum in the sewers in my game" but when you actually start making it you have to set everything, speed, color, sound, animation, lights, mechanics, systems, menu, farts etc. So yeah on the surface it's just a simple game but there's a lot of stuff to set up.

If you don't like coding try Playmaker, but even though it has a good idea, it too can get bloated. Are you following good coding practices? Maybe that;s why it's all bloated. The more compartmentalized code you have the easier it is to maintain. I'll b honest I haven't read your entire post, cuz frankly what does it matter if a game is a program by definition or not. Behavior = some kind logic. Best stuff around for working with logic is programming languages. They aren't designed to solve problems, programming languages do what you want them to do.

Example:

x + 5 = 100 therefore x is 95. You can achieve this through code. Problem solved.

Spawn 5 chihuahuas and set them loose to hunt the player. You can achieve this through code. Problem solved.

The solution doesn't have to be in numbers. The above example would solve "How to endanger the player". And it's only 1 solution. And lets not forget there are a lot of paradigms out there, OOP is only one of them. you have functional, procedural, and aspect oriented programming styles. So pick and choose and make do. My 2 cents.

 

A game is a feeling dude, a feeeeeling duuude!

 

Very true. Have yet to find a game that is a feeling dudette. #yesallcartridges

 

The problem is, it isn't always easy to specify the problem. Sometimes the problem ends up being you just want to make something "better", but people have different opinions about what better actually is. At that point your problem solving is just a subjective discussion.

 

Of course an electronic game is just a big program, almost by definition. I'll grant that very early arcade games and such were more about hardware. But any modern electronic game is based on instructions running on silicon of course. I'll take a crack at interpreting the gist of the post though:

The difference between traditional software engineering (or whatever you want to call it) and game building I think has a lot to do with design rather than technology. Sure, there are tons of things like handling realtime input/graphics/physics/sound/AI, computer graphics, art, and all that that are different and you might not structure code quite the same way. But the really fundamental difference is with the design. With a business app or something you might gather requirements and design something to meet those requirements, then iterate through a requirements/design/implemention loop until you zero in on something more-or-less useful.

With most games, the only real design consideration is that it's fun, which makes it hard to know when (or if) you've hit that point and to what extent. It's also the root of "imposter syndrome", since you have no real way to quantify the quality of your game. It's like, your opinion, man.

 

Games are art. Large piles of binary based art. It is one of the most amazing genres of art ever created in history. That is all.

 

But that's not "problem solving". That's still "problem identification" and yes, that often is very subjective, but why is that a bad thing? It's all about spaghetti sauce, man. It's perfectly ok if different people see the problems differently. That's why we have Call of Duty and Battlefield and they're both wildly popular despite being identical to the untrained eye.

A part of "I want to make X better" is identifying either opportunities for improvement in X, or shortcomings in X. They are the basis of the problems you'll be solving.

Not joking at all. For starters, you're only picking on the stuff that's displayed to the user as text. There's a whole bunch of other text that goes into a game. More importantly, though, you're skipping over the "and I/O" part of the quoted statement, and I/O is a huge part of any game. The entire purpose of a game is that a user can interact with it and it responds in some kind of engaging way. If it can't do that I don't think there's any definition of "game" that it can fit in.

Consider that there are entire fields of study, practice and specialization that are just small fractions of the "output" part of a game, the most obvious being real-time graphics.

 

There are a lot of great replies already that basically tear the original post to pieces.

If you think it takes 20 lines of code, you're missing out what those 20 lines call and are based on.

I think you don't have very much experience with software at all. Not with statements like that.

All modern operating systems work that way. They have moving interfaces with all data manipulation done behind the scenes. If you think that Excel's work is done in front, you're sadly mistaken.

In fact, if you think that spreadsheets gets work done, you're very mistaken. How do you think you get bread on the table?

• It gets harvested by a multi-million dollar harvester run by software that uses various tracking systems to know exactly where and what to harvest, in addition to doing its own maintenance cycles.
• It gets shipped to a grainary connected to a rail system run by computers doing timing calculations and system health checks that make a video game pale.
• After arrival to a bread factory the entire system is again computerized not just for timing but also yet again... self maintenance.
• All of these people overseeing these systems and doing work have to get paid, which is automated, has taxes, accessorial charges, deductions, discounts, and auditing done behind the scenes while the output is anything from mechanical to an EDI doc sent to ADP for payroll processing as either a direct deposit or a printed cheque.
• Somewhere a dispatcher uses software (possibly from my employer) to select the most optimized combination of driver, power unit, trailer, container, intermodal (air, rail, or ship) to get the bread from the factory to your grocery store.
• Dispatching is actually one of the most difficult and more advanced algorithms out there. It's essentially a very complex version of the travelling salesman problem on a far larger scale and has to take into account everything from fuel price, mileage, hotel prices, hours of service rules (USA trucking rules are horrid and make no sense), safety regulations, highway speeds, traffic, theft, anti-theft, hazmat rules, accessorial charges, discounts, D83 payables, the various intermodal complexities.... and all that the dispatcher wants to do is double click to assign a freight bill to a trip and get a suggestion for the best carriers and drivers.
• By the way, shipping 499 ping pong balls is considered to be safe, but 500 ping pong balls is actually considered a hazardous material. It's all related to the amount of nitrogen gas a truck has on board because of the contents inside a ping pong ball.
• Need I continue?

Spend some time with simulation and non-game interactive software. Also look into the vehicle subsystems that run things like the Finning 740EJ. There isn't much difference between those subsystems and all the moving parts of a game and/or game engine except that they are different moving parts. Also look into the subsystems of an F-16, F-18, and F-22, from the flight controls to targetting and communications.

In fact, to trump all of that, I would offer the example of submarine communications and targeting. The required calculations to control a torpedo using any combination and/or loss of the combination of sonar, RF, *classified*, and GPS is astounding.

All of the above "abuses" computers. It makes them do non-binary equation solving between systems that sometimes ultimately still require human input because there isn't a quantifiable number to calculate. The only reason a flight control system knows that a dive is "bad" is because we gave it a bounds check which fighter pilots routinely override in favor of the altitude bounds check which they override both when doing a barrel roll which somewhat kills normal lift for a brief period of time.

I think you've lost yourself in cybernetic theories and lost sight of both the forest and the trees. Computers are gigantic calculators used as tools for what we create our own purposes for.

Some of us make games. We sell some for money. That is a business purpose for some. It's not a pure art. Some of the people here are crazy good mathematicians and know things about shaders that is past what I can understand. Have fun telling them that solving light simulations isn't a business problem. There are academics who would disagree with you that have doctorates in trying to understand and simulate IOR of different objects and solve the problem of cloaking and invisibility -- and the real world tests are astoundingly good, though not ready for public consumption.

You are confusing enterprise software with various necessary controls with non-critical software. The firmware for a life support machine or a medical dosage machine has vastly different requirements that are far more strict than most other programs. I wouldn't expect the QA to be as strict for a video game as I would for mathematical perfection in banking or flying.

Burn victims and kids in dentist chairs playing games would disagree. Both get a 30% reduction in pain and distracted from their reality that various work can be done on them. Useful output? Not every solution has a readily apparent problem, and not every problem has a hard science solution. Soft sciences exist for a reason, and you might do well to expand your extremely narrow thinking. It's like design: neither a hard science nor a pure fine art. To remove form from function is as bad as removing function from form.

Not long from now you're likely going to over-architect yourself into a corner. We've all done it. The important part about prototyping and doing the fast and dirty is to discover what game design really is and what "fun" appears to be. Getting lost in the software and architecture is *not* game design.

By the way, computer games aren't that large. Go take a look at the Unity output binaries. A far larger program is the Unity editor, Windows 95, mileage software...

 

Sidenote: I've read somewhere that "Zelda - a link to the past" even used packing and optimizing to a point that they managed to get the whole game in under 1 MB of module space. They achieved this by looking at the light and dark world and having the dark world be a mirror of the light world with a swapped graphic set for the most part. Only the differences were stored in memory.
Apparently Capcom even managed to sqash the whole 2 Disc edition of Resident Evil 2 into one N64 game cartridge.

The optimzation know how that went into some of the games from the 8 Bit and 16 Bit era of games still amazes me. Even if I have only marginal knowledge of how it was actually achieved.

 

now to throw my opinionated penny int this diluted pool of wisdom..

essentially, yes, games are just realtime-interactive data-visualizations. and of course the software architectures vary from say a warehouse inventory system.. but architecture is biology; making "games" and making [any other software] is chemistry. aka "boils down to the same stuff"

yes you can get hung up on methodologies and fine points but if you do that you're just as likely to complain about the new box-design of your dish-washer tabs..

games certainly require all kinds of differently formatted data and a lot of it at that.. but guess what.. so do other softwares. if you want to argue that a game's IO is far more varied for it's different input categories such as {code, textures, meshes, audio} as opposed to a "Word/Write" <you still have a lot to learn> for you have forgotten the realtime part. that, little apparently overlooked in this context, part leads to very narrow constraints imposed on the inputs.. and the outputs are no different. therefore, yes, games are just programs.

"but there's so much more to creating a game than there is to making a good piece of software"
first of all: There is no "good" software. If you still think that <you still have a lot to learn>. There's just software that sucks slightly less to accomplish certain tasks than the other n pieces that allow you to do that task.
furthermore: If you think the only thing going into the production of an enterprise level software piece is code; repeat after me: <You still have a lot to learn>

now for the point of purpose or functional design of "programs" vs "games". (This is purely subjective)
Of course there is a purpose to games. That purpose is to A) entrance the user of that software through immersion techniques so deeply he/she forgets everything around them B) during that period deliver an enjoyable experience (A and B are a feedback loop fyi). That's what is commonly referred to as "Entertainment".

http://en.wikipedia.org/wiki/Entertainment


so back to it i go.. because
<I still have a lot to learn>

 

I agree, gamemaking is an artform and writing code is a dance. We are engaged in producing digital theater.

 

C++ or C standard library maybe? You want to count that as game code?

I don't know if you have experience in reading exactly what I said? I talk about organization of gameplay code. You want to argue that in almost any larger game today (including unity games) the gameplay related code has a component based game object system or you want to argue that business software does not use the same architecture? Good luck.

 

games should be like minecraft, kids like games LOOOL

art

 

LOL! Okay, I hope this comes across in the right way but I really don't understand why on earth you would spend years thinking about such a thing? I mean seriously? Obviously, games serve a purpose. First and foremost they provide entertainment. Beyond that they provide a challenge. They help us to increase our hand-eye coordination and sometimes our logic and problem solving skills.

Games are fun (or should be at least). If done well they can let us explore things we have not been able to or are currently impossible to explore. A game can allow us to experience being a part of a medieval war. They can take us to distant planets where we play a key role in colonization. They can take us to the depths of the ocean. They let us become heroes and heroines escaping our day-to-day mundane routines and experiencing something different.

From your side, as the developer, there is also great challenge and opportunities to be creative. You can literally build a "new world". In your game environment you decide all of the laws. You define how detailed the interaction is. You decide which items will aid the player and which will be obstacles.

Of course, you can view a game as nothing but just a piece of software. Ultimately, that is what it will be. But so much goes into getting to that point and that is what the focus should be on. Otherwise, we might as well see books as being nothing but a bunch of pages with some ink on them.

As someone who has done both game development and business software development for a long time I can tell you the game development is far more challenging and interesting.

Good luck with your project!

 

Problem: entertain people as long as possible while playing your game
Solution: ??? PROFIT!

As Bjarne Stroustrup(creator of C++) says in his latest book: "Often, a problem is only fully understood through the process of programming a solution for it."

 

To use your analogy, an Ford Mustang is not a vehicle. Why? It doesn't haul 2 tons of dirt.

Zelda and Word are, in effect, the same thing. They only appear different to the user because of the feature set they are given. They both parse info and draw stuff on the screen. Ironically they both parse text and draw sprites. The only difference is that Zelda has information to automatically move sprites based on specific behavior, while Link waits for player input. Word almost always waits for user input, but can adjust sprites automatically at times.

So yes, Zelda and Word are exactly the same.

So what if a database and GUI are designed differently? Do you think Super Meat Boy and Tetris use the same logic and programming language? There are games written in BASIC with no OOP involved. They're still games and still software.

Difference in development doesn't make the final product different. Hand building a car, using a robotic assembly line, and 3d printing all give you the same exact product in the end.

 

Maybe that is the problem. I talk about newest Zelda and you about the oldest one. Early games were so simple you could use a rigid business software like approach. Todays (large) games are not. You need much more flexibility, that's why the architecture of a modern game object systems is very different from business software. And if you don't see that then I'm sorry for you.
Have you ever read articles about architectures of modern games (mostly different implementations of component systems)? Or is the business software background missing? I don't understand how one cannot see that point with even minimal architecture knowledge in both worlds.

Edit: I talk about high-level concepts, these are not dependent on programming language or details. So for a software user both are software, they wait for input and draw some stuff. For a software architect these are very different things, because the basic architecture and the constraints are very different. So it depends on perspective (like everything). I thought we talk software developer perspective here.

 

I work on business software in my day job, and I work on games in the evenings (except for when I'm working on tile packs like right now.)

Really, a well-architected game and a well-architected piece of business software differ in only one key way: the means of presentation.

• Color - Games are allowed to be, and should be, more colorful than a business application. The differentiation is because games are about giving quick feedback for the user's decisions, and getting the player into a 'flow' state where only the game matters. Conversely, a business app is solely about quickly and efficiently presenting information such that the user can do a task more efficiently and make better choices; more colors actually make this difficult.
• Audio - A lot of the business software I've worked on does not provide for audio of any sort, because it's simply not necessary; often times, default operating system alerts work just fine. If you want background music that badly, there's always YouTube.
• UV-Mapped 3D Models - This depends on the profession. An architect needs a 3D visualization for certain things, that an accountant dosen't. Generally, high-performance graphics aren't necessary for most pieces of business software I've encountered, as it usually deals with keeping track of boring numbers.

However, there's a lot of bits of development that translate well between Games and Business software:

• Decoupled Code - Generally, you want to ensure that your interface code and business code are not strongly coupled. In this context, 'Interface' code refers exactly to that - the interface the user uses to do stuff. The business code is the underlying stuff, like determining if a character has died if their HP has fallen below 1, or what the total for a transaction is including local sales tax. There are additional details, such as using interfaces such that code relies less on concrete implementations, but we're talking in the broad strokes here anyhow, so let's not go too far in-depth.
• Data-Driven Calculation - The more you're hardcoding values, the more you're doing it wrong. You can't entirely get away from constants, but generally there should be some sort of data that your application relies on, be it a JSON blob, MySQL database, or a hosted database. The point of the software is to present data to the user or its source, to accept data from the user or its source, or process data that it has accepted prior to presenting it.
• User Experience - Your interface should always be as transparent to a user as possible. The interactions should 'feel right'; the app should only throw up barriers to progress in very specific circumstances (namely, stopping the user from entering garbage, because Garbage In leads to Garbage Out.) Put another way, think of the app like a hammer, or screwdriver; we use the app to do something we could do ourselves, but more easily.
• Managing the Client's Expectations - The human element of software development is the hardest thing, though. It dosen't matter whether you're making Half-Life 3, or Quicken 2015; users will always need certain things done, and want certain things you just don't have the resources to make happen. Given infinite resources, we could make an infinitely functional piece of software, but that's not realistic. Stuff hits the cutting room floor.

I'm going to chip in to the original question with my answer, if it's not already obvious: "Yes, games are just a big piece of software", with the caveat that games and business applications have different goals, and thus different ways of doing things.

I highly recommend that you pursue a non-games related development job - there's more than just programming out there, technical writing, Q/A, business are equally useful fields - so that you can understand more about what makes software either succeed or fail. The knowledge is transferable.

 

Honestly, you're not winning any points with anyone here in this forum. Asvarduil, myself, and others have been nice. You're coming across like a jerk. Some of us have a lot more experience that defies everything you've said.

Are you still in highschool or some other form of post secondary education?

All permutations of the above and more. My day job is in business software and I've studied the architectures of a few game engines in my time. Each has its time, place, usage, and history. Instead of throwing around accusations and insults, can you stop and prove that you have seen all code and know all these things you're speaking of? Have you seen the code powering medical systems, banking, shipping, dispatch, automation, subways, farming, factories, flight control systems, drones, nuclear power plants, and all the subsystems on a submarine? Where is your proof? Where is your experience?

Bingo! Very well said. But I think the OP more likely needs to get into the real world away from software for a bit. In my experience, closed minds make horrible employees and coworkers.

 

I have many years experience in developing, designing, specifying, consulting or leading teams to create business apps. So I understand what you want to say. But still the underlying architecture you choose for a large game is very different between the two. That is my whole point, never said something different. Like already said, there are many articles about studios that tried business app like architectures for game object systems, they are just not flexible enough. Don't believe me, believe the many reports of studios that tried it and wrote down the lessons learned.
Also games are real-time more or less, for most business apps the required response times are in a different order of magnitude. And they do not only act on user input. Therefor, for me games are closer to scientific simulations than to business apps. But that is not my argument.
Hell you use Unity, it has a component based game object system. You think that is there just to make it harder for people coming from business app background? Note that most AAA games don't use a predefined such system, they create their own. And there are many ways to do that. And this implementation defines how you express your ideas and program for the game. For me this system is the heart of the game software. For the programmer this is what they have to get, this is what makes work on game A different from work on game B. It is also a deciding factor over if development is a success and on time (flexibility and iteration speed depend mostly on that system).
Business app architecture of a standard app is dead boring compared to game system architecture, it is a solved problem. I would even trust a junior developer and just have a short look what he designed (of course some juniors fail, but then I would talk to the HR guy that hired him). For game object system design of a large game you gather the gurus in your company.
But let's just agree that we disagree. I have the software architecture view, there are many other valid views. So discussing that makes no sense. Just wanted that you understand my view.

Of course, nobody said anything different.

 

No, CS master many years ago, on one of the top 10 technical colleges/universities of the world. Full scholarship, top 5% quantile of my master year. Don't want to brag, but you asked so nicely.

I only was d#ckish because you started with the following, and IMHO my response was nicer than what you said first:

Do I really have to google one of the countless articles about that for you?

 

"If you immediately know the candle-light is fire, the meal was cooked a long time ago"
I think that's true for most of us

 

Want advice? Ideas are worth crap all $0 ... 13 weeks, 2,500 lines of text, 12,000 lines of code ... none of that matters if I don't finish, and release it into the wild! Games are just highly complex software that's half science and half art. And like other software, the ONLY thing that matters is execution. "Finishing is a feature. A really important one. Your product must have it."

Gigi

 

Misterselmo,

Games do solve an issue: how to give the consumer something fun to play, while making a profit from it.

You realize the gaming industry is a BUSINESS, therefore someone is making money off of it.

 

Why do I feel like most of the people who say games solve a problem don't have good problem solving skills?

Comparing the raison d'etre of a game to most software is night and day. One has a clear cut, precise, and definite purpose with measurable value (usually in time saved). The other is art, the single most human and abstract concept conceivable by man.

Saying games solve a problem is basically undermining what actual problem solving, never mind how it undervalues what art actually is. Art is not what the artist projects into the world, but what the audience receives from it.

 

There's a faulty argument in this: while the underlying architecture large game may be different than that of a large business application, you'll find that large business applications typically do have wildly different architectures from each other, and that large games have different architectures from each other. I've found in my (limited) experience that, the larger something becomes, the more stuff gets added to solve or at least patch other problems specific to the problem domain being operated in. While I see what you're trying to say (which, interestingly enough, is what I said - games and business software are two different things, and thus have two different ways of doing things), other than a false anti-equivalency, I don't really see what this argument adds to the original point that games and business software are somehow 'different.'

Yes, and no. Yes, games often do things more akin to a scientific simulation (rendering a visualization of calculations or data in real time), but there is also more business-related functionality such as filtering inputs (do you have 1000 Gil? No, you can't buy that sword that costs 5130 Gil), processing changes in app state (I was walking on the field, and I had a roll for a random battle! Push the battle state onto the app stack at position 0, and load it up!), and calculating the outcome of some actions (You dealt 36378 damage to the Jabberwock! Your party wins! You gain 537 Gold, and a +3 Sword of Greater Trollslaying!)

No.

If you're implying that Unity is the wrong tool for the job in general, there's enough games out there to disprove your point entirely.

If you're implying that Unity is the wrong tool for you, you should research competing technologies.

If you're implying Unity is what is preventing you from succeeding, consider that, like C# or Visual Studio, Unity is just a tool. Perhaps your process has improvement needs, or that your knowledge is lacking.

I've released three games publicly with Unity, and I know I have a lot to learn. The parts of the projects that succeeded were because of my knowledge and mastery; the parts of my games that are regarded as failures are due to the exact same things.

If - and only if - I can conclusively say that something in Unity made me unable to realize a vision, then it would be fair to say something about that specific thing (probably in the form of a bug report, or some other productive form of discourse with Unity Tech.) Having read your post though, I don't see such a clear thought about the problems you are having. It rather comes off as whining, if I'm totally honest.

I disagree, and question your experience upon reading this, for the following reasons:

1. Business app architecture is not boring, because each app addresses a specific problem domain. Said domains are subject to various legal, institutional, and inherent rules that must be determined and implemented correctly to be considered to be of any value, and thus earn revenue. I've not yet been able to develop a cookie cutter business app (it would be nice, though.)
2. Business app architecture is not a solved problem; again, each app is different. What works in a system that helps allocate parking spaces to employees may not work in an online ordering system (both things I have experience with, funny enough.) That said, if game architecture didn't have at least a similar amount of the problem domain solved, we would hardly have generic engines like Unity or its competitors, now would we?
3. If you would trust a junior developer to architect a system alone, without your supervision or that of a trusted senior developer, and then toss him to HR when he fails, that tells me a lot about you as a professional, and it's not good. Professionally speaking, and by your own admission, you're a douchebag (I can think of stronger things to say, but that is sufficient to voice my distaste of your rather negative attitude.) I really don't know what to tell you on this count, other than to find an attitude adjustment when dealing with architecture and junior developers.

Oh, I agree to disagree with you. I hope one day, future experiences will help you and I be able to agree on some things. I wish you luck with your professional development, particularly the attitude part.

 

No, you did not understand my point. I say exactly the opposite. Component based object system is the state of the art, 95% of larger games use it, and so does unity. It is needed for flexibility and iteration speed, everybody does it for a reason. So I say this is the right thing for game design. And standard business app like architecture is wrong for game object systems in many cases. Of course there are exceptions to this on both sides, I talk about standard ways to do things.

We have 3 templates for business app architecture, they fit for at least 95% of projects. And we are a large project implementer, we work for all kind of industries. We basically do everything the internal IT of large companies cannot do themselves or management thinks we are faster or better quality than them.

[Edit:]
The thing about the junior architect: we expect people to have some skill. What they have to do depends on that skill. I give the architecture job to a junior which was hired because he should have this skill and HR assumed from their screening that he has that skill level. So in this case I go to the HR guy not to sh#t on the junior, but on the HR guy. And of course the junior gets another chance. But if he fails multiple times he should get a position matching his skill. This is not mean, the junior will have much the better life in a position matching his skill. But designing a not working architecture and not seeing it himself and not coming to me for help is a bad sign.
For some positions we look for juniors that can manage a project by themselves after having been in one for once. The exceptional hero developer of tomorrow. If HR sends me an average junior for that, that is a HR fail.

 

Interesting conversation. I don't have much input but I enjoyed reading.

 

Ah, you just confirmed my alternate theory -- an academic.

All that everyone in here is saying is that your OP is arrogant and presumptuous as hell and comes from an academic viewpoint that hasn't seen how the rest of the world works.

I'm glad you've found what works for you, but guess what? There is a lot more code out there and for various reasons not everyone follows the perfection road. Hell, I'm very close to quitting my job because I can't take the stupidity any more and would like the opportunity to follow some best practices.

 

Maybe many years ago but not anymore, but you can say that was my initial background.

That's what I like (and hate) about my job, I work together with IT of many companies/government, other contractors and project implementers. I can tell you I can count the IT departments that really work (imho) with one hand. Sad but true. (Bad or no best practices, not working organization/management, skill/job mismatch,... I could tell you many stories that are unbelievable)

 

I dunno, when you think about all the things computers are used for, it's hard to really think of games as the real reason people have powerful personal computers.

I mean, first of all its nothing but a high speed number cruncher with a gui. Like an abacus from space, really. So you figure between the sciences, weapon systems, flight related anything... and then of course telephone and networking purposes, it was inevitable that the machines would get faster/smaller the free market and necessity would ensure that. The primary use of computers now is undoubtedly communication, but entertainment is a close second I'm sure.

Games, however, make use of a very intensive looping process. I'm not claiming to be an electrical/hardware specialist or anything, but I'm guessing all that extra processing consumes some energy, creates some heat. On older pcs with less RAM you can literally hear file paging as it happens, a sort of deep crunchy sound.

As for the whole component architecture thing, I spent some time over the last month in c++, then started writing an item storage system in c# and really looked into as many c# elements as I could, and I have to say I don't see what you couldn't achieve between objects and interfaces, what the need is for creating a great big checklist of a class I just don't quite understand. I see why UnityEngine does things along these lines, its supposed to be broadly used by millions of different programmers of all skill levels and backgrounds for any type of game conceivable. Can that be said about a specific small game project, which might have as few as 30-50 classes, most of them small one off's, with a bunch that inherit from a handful of base classes? I'm skeptical, I think there's a point where you're just overcomplicating needlessly where a proven approach works nicely.

 

Huh?

I can only think of a handful of reasons for people to need a "powerful personal computer", and games are by far the most prevalent.

I don't see the point in screws in woodwork. Can't we achieve everything we need with nails?

It's not about binary assessment of whether or not a job can be done. Just as important are how well it gets done and how much it costs to do it.

 

Artists do abuse their medium. Art is functionally useless by definition. If it had a purpose, it wouldn't be art... it would be a road sign or an advertisement.