How long would it take to...

Started by
21 comments, last by James Miller 11 years, 3 months ago

That's not what I use it for (nor what the article actually says, if you ignore your knee-jerk reaction to the title and really read it).

I don't think this article should be used to smack people in the face who want to write an engine and I don't think it should be put on any kind of game development pedestal.

I'm merely pointing out a trap a lot of newcomers fall into, and sure, if the OP is purely looking for a learning exercise, then no one will stop him, but it never hurts to inform. If the OP had asked about "a primitive, but functional 3d game, something on par with say, the original QUAKE or Half-Life 1" I wouldn't have mentioned it at all...

I have to agree with you on this one swift coder. People need to be made aware of complications and heart aches of what they are getting in to and they need to weigh those equally or even more so critically than the idea that things are easy. I seem to have been on a rampage of "Game Development is hard!" today (probably just gripes coming up from a difficult week) but it's still something VERY valid to say.

Engines power games yes, games can get very complex and time consuming yes. This is my big argument when it comes to building games and engines together. Simply put engines are extremely complicated maybe even the most complicated things that are ever coded. Games can also be complicated and in some cases just as complicated as building the engine they are powered by. This is why to me it's NEVER a good idea to do both. If you want to make an engine just to learn things and your making a game using it just to see how it all ties together, great! If you want to make an engine that other people may actually use is another story all together. You will need to invest LOT's of time on making it high performance, easy and providing a wide range of tools.

Game content, development, coding and logic are also complicated and at times can take quite a large time investment. Same as with the engine if your just doing the game to learn how things work and your coupling it with the development of a simple engine GREAT! However if you want to get other people to actually play your game (not just test it for you but actually play it) you need to put in some effort and make it worth playing (keep in mind there is a lot of competition out there and tons of really good games).

So here's where I jump in on the argument between making engines and making games. Both are required and both have nearly equal importance to each other. That is to say without better engines we don't get better games. Without better games we don't advance the engines to power them. However when we get into the world where everyone builds their own engine and their own game at the same time we completely negate the first statement of this paragraph. You build the engine to power your game and you build your game to run well on your engine and neither receive the proper attention that they deserve! So my opinion on this whole thing is the more people try to do everything the more nothing gets advanced. To me the argument isn't saying you can't build an engine it's that it requires just as much if not more dedication than the game itself. As independent and or a small game studios we simply can't afford to take a year and a half to make a half way decent engine followed by another year and a half to complete the game itself and by the time we hit the shelves we're 2 - 3 years behind all the competition in performance and quality! Even the larger studios that do build their own in house engines to go with their games have two different departments. One focused entirely on the engine itself and another focused entirely on the game itself.

So if it's just for hobby then writing an engine is perfectly fine. If there's any concern for profit you need to compete with the big boys who are dumping money into the development of their engines by the truck load. Your one or two people working in your spare time you'r not likely to ever get on par with them. However making a game with two or three people can be profitable... Make a few games and get some money coming in first then take your experience and knowledge from making games and apply it to making the engine that powers them. When you do make that leap into making the engines make sure that those involved are dedicated to just that and not the both at the same time (otherwise you will end up cutting corners and sacrificing performance and tools that will lead to loss of money and less chance or sales).

Dan Mayor

Professional Programmer & Hobbyist Game Developer

Seeking team for indie development opportunities, see my classifieds post

Advertisement

Its not a question of "how long" but "how to go about it". You'll find your own pace, and if you are smart about which areas you choose to tackle first, it might only take two or three years.

The "Quake" engine is certainly not a terrible long-term goal, but I'd recommend looking at the goal of making a Wolfenstein3D style ray-caster engine before even thinking about a full 3D engine. All you need is the ability to draw a pixel on the screen and obtain keyboard(possibly mouse) input. The maths and programming skill required is slim and is a much more manageable project.

I'd learn(in order) C++, Software Development/Engineering, Maths(Trig & Algebra) and WindowsAPI(if you are using Windows).

Languages; C, Java. Platforms: Android, Oculus Go, ZX Spectrum, Megadrive.

Website: Mega-Gen Garage

Its not a question of "how long" but "how to go about it". You'll find your own pace, and if you are smart about which areas you choose to tackle first, it might only take two or three years.

The "Quake" engine is certainly not a terrible long-term goal, but I'd recommend looking at the goal of making a Wolfenstein3D style ray-caster engine before even thinking about a full 3D engine. All you need is the ability to draw a pixel on the screen and obtain keyboard(possibly mouse) input. The maths and programming skill required is slim and is a much more manageable project.

I'd learn(in order) C++, Software Development/Engineering, Maths(Trig & Algebra) and WindowsAPI(if you are using Windows).

Thanks for the response, that's very useful to me and has helped me a lot.

I guess I messed up my initial terminology in my earlier posts, I guess I was, in my head, referring to a "Game engine", not a generic 3d engine. A game engine being something like Shadowcaster, Source Engine, etc.

But I'd love to try what you suggested. My first game goal would be to make the unfinished Wolfenstein 3d sequel "Rise of the Triad" -> http://www.3drealms.com/rott/originalspec.html

In looking at the source code for wolf3d, Carmack notes some interesting areas I'd love to explore, such as variable wall heights etc.

But I'd love to try what you suggested. My first game goal would be to make the unfinished Wolfenstein 3d sequel "Rise of the Triad" -> http://www.3drealms....iginalspec.html

In looking at the source code for wolf3d, Carmack notes some interesting areas I'd love to explore, such as variable wall heights etc.

I'm not sure where you are in your learning, but I think this is too much of a goal if you just started. Here's my two cents about the whole questions about learning programming.

Learning programming up to the point of mastery can be divided into four major parts:

  1. The first part for the Average Joe is to learn the actual programming. For people who have never programmed in their life before, it actually is hard for them to grasp the concept of writing instructions. Computers follow instructions down to the exact steps. It doesn't question, it doesn't disobey. So programmers, must write the instructions correctly, line by line, and this is hard for Joe. If you ask Joe to write a code that "Ask for a number and print that number.", don't be surprised if Joe asked back "Shall I use for-loop?" I have experienced this first-hand teaching newbies programming.

    Programming is a weird concept for Average Joe. Being able to compose instructions together that make sense, and make up a usable program, actually takes time to learn and master. Actually, I have observed that some Computer Science graduates can't still write a program from scratch. They can read code, they can change code, but they can't write it from scratch. Yes, the so-called programmers can't program.
  2. Joe's next hurdle is to master programming languages. This is all about "learning C++/Java/C/Python" and all that stuff. Knowing the syntax, what they do, and when to use them is no easy feat. This, by itself, may take a year or two for any programmer to master a language. Over the course of Joe's career as a programmer, Joe will find himself learning multiple programming languages.
  3. Then there's the third part, the library/API part. Learning this is similar to learning a programming language. As a matter of fact, some programming languages come with extensive range of API. Some others (like C/C++) don't. This is where Joe learns how to draw stuff on screen, how to play audio files, etc.
  4. The fourth part is to master software architecture. This require considerable amount of experience, and I'm pretty sure vary by person and experience. I have programmed for more than 20 years, and it's only just recently that I got *it*. By the time I got that "aha" moment, I have learned about 8 different programming languages, completed about a dozen personal games, and released about two-three commercial games.

Obviously, these four parts don't necessarily have to happen before one another. They are all learned simultaneously. You could go back to part 2 if you just picked up a new language, for example.

I think, only after you have mastered all four, of a particular programming language of a particular API, you are qualified to make an "engine". Knowing C++ inside out doesn't not make you qualified to make an engine in Java. I'm not saying you shouldn't make one. I'm not stopping you from making one as long as it's for your own personal use and learning purposes. It's a great learning experience. Just keep in mind that whether it's a "game engine" or a "3d engine", making it is no easy task, especially for the Average Joe.

But I'd love to try what you suggested. My first game goal would be to make the unfinished Wolfenstein 3d sequel "Rise of the Triad" -> http://www.3drealms....iginalspec.html

In looking at the source code for wolf3d, Carmack notes some interesting areas I'd love to explore, such as variable wall heights etc.

I'm not sure where you are in your learning, but I think this is too much of a goal if you just started. Here's my two cents about the whole questions about learning programming.

Learning programming up to the point of mastery can be divided into four major parts:

  1. The first part for the Average Joe is to learn the actual programming. For people who have never programmed in their life before, it actually is hard for them to grasp the concept of writing instructions. Computers follow instructions down to the exact steps. It doesn't question, it doesn't disobey. So programmers, must write the instructions correctly, line by line, and this is hard for Joe. If you ask Joe to write a code that "Ask for a number and print that number.", don't be surprised if Joe asked back "Shall I use for-loop?" I have experienced this first-hand teaching newbies programming.

    Programming is a weird concept for Average Joe. Being able to compose instructions together that make sense, and make up a usable program, actually takes time to learn and master. Actually, I have observed that some Computer Science graduates can't still write a program from scratch. They can read code, they can change code, but they can't write it from scratch. Yes, the so-called programmers can't program.
  2. Joe's next hurdle is to master programming languages. This is all about "learning C++/Java/C/Python" and all that stuff. Knowing the syntax, what they do, and when to use them is no easy feat. This, by itself, may take a year or two for any programmer to master a language. Over the course of Joe's career as a programmer, Joe will find himself learning multiple programming languages.
  3. Then there's the third part, the library/API part. Learning this is similar to learning a programming language. As a matter of fact, some programming languages come with extensive range of API. Some others (like C/C++) don't. This is where Joe learns how to draw stuff on screen, how to play audio files, etc.
  4. The fourth part is to master software architecture. This require considerable amount of experience, and I'm pretty sure vary by person and experience. I have programmed for more than 20 years, and it's only just recently that I got *it*. By the time I got that "aha" moment, I have learned about 8 different programming languages, completed about a dozen personal games, and released about two-three commercial games.

Obviously, these four parts don't necessarily have to happen before one another. They are all learned simultaneously. You could go back to part 2 if you just picked up a new language, for example.

I think, only after you have mastered all four, of a particular programming language of a particular API, you are qualified to make an "engine". Knowing C++ inside out doesn't not make you qualified to make an engine in Java. I'm not saying you shouldn't make one. I'm not stopping you from making one as long as it's for your own personal use and learning purposes. It's a great learning experience. Just keep in mind that whether it's a "game engine" or a "3d engine", making it is no easy task, especially for the Average Joe.

As for prior knowledge, I've got a working knowledge and understanding of BASIC, and C. I designed and programmed the Command Line Interface of East-NSW TAFE college, and built a very very basic DOOM clone in QBASIC. The fourth image isn't my own work however, but that of Ken Silverman. I was toying around with his 3d engine written entirely in QBASIC which was quite fun to toy with, similar to the Wolf3d engine. Mind, the BASIC stuff like the Doom engine was done years ago when I was nearly a toddler so it's not fantastic, but I've re-invigorated my love for wanting to make an engine.

gsZ4J1l.png

buBO2pR.png

hZfYaGV.png
ARGRWM4.png

DKnvvAk.png

The API part is what I was curious about, that's what I always wondered about, as I never found anything in all of my C++ textbooks about how to actually *draw something* on the screen, even a single pixel. Regardless, I'm curious and eager to delve into it and see what I can come up with, but I'll be happy with getting one good solid program done, even if it's no more than a simple calculator. Progress motivates me, and getting started was always the hard part for me, but once I start making even a slight tinge of progress (ie, something actually works when I compile it!) then I tend to just steam along after that.

The API part is what I was curious about, that's what I always wondered about, as I never found anything in all of my C++ textbooks about how to actually *draw something* on the screen, even a single pixel.

C++ is purely a programming language - it knows nothing about abstract constructs like 'screens' or 'pixels'.

You will need to use a library that exposes such functionality (something like SDL or pixeltoaster)

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

The API part is what I was curious about, that's what I always wondered about, as I never found anything in all of my C++ textbooks about how to actually *draw something* on the screen, even a single pixel.

C++ is purely a programming language - it knows nothing about abstract constructs like 'screens' or 'pixels'.

You will need to use a library that exposes such functionality (something like SDL or pixeltoaster)

So what would've the early 3d game developers (ie again, Carmack working on Wolf3d) have used? Did they write their own libraries or were these kinds of resources available back then?

If you really want to do it from zero, then it will be rather a long journey than a simple "project". If you have plenty of time and motivation then you`ll have nice results in 2-3 years(depending on how good you are at maths/3D maths.)

-You not just have to learn C++ ...but OOP prorgramming itself, lots of maths, 3D maths, physics, directX / openGL, (a sound API and networking ...optionally) etc.

If you dont wanna create your own 3D models ....just import them from an other program ...thats saves a lot of time.

-It makes more sense to build up your engine incrementally and create actual games along the way, ....cause you can spend months with working on things that make your engine more solid but dont add anything to the graphics. .....it can be quite demotivating.

-And you need to have 2D projects too. ....with many things its better to have a good understanding of them in 2D before doing the dimension jump:)

....anyway Wolf 3D and Doom1 are not really 3D games, but 2D games with 3D(ish) graphics.

So what would've the early 3d game developers (ie again, Carmack working on Wolf3d) have used? Did they write their own libraries or were these kinds of resources available back then?

Back in the days of DOS, the hardware was a lot simpler, and the OS didn't prevent user code from accessing the hardware directly. You could map the framebuffer into memory and write directly to it.

These days the hardware is infinitely more complex, and hundreds of processes may need to be drawing to the screen at the same time, so the OS and graphics drivers work very hard to insulate you from all that. You can't get any lower-level than the OS-specific drawing or 3D API - libraries like SDL just abstract across the many different OS-specific APIs that accomplish the same thing.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

If you really want to do it from zero, then it will be rather a long journey than a simple "project". If you have plenty of time and motivation then you`ll have nice results in 2-3 years(depending on how good you are at maths/3D maths.)

-You not just have to learn C++ ...but OOP prorgramming itself, lots of maths, 3D maths, physics, directX / openGL, (a sound API and networking ...optionally) etc.

If you dont wanna create your own 3D models ....just import them from an other program ...thats saves a lot of time.

-It makes more sense to build up your engine incrementally and create actual games along the way, ....cause you can spend months with working on things that make your engine more solid but dont add anything to the graphics. .....it can be quite demotivating.

-And you need to have 2D projects too. ....with many things its better to have a good understanding of them in 2D before doing the dimension jump:)

....anyway Wolf 3D and Doom1 are not really 3D games, but 2D games with 3D(ish) graphics.

Sounds like an ideal plan, and yeah I'd begin with simple 2d engines, games etc at first, learn how it all slots together etc. I guess I wouldn't expect to be able to make a Wolf3d clone for a few years yet, but it's my goal. I dream of being able to make just some kind of generic 3d fps engine, even if it was never good enough to be sold or used commercially, just something to toy with and use to learn, but it's one of the things that's on the cards for the next decade of my life, or optimistically, 5 years.

As for 3d models, I should be able to build most of them myself, I've done a level design, 3d modeling and 3d animation before. I've done a bucketload of mod work over the last 10 years in Doom/2, Build engine, Source Engine and Unreal. Have also built a lot of special effects, so it would be fun to play around with some of these aspects from the coding side of things once I get the hang of it.

2-3 years sounds good, nothing good comes easy or fast, it just relieves me to know that it's not some 10 year endeavour, I don't want to end up making something half decent by the time my life is already more than halfway over.

Still, thanks for all the answers guys! I know I haven't replied to all of them but I've read all your responses.

This topic is closed to new replies.

Advertisement