-6
\$\begingroup\$

I've been interested in how AAA games are made recently.I looked up how Fallout 4, one of my favourite games, was made. It turns out bethesda games uses a drag-and-drop style engine with maybe a little bit of scripting here and there, like Unity or Unreal. I also looked up how GTA 5 was made. It turns out that rockstar games has its own engine, Rockstar advanced game engine (R.A.G.E). Slightly disappointed , I'm just wondering whether any AAA game out there is still actually programmed with code. I know that the engine is probably made with code, and if a game company has its own libraries with useful functions/classes that makes sense, since some things will be very tedious to directly repeat. But do AAA industries still use proper code for the actual game?

\$\endgroup\$
  • \$\begingroup\$ When you collect some more experience as a software developer you will see that the real work in software development isn't programming and won't look down anymore on people who use visual tools instead of "proper" programming languages to do stuff which is done far more efficiently in a visual way. \$\endgroup\$ – Philipp Aug 18 '16 at 22:04
  • \$\begingroup\$ That depends on what you're good at and what you're not. I've been using java for software development for some time now. \$\endgroup\$ – Max Aug 18 '16 at 22:07
  • 5
    \$\begingroup\$ I took a look at your stackoverflow profile, so I think I got a quite good impression of your level of experience. When I was on your level I also told myself that working in code makes me somehow better than those who worked with visual tools. It took me several years to realize that the ability to pick the right tool for every job without being influenced by prejudice is an important skill for software developers. \$\endgroup\$ – Philipp Aug 18 '16 at 22:15
  • 2
    \$\begingroup\$ That's still no reason to not use visual tools in those situations which are within their limits. Like for example designing a game level by drag&dropping objects around a WYSIWYG editor. \$\endgroup\$ – Philipp Aug 18 '16 at 22:37
  • 1
    \$\begingroup\$ Some great game development advice I've heard went something like this: "If you want to make an RPG, use RPG Maker. If you want to make an RPG from scratch, make RPG Maker." There's little reason not to use good development tools. \$\endgroup\$ – milk Aug 19 '16 at 18:25
6
\$\begingroup\$

Yes, absolutely.

Fallout 4 was not made entirely with Bethesda's drop-and-drop tools. Nor was GTA. Even if they were, that means those games could not be made without those tools, and how do you think those tools came about?

Somebody wrote them. In a programming language.

The engines your thinking of here do a lot of things. Among those things is provide high level tools (such as drop-and-drop scripting tools) that can be used to prototype gameplay and related systems, iterate on them quickly, or allow non-technical developers (like designers or artists) to affect change in game systems without needing a programmer to intervene.

But programmers wrote those systems in programming languages in the first place. Further, as with most any abstraction, these systems introduce extra complexity which can negatively impact performance, and so they are often not used (outside of prototyping) for extreme time-critical aspects of the game (even the gameplay code). You will not find the core rendering loop driven by Blueprint in Unreal, for example. Nor will you find the kernel of the physics simulation in Fallout 4's drag-and-drop system.

Programming languages are still very much a thing.

\$\endgroup\$
  • \$\begingroup\$ 1. I know the game engines were coded, I was asking about the actual game, 2. How much of , let's say Fallout 4, would have been made with the engine? 3. Is it a good idea to use a visual engine? \$\endgroup\$ – Max Aug 18 '16 at 21:56
  • 3
    \$\begingroup\$ I didn't work on Fallout 4, so I can only speculate. And won't. As for whether it's a good idea to use a "visual engine"... if you want to make a game you should use the best tools for the job that fit with your workflow. "Visual engines" let you build/iterate on the things that matter, the gameplay that is unique to your game, far more quickly than most alternatives for many people. Nobody can really tell you objectively what technology to use, but I'd argue that if you avoid good tools simply because they "look too easy" or don't require you to do everything in low-level C++, that's folly. \$\endgroup\$ – Josh Aug 18 '16 at 22:08
1
\$\begingroup\$

Yes, visual editors in engines only get you so far.

For example in unreal engine you can and most likely will be adding pure code files to the project for the very specifics of your game, while using the faster visual editor for all the usual stuff that is almost entirely covered in the engine itself already.

So basically, you are right about source code being more usefull in that it gives the author more control over what's going on, but in a game, there are so many common things that it's just a waste of money to develop it 100% from scratch.

Also, there are engines that are still purely code based, also known as libraries. All those super advanced "engines" are just a bunch of libraries with a visual editor.

\$\endgroup\$
1
\$\begingroup\$

They tend to use the most cost effective tool for the job. AAA games are expensive to make & have no guarantees of return on investment. Visual engines provide several ways to mitigate risk by saving time &/or money:

  • They are already built, so you don't need to code up & test the engine.
  • They are often more well documented than in house solutions, especially if they are themselves a commercial product.
  • They allow people who may have less coding expertise (modelers, designers, artists; basically anyone who isn't a coder) to participate more directly in prototyping & iteration.
  • By providing an framework, there is the perception fewer development choices to make, E.G. what language to use, how to handle events, etc.
  • They may target more than one platform, reducing the cost of porting.

That being said, there are still reasons not go with a visual engine:

  • The reasons listed in favor of a visual engine don't provide sufficient value.
  • You want some look, system or level of performance that cannot be achieved with a visual engine.
  • You hope to license your own engine as a product.
  • You need a combination of sub systems (graphics, audio, etc) that isn't provided by an engine.
  • Writing your own engine is a design goal in of itself; probably a rare AAA concern.
  • You want to target a combination of platforms that aren't covered by available engines.
\$\endgroup\$
  • 1
    \$\begingroup\$ "By providing an framework, there are fewer development choices to make" Except the choice which framework to use in the first place, of course. If anything, the availability of frameworks just increases the amount of analysis paralysis during early project planning. That's why the question "What game engine should I use?" gets posted here so often we got a custom close-reason for it. But otherwise, good answer. \$\endgroup\$ – Philipp Aug 19 '16 at 10:51
  • \$\begingroup\$ That's a good observation about the validity of 'fewer choices'; I've tweaked my answer. Originally, I was thinking of times where I had already picked a framework without considering system X & when I needed to work on X, my choice was essentially already made. \$\endgroup\$ – Pikalek Aug 19 '16 at 16:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.