Making an Engine...
Author
Hello ;)
Right to it:
I'm going to create a game engine.
I've never programmed anything beyond the very useless applications I had to do in school using trueBASIC, or websites.
I'm fairly decent at trueBASIC.
I would say im definatly not the worst, perhaps a moderatly ok php/XHTML, programmer*.
I can cope sufficiently with SQL, at least enough for the purposes of web development.
I have VERY limited knowlage of C++, and Java. (Though i've made a few programs with both that were only usefull to get to grips with the languge.)
I will be 17 this year, and i'm in no hurry whatsoever to complete this game engine within the next say 6 years. I have my advanced highers this year (last year at high school in scotland) and university afterwards, so i really dont care about the time it will take ;)
Everything except from the trueBASIC above i've learned of the internet and books.
I really like learning new things (Not so excited about knowing them).
The problem:
I dont know where to start. :P:P (Yeah, i do think thats quite funny :D)
I want the engine to be used in 3D games, (preferably networked ones like halfLife, and also MMORPGs like Runescape(if its an RPG...) and EL etc.)
I want the games to be able to be created with drag n drop type of editors that are used 'in' the game while its running.
I want the games/objects/maps etc. to be able to be scripted and compiled while the game is running.
(The last two have MORGs in mind and -i hope- would make downtime while updating unnecessary).
What I would like from you(the person who is reading this and probably will come up with some witty response as to why i shouldn't do this):
What would you suggest as good languages to learn for this, and where to start; Graphics, Physics, AI, Scripting... whatnot?
If you could give clear reasons why so would be nice ;)
If you could give clear reasons why not, also would be nice :)
As a note:
I don't whatsoever want to use parts of other folks' engines, thats not to say i wont accept help with this ;)
I really don't mind insults, so feel free to poke fun ;)
*Im not sure on the actual term for this, is it programmer, or speaker, or linguist? :D
Ta,
-Zatarg
Edit: Forgot the title... can't be a good start.
C# seems to be a popular language to start with, personally I don't like .NET very much though so I stick to C++. It is admittedly a difficult and quirk-filled language though, so I might stick to something like Python until you're a bit better versed in general programming practices. For the future though, C++ or C# is probably your best bet to be learning and making this engine in.
From my own experiences in designing an engine - DON'T design an engine just to make one. I tried that, and it turned out horribly. You end up trying to design your engine for the most general case, and so you're basically coding that one component forever, and most of the time it doesn't even work.
My suggestion would be to start off by creating a simple game. Try to make the code reusable, but don't concentrate on it, concentrate on getting the game finished. When you finish, look at the code and try to strip out the reusable portions, then use those to build another game. Continue building up these reusable portions through a number of games and eventually you'll have a somewhat general engine. This is working great for me so far, and it makes for much less discouragement as you're producing tangible results with each game.
From my own experiences in designing an engine - DON'T design an engine just to make one. I tried that, and it turned out horribly. You end up trying to design your engine for the most general case, and so you're basically coding that one component forever, and most of the time it doesn't even work.
My suggestion would be to start off by creating a simple game. Try to make the code reusable, but don't concentrate on it, concentrate on getting the game finished. When you finish, look at the code and try to strip out the reusable portions, then use those to build another game. Continue building up these reusable portions through a number of games and eventually you'll have a somewhat general engine. This is working great for me so far, and it makes for much less discouragement as you're producing tangible results with each game.
Quote:
I'm going to create a game engine.
That's not a good idea. Sorry.
You cannot make a game engine -- especially one that you're envisioning -- without experience or requirements. You lack the former, which means you cannot adequately develop the latter. I've written recently on why you should write games not engines already a number of times on these forums, so I'll just send you to the links rather than repeat myself.
However, the upshot is that if you want to ever produce anything, you have to write multiple games and refactor your common engine code out from underneath them. To do otherwise is folly. Read these threads:
Engine Coding
Gaming Engine
Rate My Engine
Quote:
I will be 17 this year, and i'm in no hurry whatsoever to complete this game engine within the next say 6 years.
That's six years down the drain for one product that will be poorly written, poorly designed, and outdated by the time you're done. Not very impressive on a resume. It doesn't matter how dedicated or ambitious you think you are right now -- you will fail if you try to jump right in like this. You need to walk before you can run.
Quote:
I have VERY limited knowlage of C++, and Java. (Though i've made a few programs with both that were only usefull to get to grips with the languge.)
I'd recommend you use the tools you know -- if you know C++ or Java, even a little bit, work with those instead of trying to learn something completely new. However, if you insist, I'd recommend C# or Python.
[Edited by - jpetrie on May 25, 2007 1:06:20 PM]
Making a game engine is a massive endeavour usually undertaken by a team of programmers, rather than an individual; much less a beginner at programming. I wish you the best of luck in your endeavour, you're going to need it.
If you want to have a higher chance of success, start small and build your way up to a full game engine. 2-3 actual small games, completed fully and polished, under your belt and you'll find it much easier to build a simple game engine from scratch. Why waste time on a convoluted generic engine at the start when you can actually go out and make small games first? That way you have something cool to show for all your efforts. Later you can work on an engine which will be much more impressive and effective. I say this because I hate to see such enthusiasm as you have go to waste.
Furthermore, if you are serious about making games, get yourself good grades in higher mathematics (A or B grade) and apply for a degree in Computer Games Technology at the University of Abertay. The degree is a no-nonsense degree which will take you from knowing basically nothing about programming to being a halfway decent game programmer in 4 years. One note: they will NOT accept you if you do not have an A or a B in mathematics at advanced highers level. I've spoken to the lecturers personally, and I've just finished the course this year. They won't even look at an application with mathematics less than a B grade. The mathematics in the course is VERY difficult, especially at 4th year, so an excellent foundation in high-school mathematics is essential.
Other degrees such as those at Teesside and Hull are equally as good but I don't know about their entry requirements. (Teesside appears to have lower mathematics requirement for entry with only a C grade required)
[Edited by - Leo_E_49 on May 25, 2007 11:11:24 AM]
If you want to have a higher chance of success, start small and build your way up to a full game engine. 2-3 actual small games, completed fully and polished, under your belt and you'll find it much easier to build a simple game engine from scratch. Why waste time on a convoluted generic engine at the start when you can actually go out and make small games first? That way you have something cool to show for all your efforts. Later you can work on an engine which will be much more impressive and effective. I say this because I hate to see such enthusiasm as you have go to waste.
Furthermore, if you are serious about making games, get yourself good grades in higher mathematics (A or B grade) and apply for a degree in Computer Games Technology at the University of Abertay. The degree is a no-nonsense degree which will take you from knowing basically nothing about programming to being a halfway decent game programmer in 4 years. One note: they will NOT accept you if you do not have an A or a B in mathematics at advanced highers level. I've spoken to the lecturers personally, and I've just finished the course this year. They won't even look at an application with mathematics less than a B grade. The mathematics in the course is VERY difficult, especially at 4th year, so an excellent foundation in high-school mathematics is essential.
Other degrees such as those at Teesside and Hull are equally as good but I don't know about their entry requirements. (Teesside appears to have lower mathematics requirement for entry with only a C grade required)
[Edited by - Leo_E_49 on May 25, 2007 11:11:24 AM]
Quote:Original post by jpetrieSeconded. Writing actual games will be a more productive use of your time and will give you an idea of what features you actually need and how to design them; if you start off immediately trying to write an engine from scratch you'll essentially be guessing at what you should include and how it should be implemented.
[...]
However, the upshot is that if you want to ever produce anything, you have to write multiple games and refactor your common engine code out from underneath them.[...]
As you'll be learning at the same time as you code you'll also likely get things wrong along the way and/or learn better/different ways to do things, and you'll likely be more inclined to do the right thing and scrap or rewrite the bad pieces of code if they're part of a smaller game that isn't your final goal than if they're part of the engine that is your dream project.
You don't want to use functionality from anything else? Boy, then you have a massive road ahead of you. I'd highly recommend using at least an API or two for graphics... DirectX or OpenGL or both. Only language I can recommend is C/C++ since they're the only ones I've used.
I started out just "making a game" instead of an engine also. If you can divide the basic functionality(eg how resources are loaded )of your game from the game specific code(eg certain AI behavior of enemies ) then I'd say you could start on an engine but if you're anything like me when I first started your code will be a horrible mess unless you've gone over, understand, and excercise good programming practices along with modular programming.
you could start with making a small engine and use that in a small game as long as you plan ahead. I like to aim high myself and if you do always just make small games you'll end up never getting the experience you seek. You'll have to make the leap eventually to a mega engine but making at least one smaller one first is probly a good idea to get the jist of how it's done since you have no previous experience.
I started out just "making a game" instead of an engine also. If you can divide the basic functionality(eg how resources are loaded )of your game from the game specific code(eg certain AI behavior of enemies ) then I'd say you could start on an engine but if you're anything like me when I first started your code will be a horrible mess unless you've gone over, understand, and excercise good programming practices along with modular programming.
you could start with making a small engine and use that in a small game as long as you plan ahead. I like to aim high myself and if you do always just make small games you'll end up never getting the experience you seek. You'll have to make the leap eventually to a mega engine but making at least one smaller one first is probly a good idea to get the jist of how it's done since you have no previous experience.
There are game engines and game frameworks and game libraries - in decreasing order of specialization. An engine is typically a fairly large, advanced, reusable set of funcionality aimed at supporting 1 type of game (for example a FPS engine, a RTS engine, a 4X TBS engine), the reason engines normally only support 1 game genre (or a few very similar genres) is that coding is all about making choices, you can have bigger maps or more detail, you can have smarter AI decisions or more AI units running around, you can have open ended destructable maps or you can have map queues that let the AI make better decisions quicker. As such, no 1 program can be the best at everything - in fact no one set of options can even be decent at everything.
Below the engine is a framework ... a less single-minded set of code for standard things like raising game events the AI can respond to, systems for trying animations and sound to game events, support for deformation of terrain, spawing of game objects, etc.
Below the engine is a library. Mostly seperate bits of functionality that each do 1 thing - very well. functions to load sounds and images, models. Functions to establish network connection. Threading code, memory management, timing and debuging code. Everything that you wish Microsoft or whoever had already written for you, but that they didn't (or didn't write well).
So, first you start with a MINIMAL and very very clear and focused goal. Usually a very specific game. And you create the engine FOR THAT GAME. The reason is, when its 5am on a sunday morning and you simply can't figure our whether to add support for acurate angualar momentum simulation, or AI personality plugins, its the GAME that will help you answer the question.
Each application exists for a purpose, and a game engine exists solely to be easier to use to make games than starting from scratch. As such, you prioritize your engine's features according to the needs of today's game. You will get to advanced features needed by tommorow's game, tommorow. The game and the engine are a symbiotic pair. You cannot make a "good" game engine, unless you have some meaning for judging its goodness.
So if you are going to make a tic-tac-toe game, the kinds of things you support in your engine / framework / library are probably stuff like saving / loading game files, and either basic networking or simple AI support. Displaying on a screen, playing sound, etc. As your tic-tac-toe evolves, you decide to then write more 2D board games, so your engine gets cooler, more generic concepts for supporting multiple games, better sound handling, maybe internet score tracking, who knows, whatever you want to do next.
And year after year, game after game, you find that you have an engine / framework / library which lets you drag-and-drop 3D object's into an in-game level editing mode, tweaking your online game content with no downtime.
But I promise you, you don't start at the end, you see the journey in front of you, and then you plot a coarse to the nearest safe haven toward your destination.
Another thing people forget is that in self-development, each leg of the adventure is financed by the profits from the previous legs. (In terms of successfully development of usable code and skills and continued motivation to go on). You do not have the funding (skill) to set out to Alpha Centari directly, you must first get a plane in the air, then an airplane industry, then space travel, a space station, moon landings, asteroid mining companies, and finally ... probably 2-5 years down the road - you will have the resources to start that long final voyage to your destination (bringing together all your code and knowledge into a real workable product, that has all those nice features you list in your post and that someone would find usefull for building games with).
Good Luck.
Below the engine is a framework ... a less single-minded set of code for standard things like raising game events the AI can respond to, systems for trying animations and sound to game events, support for deformation of terrain, spawing of game objects, etc.
Below the engine is a library. Mostly seperate bits of functionality that each do 1 thing - very well. functions to load sounds and images, models. Functions to establish network connection. Threading code, memory management, timing and debuging code. Everything that you wish Microsoft or whoever had already written for you, but that they didn't (or didn't write well).
So, first you start with a MINIMAL and very very clear and focused goal. Usually a very specific game. And you create the engine FOR THAT GAME. The reason is, when its 5am on a sunday morning and you simply can't figure our whether to add support for acurate angualar momentum simulation, or AI personality plugins, its the GAME that will help you answer the question.
Each application exists for a purpose, and a game engine exists solely to be easier to use to make games than starting from scratch. As such, you prioritize your engine's features according to the needs of today's game. You will get to advanced features needed by tommorow's game, tommorow. The game and the engine are a symbiotic pair. You cannot make a "good" game engine, unless you have some meaning for judging its goodness.
So if you are going to make a tic-tac-toe game, the kinds of things you support in your engine / framework / library are probably stuff like saving / loading game files, and either basic networking or simple AI support. Displaying on a screen, playing sound, etc. As your tic-tac-toe evolves, you decide to then write more 2D board games, so your engine gets cooler, more generic concepts for supporting multiple games, better sound handling, maybe internet score tracking, who knows, whatever you want to do next.
And year after year, game after game, you find that you have an engine / framework / library which lets you drag-and-drop 3D object's into an in-game level editing mode, tweaking your online game content with no downtime.
But I promise you, you don't start at the end, you see the journey in front of you, and then you plot a coarse to the nearest safe haven toward your destination.
Another thing people forget is that in self-development, each leg of the adventure is financed by the profits from the previous legs. (In terms of successfully development of usable code and skills and continued motivation to go on). You do not have the funding (skill) to set out to Alpha Centari directly, you must first get a plane in the air, then an airplane industry, then space travel, a space station, moon landings, asteroid mining companies, and finally ... probably 2-5 years down the road - you will have the resources to start that long final voyage to your destination (bringing together all your code and knowledge into a real workable product, that has all those nice features you list in your post and that someone would find usefull for building games with).
Good Luck.
Many technogies are good, and knowing more than 1 rarely hurts ... so experiement a lot.
Personally I use C++, C# and ruby myself because between the 3 there is nothing I feel I am missing.
If you like low level, fast, to-the-metal coding. C++ is the best choice for fun. But that does NOT mean you need to know it. Feel free to skip C++ for a higher level language if you aren't fond of it - early in programming it is more important to learn 1 language well, than to know a particular language at all.
If you would like a generally broad usefull language, that might also get you jobs outside of games ... my top recommendation is C#. Java is a good alternative also. The key is that these languages are simpler, more RAD development languages than C++ (although a C++ expert can do just as much as a Java expert, it usually takes that C++ expert a few more years to become that good and learn the libraries (boost and such) that make it possible). I like C# in this space because of Microsoft's free Visual C# Express Edition and XNA development studio. Also look into the Tao Framework for accessing game libraries like OpenGL from .NET.
Then there are the super light dynamic langauges. Python and ruby are the main 2 these days. Python is better implemented, faster, more well supported and better documented. Python has great support for basic game libraries to get started with, and can grow / scale up to full fledged apps fairly well. But I use ruby, it just feels right to me. Even after the last major improvement ruby is nearly twice as slow as python in some cases. And currently (but not for too long I expect) ruby still has a kinda messed up mutli-threading system. But I get small little pieces of stuff written in 4 hours of ruby that would take me 3-4 days in most other languages.
Normally I write my main apps in C#, my helper scripts and test code in ruby, and my core game models in C++ (just because I am super fast at modeling complex relationships using C++'s templates) - truthfully I use C++ templates to prototype my idea, then I usually code it in C# with .NET components and interfaces (backwards from the old ways of doing it I know).
I recommend you pick up some DirectX (windows only) or OpenGL (cross platform). And either DirectSound or OpenAL. You might start with either SDL or XNA (.NET only). When getting into networking mybe something in SDL networking, XNA networking, or just raw WinSock would work - skip DirectPlay its mostly useless. For 3D scene graphs you may like Ogre3D (C++) or Irrlicht (a .NET engine) - although that might be like using someone elses "engine" there is no such things as starting "from scratch" anymore. So you will have to investigate what's out there, and what you personally want to write vs. use. As well as what their licenses are (as I'm sure you don't want any restrictions placed on what you do with your engine).
Personally I use C++, C# and ruby myself because between the 3 there is nothing I feel I am missing.
If you like low level, fast, to-the-metal coding. C++ is the best choice for fun. But that does NOT mean you need to know it. Feel free to skip C++ for a higher level language if you aren't fond of it - early in programming it is more important to learn 1 language well, than to know a particular language at all.
If you would like a generally broad usefull language, that might also get you jobs outside of games ... my top recommendation is C#. Java is a good alternative also. The key is that these languages are simpler, more RAD development languages than C++ (although a C++ expert can do just as much as a Java expert, it usually takes that C++ expert a few more years to become that good and learn the libraries (boost and such) that make it possible). I like C# in this space because of Microsoft's free Visual C# Express Edition and XNA development studio. Also look into the Tao Framework for accessing game libraries like OpenGL from .NET.
Then there are the super light dynamic langauges. Python and ruby are the main 2 these days. Python is better implemented, faster, more well supported and better documented. Python has great support for basic game libraries to get started with, and can grow / scale up to full fledged apps fairly well. But I use ruby, it just feels right to me. Even after the last major improvement ruby is nearly twice as slow as python in some cases. And currently (but not for too long I expect) ruby still has a kinda messed up mutli-threading system. But I get small little pieces of stuff written in 4 hours of ruby that would take me 3-4 days in most other languages.
Normally I write my main apps in C#, my helper scripts and test code in ruby, and my core game models in C++ (just because I am super fast at modeling complex relationships using C++'s templates) - truthfully I use C++ templates to prototype my idea, then I usually code it in C# with .NET components and interfaces (backwards from the old ways of doing it I know).
I recommend you pick up some DirectX (windows only) or OpenGL (cross platform). And either DirectSound or OpenAL. You might start with either SDL or XNA (.NET only). When getting into networking mybe something in SDL networking, XNA networking, or just raw WinSock would work - skip DirectPlay its mostly useless. For 3D scene graphs you may like Ogre3D (C++) or Irrlicht (a .NET engine) - although that might be like using someone elses "engine" there is no such things as starting "from scratch" anymore. So you will have to investigate what's out there, and what you personally want to write vs. use. As well as what their licenses are (as I'm sure you don't want any restrictions placed on what you do with your engine).
Some ideas:
I suggest you take a look at enguinuity to get an idea of how you make an engine skeleton that is extendable and well rounded off. I'm not saying C++ is a good idea though, I just think it will give you some good ideas for a modular design.
Once you have a solid kernel you can start writing small modules that you load and unload from there. Make the kernel simple and compact. Not much more than a simple command line with a load/unload module command.
Everything from there would be small and well defined modules written as dynamic link libraries. You would have to figure out how to cope with dependencies, like you can't load a module that depends on a sound module if you haven't loaded a sound module yet.
I suggest using a high level language that will allow you to embed a low level language where high performance is paramount. If such a thing exist...
I don't have much experience with this kind of thing myself but I have been onto the idea. Don't be supprised if you are an expert before you get anything like this up and running ;)
edit:
As Xai said (while I was busy writing) your engine is not going to be suitable for any kind of game. You might want to start making an engine for a simple kind of games like console RPGs, or maybe 2D strategy games.
I suggest you take a look at enguinuity to get an idea of how you make an engine skeleton that is extendable and well rounded off. I'm not saying C++ is a good idea though, I just think it will give you some good ideas for a modular design.
Once you have a solid kernel you can start writing small modules that you load and unload from there. Make the kernel simple and compact. Not much more than a simple command line with a load/unload module command.
Everything from there would be small and well defined modules written as dynamic link libraries. You would have to figure out how to cope with dependencies, like you can't load a module that depends on a sound module if you haven't loaded a sound module yet.
I suggest using a high level language that will allow you to embed a low level language where high performance is paramount. If such a thing exist...
I don't have much experience with this kind of thing myself but I have been onto the idea. Don't be supprised if you are an expert before you get anything like this up and running ;)
edit:
As Xai said (while I was busy writing) your engine is not going to be suitable for any kind of game. You might want to start making an engine for a simple kind of games like console RPGs, or maybe 2D strategy games.
Hold off on making an engine. I've made that mistake when I was 18. If you have not developed at least 3 games ( Not BF2 or Quake or Doom of course ) then you have very little understanding of what a developer requires from an engine. Theory is good, but actual experience developing games is very different.
I'm only now, 28, beginning to write an engine to base my future projects on. But that comes from almost 10 years of making small games, few published games, being on large teams and just observing how engines are created, etc.
I guess, the question is this: What do the other dozen already made engines lack that you feel you must provide? IMHO, you should write an engine if during your development or design process you realize you need certain features that you just can't get in the existing engines. Otherwise, you are really wasting your time. You will learn the language, but create a useless or redundant product. Plus, I am 99.9% sure you will never complete it since you have no real solid goal and purpose.
Don't start out your programming hobby/carreer with the NIH Syndrome. It is hard to break that habbit.
I'm only now, 28, beginning to write an engine to base my future projects on. But that comes from almost 10 years of making small games, few published games, being on large teams and just observing how engines are created, etc.
I guess, the question is this: What do the other dozen already made engines lack that you feel you must provide? IMHO, you should write an engine if during your development or design process you realize you need certain features that you just can't get in the existing engines. Otherwise, you are really wasting your time. You will learn the language, but create a useless or redundant product. Plus, I am 99.9% sure you will never complete it since you have no real solid goal and purpose.
Don't start out your programming hobby/carreer with the NIH Syndrome. It is hard to break that habbit.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
