C# + AS3 + C++?

Started by
26 comments, last by Dirk Gregorius 6 years ago
9 hours ago, frob said:

Some of the first steps are to hire a large team of experienced editor-developers, and spend several million dollars over multiple years on technology developed across multiple studios around the globe.

EA has an enormous body of tech tools and libraries that cover just about anything you want. They've been built up for game after game, from project to project for decades.  When I was working there I noticed and pointed out a date in a comment. It was from nearly two decades earlier, the comment stated that it was the third rewrite and they were hoping it would be the version that would solve all their issues.  The tool worked great, we were adding our own useful bit of functionality which would be added to the suite.

I agree with you, but I want to be able to make things by myself. I know I can't match with EA and DICE, but I need to evolve.

Advertisement

Evolve to do what? If you're a beginner you shouldn't be making your own engine until you have spent some time learning how to use existing ones. Certainly you shouldn't base your implementation decisions on other people's job adverts because their existing technology is, as Frob said, the result of many years of different projects and different directions which they now have to maintain, not the ideal form that others should strive to emulate.

On 20.11.2017 at 12:36 AM, Kylotan said:

Evolve to do what?

To evolve as a programmer and engineer. To make better tech and understand how to implement particular algorithms from white paper and so on.

 

On 20.11.2017 at 12:36 AM, Kylotan said:

If you're a beginner you shouldn't be making your own engine until you have spent some time learning how to use existing ones.

But how Carmack, Sweeney and others did it?

 

On 20.11.2017 at 12:36 AM, Kylotan said:

Certainly you shouldn't base your implementation decisions on other people's job adverts because their existing technology is, as Frob said, the result of many years of different projects and different directions which they now have to maintain, not the ideal form that others should strive to emulate.

So their solutions and decisions they were made aren't good enough to be reimplemented by somebody else?
 

Carmack and Sweeney did not start out making 3D engines as a beginner. They made much simpler software until they had learned enough to be able to move onto more complex topics, and they did not write an engine until they had written several games and learned which parts of the game were reusable and which parts were not. You should do the same.

The tools and technologies that you see in a job advert indicate that company's own particular interests, history, resources, politics, and limitations. They tell us very little about which technologies are good, or suitable for beginners.

 

22 hours ago, Kylotan said:

You should do the same.

Which way is most suitable and usable?

I'd recommend one of two routes:

  1. Download an engine like Unity and get making flashy-looking games quite quickly, learning the high level concepts quickly and coming back to the low level concepts later on;
  2. Download a framework like SDL or Monogame and make simple-looking games quite quickly, learning the low level fundamentals early, and progressiving to bigger 'engine' level ideas later.
9 minutes ago, Kylotan said:

I'd recommend one of two routes:

  1. Download an engine like Unity and get making flashy-looking games quite quickly, learning the high level concepts quickly and coming back to the low level concepts later on;
  2. Download a framework like SDL or Monogame and make simple-looking games quite quickly, learning the low level fundamentals early, and progressiving to bigger 'engine' level ideas later.

Ok. So if I will start from first step the official engine documantation will be my first entry into game development? But what the main resource of tech and knowledge that guys at Epic games and DICE using? For example how they all figure out how to make 3d audio system? It's seems like there a very little information in the Internet and even less practical implementation in the C++. That's what makes me wonder every time..
Or maybe this is all about Bachelor/Master/PhD degree in computer science? Or maybe some cool books with code examples?
Unfortunatelly, I dont' have such degree - I'm self-taught.

Learning and understanding math is probably the most important asset when developing engines, especially back then. People like carmack used papers and reference books like Computer Graphics: Principles and Practice when developing there engines.

Carmack used papers by Bruce Naylor when writing the BSP tree used by the doom engine. He popularized the use of different techniques within games that nobody did before or at least as far as I know.

To summarize, engines are built from the work of many different people, usually people who specialise in specific areas or algorithms. From there papers engineers when the resources become available implement them practically in three respective fields. And that's basically no it goes, there's books on graphics,physics,collision etc. And those books wouldn't be possible without earlier research and that research without earlier discoveries in math etc. So it goes way back

1 hour ago, Jemme said:

And that's basically no it goes, there's books on graphics,physics,collision etc. And those books wouldn't be possible without earlier research and that research without earlier discoveries in math etc. So it goes way back

I agree. I noticed that game physics engines started to appear after 2 papers by David Baraff:
1. Analytical methods for dynamic simulation of non-penetrating rigid bodies;
2. Fast contact force computation for nonpenetrating rigid bodies;
Interactive Collision Detection – By Philip Hubbard
and Brian Mirtich, Impulse-based Dynamic Simulation of Rigid Body Systems.
That's all are very interesting topics for me. I'm interested in everything - graphics, physics, animation, audio, editor, visual node-graph scripting (a la blueprint), networking, etc. But if I want to dig in it seriously to make physics engine I will literately spend years for that and that will still far from "nice" physics engine. And I don't know what I should to do - just use tech from Epic games, Crytek, etc or try to link some kind of engine from available 3d party components (physX/bullet, vxgi, steam audio, etc)?
As Kylotan said I will start from just using other's tech right now. But I'm still interested in gathering more low-level information as foundation for future plans. 

1 hour ago, Jemme said:

Learning and understanding math is probably the most important asset when developing engines

So first I need to read "Eric Lengyel. Mathematics for 3D Game Programming and Computer Graphics"?

I learned math from tons of different books and articles, lengyel book is very mathy in the sense it's quite difficult to understand for non degree people. 

This book is a bit easier for newer people:

https://www.amazon.co.uk/Foundations-Game-Engine-Development-Mathematics/dp/0985811749/ref=sr_1_1?ie=UTF8&qid=1512679107&sr=8-1&keywords=Eric+lengyel

I would say figure out your purpose for doing this, what exactly do you want to do this for? That answer will decide the path you take, for example if you want to be a render programmer just build a render , physics ? Then use someone else's render engine and just do the physics.

If you want to do everything then break it down for example I'm building a framework a bit like SDL and SFML but with more render APIs and custom physics. The key is that is NOT an engine it's not as big as something like unity or unreal but will be modern rendering etc.

You can then add the "engine" separately to supply scene manager , entity systems etc.

Splitting them apart makes it alot easier to develop.

Check SFML and SDL source, look at XNA structure and check out eberly engines:

https://www.geometrictools.com

 

This topic is closed to new replies.

Advertisement