Great. Can't wait for the link.
Will you lua or C# for scripting?
GameEngine from start to finish(DevLog)
Author
@ L. Spiro
That looks great, well done:
@ Solid Spy
Depends on what you're doing with it, you could choose the CryEngine .XML way of listing objects. But I'm inclined to agree, neither do I particularly like that system and I also don't believe it's very user friendly.
@ jbadams
Yeah I'd love to post it on here, the development blog section seems to be split into several posts. Whereas I'd like to keep updating in sections on a specific post and then getting feedback as I go along. Just like a thread really, is this possible?
@ Nathan
Yes C#
Author
Part 1 (Build engines not games)
I'll explain the title later 
:
As said, I'll cover the shear basics and questions asked.. When I originally started the hardest thing was to find what I needed to get going.. So I'll simplify the startup procedure and answer questions I've seen asked many times.
What is a game engine?
The question is very open to interpretation, diluted further with modern commercial and freeware (Open source) game engines. Simply put, I see a game engine as a solution to build and develop games quickly. The toolset size is dependant on what a developer is intending to do, you wouldn't focus on orthographic (2D) projection for a 3D game (let's move past the UI for now), but a multi-platform commercial engine like Unity would. There's several features in this tutorial that many engines wouldn't use of need, so they don't have them.. But they are still an engine, then we have open source products like Ogre3D and Horde3D which are rendering engines. Rendering is a term for displaying graphics, whether using Microsoft's implementation direct3D or the multi-platform OpenGL.
Why would I build my own engine?
A lot of what I say is subjective and it's for you to make your own mind up, but I will say don't attempt to build an engine if the following applies:
- A current engine serves all purposes required
- You haven't used a game engine before and at the very least, you're unfamiliar with putting a basic game together.
- You haven't discovered the limitations of a specific engine.
Building an engine can aid in multiple areas:
- Closed source engines are difficult to modify if impossible
- Deep understanding of not only how games work, but how tools fit together
- Feature set's can always be improved and added
- Financial return
Anyone deciding to build an engine has to weigh up is it worth it, this is NOT A COMMITMENT TO MAKE LIGHTLY and in most cases isn't worth the effort.
What's the difference between a game and an engine?
Not as much as one would expect, a game requires a renderer / physics / input / audio / UI and a way to be executed on a system / load resources / save games.
Many a time code is re-used from a game to build an engine around it, if you're going to do it from scratch then you might as well build what is in essence a level editor which allows you to quickly craft scenes and event's.. That's where the engine comes in, because once completed everything is done in the background.
What is the toolset we need?
Ok a list of tools:
SDL 2.0 (http://www.libsdl.org/)
Glew (http://glew.sourceforge.net/)
QT Creator (Because it's cross platform and supports widget's, (VIsual studio can also use QT widgets) (http://qt-project.org/wiki/Category:Tools::QtCreator)
UI (http://cegui.org.uk/) I'm open to other suggestions for vector or widget based solutions
Nvidia Physx 3.1 SDK (https://developer.nvidia.com/physx-sdk-v31)
Build engines not games
Wrapping this portion up, I saw an article saying build games not engines. Which rings very true, but there is more to it and not everything is black and white. As said, the best path is to find an engine that works for you. Failing that, you will spend a large portion of time building an engine for your game and time will be consumed building toolsets instead of writing an actual game itself. In a nutshell, this word TIME is the greatest challenge here.. A large high fidelity game may take 2 - 3 years to complete, add an additional 2 years for an engine, then ask yourself. Do you have the time?
In part 2, I'll be discussing openGL and Math:
Wrapping this portion up, I saw an article saying build games not engines. Which rings very true, but there is more to it and not everything is black and white.
I think it's worth linking to the article at this point for anyone unfamiliar with it: write games, not engines. A lot of people simply read the title and maybe skim a little of the text and assume the article is telling you not to create an engine at all, but that's not actually the point it makes; rather, it suggests an approach to engine creation where you start by writing one or more games and refactoring out the useful functionality to form the basis of your engine -- and it's a very good approach for ensuring your engine meets the requirements of a real game without wasting your time on features that might not be needed.
Obviously not an approach for everyone, but valuable advice to read and consider. Looking forward to seeing how your efforts progress!
(...and yes, if you really feel like you prefer to keep this as a forum topic rather than journal entries that's fine, although I'll move you from For Beginners to Game Programming. :))
Author
Wrapping this portion up, I saw an article saying build games not engines. Which rings very true, but there is more to it and not everything is black and white.I think it's worth linking to the article at this point for anyone unfamiliar with it: write games, not engines. A lot of people simply read the title and maybe skim a little of the text and assume the article is telling you not to create an engine at all, but that's not actually the point it makes; rather, it suggests an approach to engine creation where you start by writing one or more games and refactoring out the useful functionality to form the basis of your engine -- and it's a very good approach for ensuring your engine meets the requirements of a real game without wasting your time on features that might not be needed.
Obviously not an approach for everyone, but valuable advice to read and consider. Looking forward to seeing how your efforts progress!
(...and yes, if you really feel like you prefer to keep this as a forum topic rather than journal entries that's fine, although I'll move you from For Beginners to Game Programming.
Sounds great, thanks for the citation. That actually wasn't the one I originally read, the article linked shows you should make a game and have an engine built around it which is right on the money and my intentions..
Also thanks for the move and appreciate the input, from everyone.. I really do, I don't pretend to know everything and I love it when a community comes together to get a solution put together.
I'll just add, any information / point of view or opinion is not a reflection of the company I work at. This is my own personal take on things..
Author
Part 2: OpenGL and Math
I'll start off by covering some basic questions:
Do I need to be a Math Genius?
No! You have a massive calculator in front of you called a PC, if the prerequisite was a PHD in maths before you could make a game then many people wouldn't get very far. But you do need to have a basic understanding of how the math is put together, the reasons why we do it and how it relates to rendering.
Being straight up honest, the formulas made by math Guru's is freely available to copy and paste on the web. But we don't want to do that do we? No! Except perhaps the strange formula that is used for quaternion rotation.
Except perhaps the strange formula that is used for quaternion rotation.End users and abstraction
One thing you need to decide is who are you doing this for? A commercial released engine for finance, or do you want to use it for a team / personal use? Why I mention this here is you will have to automate a lot of the framework for end users who do not care or desire to know what you do about how an engine works. Abstraction can be the a world of pain unto itself and cause more headaches than building the engine itself. All the math will be publicly available, the renderer will be manipulated with a couple of clicks.
Sure automating tools to become very simple to use can also benefit yourself, but you may find the time to create is not worth the effort. But this tutorial / set of whining, will be based around a commercial engine. Use the concepts and choose your positions wisely..
OK!!
So I've covered the Q&A, now I think it's time to start learning about how the engine is built!
Coordinates
The shear basics are, we have a screen filled with pixels that are RGB (Red, Green and Blue) or (Cyan, Magenta, Yellow and black). The higher the resolution, the more pixels are displayed on the screen. We have CRT's which use a timing system, but as technology has moved on I'll not mention anything about them.
LCD screens represent pixels as dots / squares, usually manufactured on a 2D grid.
Just as pixels are displayed in a grid, we also are going to compute based on an invisible grid with locations called Vectors. We can have 2 vectors (X,Y) one to represent horizontal axis and another to represent the vertical axis. Whilst we do use 2D Vectors in a 3D game, we will mainly be focusing on a 3 dimensional vectors represented as (X,Y,Z) and a 4D representation (X,Y,Z,W) for rotations. What? 4D? It's a simple way to think about it and as it's not necessary to explain every detail so I'll move on from this one and return later :).
The claw GRRR!
Easiest way to think about coordinates in 3D space is to stick your hand up in the air and do a three finger claw, your middle finger pointing straight out, your index finger pointing up and finally your thumb pointing the side. Or make an L shape with your Index / thumb and have your middle finger pointing directly away from you.
We always start from (0,0,0), theres nothing stopping you from starting somewhere else.. But there's an issue I'll discuss later in the tutorials with how floating point precision far away from the default location of (0,0,0) can cause issues. By the way (0,0,0) = (0(X), (0(Y), (0(Z)) so in other words X,Y and Z are all set to zero in parenthesis.
So what's the point of all this?
It's how we do anything in games, drawing lines, spheres and even calculated positions of complex meshes. Then we transform them from one location to another based on coordinates. So now we have a basic understanding of vectors, let's move on to our next lovely set of maths.
Vertices and indices
In essence we play a massive game of dot to dot and GL will join the lines up and every line is classed as a vertex, I don't want to go into optimisation to early. But indices brings up a valid point, what if we have two conjoining triangles with overlapping lines? What will OpenGL do if we only displayed everything as Vertices? Well it would draw every Vertex, so we have two triangles and six lines (Vertices). This isn't ideal as I will show you later, drawing is one of the most resource hungry portions in regards to rendering. Welcome to indices, in which simply we just don't duplicate vertices and append as an indices. So we don't draw line, 1,2,3,4,5 and 6 and duplicate the intersection of line 3 (to the adjoining triangle) we just draw, 1,2,3 and 2,3,4.
Enter the Matrix
What we could do is, set all these positions manually. We could transform from one location to another in 3D space by setting every position in code line by line, but that would be silly and utter waste of time.
So what we use is a Matrix / matrices and take advantage of our giant calculator to perform transforms for us.. Cool huh?
The biggest question is what are we trying to achieve with these matrices?
Well basically we need to define where we are in relation to anything else, I'm sat in the lower left corner of my room. On top of a chair, in a certain part of the world.
So we have three important matrices to consider:
World, view and projection
World
Where is the object / model / mesh located in the world? That's about it for world view:
View
Where exactly is the model so the camera can see it?
Projection
This is what type of camera we are going to use, for our project there will be two. One as a main 3D projection and a secondary as a 2D orthographic projection for the user interface.
Finishing off
I hope you enjoyed this, next time we are going to look at how we apply these features and delve a little deeper into applying the math and how OpenGL responds.
I'm going to reveal what sort of game we're going to make as well :)!
An RPG WOOO! Wait Wait.. What about my FPS? What about my X game!??
It doesn't matter, once you have learn't all of this you will realise very quickly.. There's honestly not that much difference in it!! You might change where the camera is, or modify the physics slightly for your grenade launcher.
Why an RPG then?
Because, it is the biggest pain in the ass I could find and the toolset will be extensive and transformable to most other games!. Hence when someone pops onto a forum with no experience and says HEY! I want to make an MMORPG and we just have a giggle about it. If they knew what they were getting into, they'd run to the hills!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
