Existing 3D Game Engine for Gameplay Programming

Hey Royibernthal,

If you're really wanting to start out easy then I'd suggest looking at a game engine called Unity. Unity basic is free of charge and a pretty easy engine to start with, in my opinion anyway. You can find that at www.unity3d.com. Unity uses UnityScript and C Sharp (C#), the engine is widely used by small-time game developers and both languages are relatively okay to learn.

There are many advantages to using Unity such as:

• There is a large Unity community on and off the unity forums. It's easy to find and discuss topics. This is also a great way of finding solutions to any coding errors you may run into.
• There are many pre-built scripts available online, making your development easier. Even and including a ton of free scripts on the Unity Asset store.
• There are also a lot of available plugins for Unity.
• Unity can create games for Windows, PC, Mac, Linux, iOS and Android. It's well known for its multiplatform ability.
• Anyone can get a Unity Basic commercial licence.

These are some of many. It's worth checking it out.

CryEngine 3 and Unreal Engine 4 you may find harder to start with. Where CE3 and UE4 are undoubtedly more powerful, the coding structures are more sophisticated and the licences are harder to get if you're planning to sell a game commercially. You can of course get a free non-commercial development kit for both unreal engine and cry engine if you'd like to try them out.

Unreal Engine Development Kit: http://www.unrealengine.com/udk/

Crytek Engine Development Kit: http://www.crytek.com/cryengine

I recommend that you start out with Unity Basic, keep things simple for the start. It may take you a while to adapt from 2D to 3D programming.

I hope I managed to help you and I hope you meet your goal!

First of all, thanks for taking your time and writing this very detailed answer.

I considered Unity in the past but I'm definitely looking to program in C++ and nothing else.

A little discussion about the lack of direct C++ in Unity:

http://stackoverflow.com/questions/10188636/something-like-unity-but-for-c-programmers

Furthermore, I'd rather not learn a completely new framework which I intend to leave later.

I'm definitely not looking for the easiest option or something in the middle, I'm looking for the best one.

Difficulty is not a factor. I've got the time and the will to learn something new, I just need to know I'm on the right path before I dive in.

I'll try to rephrase a little bit.

Career-wise, would it be a wise choice to learn Unreal Engine 4 / CryEngine 3?

Would they open doors for me in the future, not only in the companies behind those engines?

Would any knowledge I gain from working on these engines be useful in other engines I might encounter in my career?

Would the experience add to my resume?

Alternatively, are there any other engines I should consider? Not because they are easier to get into, but because they seem like a good choice.

Have you thought of designing your own engine using the OpenGL library?

If you want to use a 3d engine that will allow you to program with C++ you might consider trying the recently open-sourced Torque 3d. It's a capable formerly commercial engine with good documentation, and will certainly give you a good starting point.

CryEngine is definitely a good option that's very capable, but you might find it has a fairly steep learning curve.

You might also consider C4 Engine, Irrlicht, or Panda3d.

Royibernthal,

It is a shame Unity doesn't support C++. Considering it's likely to survive in game engines for 10 or over years.

A conversation about that if you're interested: http://gamedev.stackexchange.com/questions/37361/will-c-remain-viable-for-game-engines-in-somewhat-distant-future

I'm going to answer each of those questions directly for you!

1. Career-wise, would it be a wise choice to learn Unreal Engine 4 / CryEngine 3?

Yes, it would be a good career option and out of the two of them I would definitely suggest going for Unreal Engine 4. It's more widely used by games dev companies then CryEngine 3.

2. Would they open doors for me in the future, not only in the companies behind those engines?

Yes. I think learning to code in any engine will open doors for you in multiple companies, especially with the massively expanding market. This especially stands out for Unreal Engine 4 - although the engine isn't publicly available yet it will be around and possibly the game engine market dominator for many years to come.

3. Would any knowledge I gain from working on these engines be useful in other engines I might encounter in my career?

I think a good understanding of any 3D game engine gives you potential to work on other engines since most engines share the same attributes. I used to work with a Unity developer who had never before used Unreal Engine but managed to conquer it in a matter of days because he had a basic understanding of how the engine worked.

4. Would the experience add to my resume?

Absolutely. If you're looking to get a job in the games design industry that is to do with modelling or coding - you generally need a understanding of game engine coding/general development. Teaching yourself to code in say, UE4 would be impressive on a resume.

5. Alternatively, are there any other engines I should consider? Not because they are easier to get into, but because they seem like a good choice.

Good question. With the ever-expanding market in the games industry, more and more engines are becoming publicly available. You mentioned CDProjektRed in your post earlier (brilliant company by the way, love those guys) they are in development of their third witcher game which is running a new game engine, rumoured to be as powerful as Frostbite 2.

You'll find most big companies that know exactly what they want in a game will build their own engine for it. You'll also find that they will train you in how to build in that engine which is why you'll need experience in a well known semi-complicated engine, such as Unreal Engine 4.

Have you ever heard of a game called Infinity Universe? Those guys are building their own engine which generates and hosts thousands of planets automatically, they've been in development for a long while with barely any funding (that I know of, don't take my word on that) and they're still churning out some amazing looking stuff. You can check them out here http://www.infinity-universe.com/Infinity/index.php?option=com_content&task=view&id=12&Itemid=33

As Mathimetric mentioned, OpenGL Library is an option. Find that here: http://www.opengl.org/resources/libraries/

I hope this answers more of your questions.

Furthermore, I'd rather not learn a completely new framework which I intend to leave later.

This is a common thought process amongst beginners, but it can be a bit of a trap. If you get a job as a professional programmer you will usually not have a choice in the matter: you will be told to use a particular language/engine/API and expected to learn it and become productive quickly. An important skill to develop is the ability to learn and effectively use different technologies, and for most people this will be far more beneficial in the long run than simply getting experience with a specific engine that may or may not be used at your future place of employment.

By all means pick engines that you feel will yield good results and be useful to you in the long term, but don't let the fact that an engine might not be useful later hold you back.

quote "I have roughly 6 years of experience in programming 2D games, in Adobe Flash ActionScript 3.0"

you can design your own engine in c++ using openGL, and windows programming for free, and not need a license for what ever you produce.

I.E.

http://www.gamedev.net/gallery/image/3468-havoc-wreaker/

I'd like to offer 2 other engines:

Panda3d (by disney) and Irrlicht. Both are FREE 3d engines, and both do a fine job. They will not compete with Unity or CryEngine, but they do a fine enough job.

Of the two - Irrlicht is the better option. It has better documentation, and even an ebook and a lot of samples.

Both work in c++ and are very easy to install. Irrlicht also has the option to work with C#, though the books and examples are still in c++.

jbadams

Torque3D is actually one of the engines I considered in the past, very good to know it now became an open source.

I understand what you mean, but I see for example easing into 3D by starting with Unity for example a little bit of a waste of time if I have a clear plan to move on later to Unreal Engine 4.

Mathimetric

Yes I have thought about that. I've actually spent some time learning Ogre3D until the folks in the forum made me realize low-level programming is pretty much irrelevant to a Gameplay Programmer, or rather I better put my time into working on an existing 3D engine. If you have a different insight please do share.

cgx11

That answered many of my questions indeed thank you very much.

From what you're saying Unreal Engine 4 sounds like the obvious choice (in my eyes at least), think there's a chance it'll get released this year?

I've never heard of Infinity Universe before but it sounds like a very cool project.

I have no doubt I'll most likely get to work on different engines in the future, but developing my own from scratch (although crossed my mind) doesn't seem like the right choice if I'm planning to become a gameplay programmer.

Like I told Mathimetric - if you have a different insight please do share.

shay.yizhak

Irrlicht seems like a fine engine, which would you personally prefer - this one or Torque3D?

On a side note, are you by any chance from Israel?

well my insight is that, the definition of what makes an engine in the simplest form, has these basic things,

user key/joy/mouse controls (programmer defined),

user Graphic interface,

game data structures,

game load/save

game rules,

game models/textures (art)

;Ways to load and render such to the screen, and create a gaming experience.

;all you do as a programmer, is the following:

find your favorite 3d model editor/photo editor to create models/textures

create a program that parses and loads such data

create ways to animate the data (snap shot animation or skeletal matrix manipulation) and render it

create levels/terrain exetra

create rules, physics, boarders,

create GUI, and finally handle the controls.

once you have a method for above mentioned methods of design, you pretty much have yourself your

own engine.

Yes. It's indeed not impossible but it'll require me to stray off the the path to my goal too much.

Most of the things you mentioned if not all go under Engine Programming not Gameplay Programming, correct me if I'm wrong.

What I meant is if you have a different insight on Engine Programming not being beneficial to Gameplay Programming. If so, is it really worth the effort instead of focusing on more Gameplay Programming related subjects?

My goal at the moment is to become the best Gameplay Programmer I can be, rather than to make the best game I can possibly make - which obviously won't be able to compete with the big game companies. (hence I'm a little bit skeptic about creating my own engine, at least at the moment)

Royibernthal,

Glad I could help!

Yes I think UE4 will be released this year or at least early next year. Probably Nov-Jan release. You should download the UDK for version 3, so you can familiarize yourself with Unreal for a bit.

Infinity is an awesome project. Their engine is incredible, you can see what it's capable of here: http://www.inovaestudios.com/index.htm

I would agree with you that developing your own engine from scratch probably wouldn't be the right choice, but between now and the release of UE4 you have some time to expand your options. There is no harm in trying, especially if you want to add that to your resume.

I see, I definitely hope so. Should I familiarize myself with the tools, compiling their engine, etc? I don't see a point in learning Unreal Script, correct me if I'm wrong.

That project definitely sounds cool and innovative, nice idea to have infinite open spaces with no loading screens.

You seem pretty excited about it, are you related to it in any way or are you just a fan of the work?

Well, there's little harm in trying Losing time over something I'm sure I'm not interested in doing for a living. That time can be probably put to better use.

I was thinking about getting to know C++ better since I'm definitely going to need it.

If you have other ideas that'll help me become a better gameplay programmer they'll be much appreciated.

As you can see my mind is pretty much set on gameplay programming, so I hope it's understandable why I quickly reject ideas like creating my own engine.

Roylbernthal,

Yeah, that's a good plan - even if UE3 and UE4 are that different - a basic understanding of the engine's predecessor always comes in handy. But I think you're wrong about not learning unreal script. Realistically if you want to work with the Unreal Engine you'll need to learn the basics of Unreal Script at least. This is also good for your resume.

I'm a fan of the work, a good deal of my friends love sci-fi games and they all chat about Infinity Universe a lot. I just like the fact that despite all the competiton, people telling them it isn't possible, the lack of funding, etc - they're still building this crazy project. I think that shows a dedication of the people to the company, let alone a dedication to the fans and the industry. It's unusual to find that kind of thing in this market.

C++ is one of the hardest coding languages around but if you get to a good understanding of it then it'll open more doors with other languages. For instance, C++ and C# are incredibly alike. I'd definitely suggest giving it a crack.

"To become a better programmer" work hard at it and eventually you'll be the best you could be. Look at online guides, maybe buy a book on coding for UDK, read the gamedev forums every now and then - it'll keep you up to date. Practice makes perfect.

Speaking of Unreal Engine 4, have you heard of Project Awakened by Phosphor Game Studios? It's worth a look. http://www.kickstarter.com/projects/1312036782/project-awakened

If you ever have any other questions relating to the industry, coding, or so forth then you can always reach me by mail over gamedev. I'm more then happy to help with any questions you might have.

I wish you luck in the industry!

Why make poor decisions because of stupid, self imposed rules?

C++ is used for the system level code, and scripting engines and VMs are used for the actual game logic. This isn't slow. This has been done going all the way back to the 80s. Game logic is just content.

That's why engines like Unity3D and Unreal don't give C++ access. Because that part of the job is already done. The things that you would have written in c++ instead of the scripting language are already written and working.

cgx11

I'm a little confused, will UnrealScript still be used in Unreal Engine 4? If not, how will it be useful in it?

It's always great to see projects like that in the industry, it shows you that a small determined team can make great games.

Project Awakened looks very cool too. It's a shame that their Kickstarter funding failed, I hope they'll find another way to fund their project.

Thanks alot, it's good to know :)

Daaark

I see. Wouldn't big systems like inventory, quests and such be better off programmed in C++ rather than scripted?

I'm aware of that but I really do favor programming over scripting, even in cases in which it can be done both ways.

You have the tools to come up with more creative solutions to a problem when programming, not so much when scripting.

That is my experience, I may be wrong.

Would you say that as a gameplay programmer I'd encounter more scripting than programming?

From what I saw good gameplay programming positions usually require expertise in C++.

royibernthal, on 11 Mar 2013 - 05:57, said:
I see. Wouldn't big systems like inventory, quests and such be better off programmed in C++ rather than scripted?

This sentence doesn't make very much sense.

There is no distinction between programming and scripting that needs to be made. Scripting is only used as a context to describe the programming where you tell an existing program what to do, instead of the programming that is done to make the actual program in the first place. This allows a program to be small and fast, and just describe some basic object models. After that, it's handed off to the user to create scripting data to tell it how to behave.

Gameplay interactions have no business being in the engine code in the first place. The engine has it's own single area of responsibility. It manages memory, takes input, checks for collisions, draws the screen from a list of visible objects, etc. It doesn't need to know or care about your inventory system, or what a quest is, because they have nothing to do with it's job.

For instance, the engine has defined generic game objects, and triggers. It has events for when an object enters and exits a trigger. The user of the engine can hook into these events with a script.

The user can now write a script to define what happens when an object enters or exits a trigger area. The possibilities are almost endless, and any type of action can now occur without having to change the actual engine program.

The script becomes content, and can be loaded, swapped for new ones, and possibly modified on the fly. They will get trashed like any other data when they are not needed anymore.

Scripts are mostly safe, and usually will just be halted with an error message instead of crashing the whole program. Usually you just get bad behavior that you can isolate and fix quickly, and then you don't have to recompile your whole program. The script is just a file in a folder. No different than altering a texture or a sound.

If your inventory and quest systems are big and complicated, then you doing them wrong.

An inventory is a just a list of some custom data structure with a few functions to manage that list. When it comes time to draw the inventory, you just tell the GUI skin you customized what items to draw in what slots, and the engine takes care of adding it's standardized GUI with the correct image references to the render queue.

What if you don't want that? Tell the engine to draw your inventory items dangling from your belt by making one call to add the model to the scene graph.

What if you don't want that either? Tell the engine to draw a floating model of your inventory object on the top corner of the screen.

etc...etc...

I understand what you're saying and it does make sense.

You are right but the distinction I'm making is between full-fledged programming languages and simplified scripting languages. Less "tools" to use, correct me if I'm wrong.

An Inventory system is first and foremost a list of items, but you can always complicate stuff. Same goes for other gameplay related features.

Would you define Unreal Engine 4's new "Hot Reload" feature (C++) as scripting? It matches your definition.

http://www.unrealengine.com/unreal_engine_4/

If gameplay programmers are not expected to program in C++, why do gameplay programming positions require expertise in it?

Yeah, that inventory stuff is all simple programming. It is just a list. Complex ideas do not mean complex programming. Everything you mentioned is just a few lines of code attached to different events that reference that list. The code will more or less look the same in any language.

Scripting languages aren't dumbed down. They often aren't 'scripting' languages at all. They are full on languages that can do anything, and as I said in my post above, they are only called scripting languages in the context that they are being hosted in another program. They exist because they have different goals than C++. They let you model problems at their face value and ignore machine specific technical details that have nothing to do with the problem you are solving.

C++'s purpose is to be a portable language that targets system level programming. It's good at moving memory around and doing complex calculations really quickly. Other than ASM, it's the best too for that job. It can leave a lot to be desired in other areas though.

Other languages are better suited to different tasks, and to express different ideas. C++ is all about machine level details, but when the problems you are dealing with have nothing to do with those details, C++ can actually become a hindrance.

Sometimes you just want to process text and numbers at face value (instead of as char arrays, and numbers as objects with bit limits and sign issues). Sometimes you want 8 to just be 8, and not a representation of a 32-bit unsigned integer. Sometimes you want to deal with words and phrases, and not character arrays or strings. There are languages that can hand C++ it's own ass in these areas. That doesn't mean C++ is bad. It's just not what C++ was designed for out of the box, and it can't express those ideas as neatly and elegantly.

So it turns out that the best tool for the job is to use a C++ to solve the system level problems, and host a virtual machine to handle the actual game. The engine can then be small and fast and focus 100% on it's area of responsibility.

The scripts can be executed quickly, changed on the fly, without recompiling anything, and won't introduce bugs into the executable. The scripts also add almost infinite possibilities to what an engine can do. It's a win/win situation.

An engine will take 10,000 objects in a scene and do a quick collision detection pass on them. It will then generate a list of collision events, and hand them off to ->

The scripting engine, which will handle collision response. A script will fire and it will know which object it collided with, and have a data structure passed along with all the other relevant information. You object can now bounce, disappear, turn green, blow up, play a sound, trigger another event, generate code on the fly, or whatever else you come up with.

The engine does the detection because it's faster, it's technical, and it's standard behavior, not needing flexibility.

The script handles the response because it needs to be flexible and open ended. Most scripts will be dealing with event reactions, which are rules, and not technical details. These are not 'c++ / system level' problems.

Quote
Also, why do gameplay programming positions require expertise in C++?

It's an industry buzzword, and a C++ programmer can easily learn any other language. A C++ programmer will have experience dealing with systems on the low level, and can be switched around to different tasks with different amounts of required technical expertise. There are many different tasks in programming a game.

You may join as a scripter and only ever write lua/C#/java/python/etc scripts. However, when that task is complete, it's nice to be able to do other things, or you will become redundant when they don't need anymore of those scripts written.

C++ deals with the machine at a very low level. It's easy for a C++ programmer to jump into any higher level language and be somewhat productive immediately. Because it's all the same concepts, but you don't have to be as specific, and don't have to manage memory. It's harder for a someone without C++ knowledge to jump into C++ because you suddenly have to know how to think in terms of memory management and being specific.

I never said not to learn C++. I said it's not required to make a good, fast, game, and certainly not desirable to find a C++ only engine. You can use an engine and create tons of successful games without ever needing to write a single line of C++.