• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ShadowKGames

GameEngine from start to finish(DevLog)

15 posts in this topic

As a fellow EngineEngineer (I'm doing one but WebGL in HaXe language) here are some cents.

 

If you're focusing in the end-user you should try C#, as you said the perfomance will not be an issue (look at Unity3d), simple and frequent operations like sorting, delegates, get/set methods and other hi-level stuff done in 1 C# line will help a lot.

 

Just wrap OGL stuff in a static class and you are free to create a higher-level class library that make the calls organized and the GC is a good friend too.

In terms of class modelling I found Unity's way really awesome (Entity-Component based), you have a container (Entity) and Components are attached to it, after that, only destroying it will remove it (it is nice to avoid lost references).

 

I have a 'Object' like class (Resource) which contains useful stuff like unique-id, name string, ... which I register in a global Resource list, useful to simply destroy everything after a scene changes or globally search any stuff based on type or name (Reflection is another awesome feature of C#).

 

I organize stuff in scenes wich is basically a XML [dependecies + hierarchy] that create stuff in RAM/GPU memory and also creates the entities in 3d space with its components + reference to the loaded dependencies. When a new scene is called, destroy everything and restart the process.

 

About OpenGL, I suggest also following Unity's footsteps. Working with the concept of Renderer + Material, I reached a way to sort the rendering stuff based on properties of both elements and then optimizing stuff and fitting RenderTarget operations (E.g. ImageEffects) more easily in the pipeline.

 

Lastly, I will reveal the feature that took most of my time in the 6 months of development. The Collada Loader adapted to correctly load Bones and Animations. It was a real pain. Also the Skinning technique was hard to make it work efficiently in the GPU mode.

 

Nice post! Keep in touch!

 

**Edit**

 

Also create a static class to draw any kind of gizmo on top of everything (lines, wirespheres,wirecube,...) it will help a lot to debug hard stuff (skinning)

Edited by eduardo_costa
0

Share this post


Link to post
Share on other sites

If you're focusing in the end-user you should try C#, as you said the perfomance will not be an issue (look at Unity3d), simple and frequent operations like sorting, delegates, get/set methods and other hi-level stuff done in 1 C# line will help a lot.

 

Not arguing with your sentiment, but Unity3D is written in C++; Mono is used for user extensions, not the engine itself.  :)

1

Share this post


Link to post
Share on other sites

This was exactly the original purpose of my site.

It was supposed to be a logging of the trials and errors of constructing an engine, not to have a bunch of tutorials.  It eventually shifted focus because there was no reason not to include tutorials and other things, but until now I haven’t really talked a lot about the “trials and tribulations” part.  That is changing now that I am redoing the graphics module.

 

Although my philosophy on using 3rd-party libraries is different, we basically seem to have exactly the same goal with our sites, so readers will be able to see different ways of doing it all, which I would consider a good thing.

 

 

L. Spiro

 

Sounds great, If you don't mind can I use some of that blog as excerpts? Anyway I'll be going down the OpenGL strictly path.. For a couple of reasons, A) the mantle OpenGL derivative and B) cross compatibility..

 

From a quick scan, you seem to have quite a lot of cool stuff that I'm interested in.. But I'll not be including mobile support, because I don't have a clue smile.png.

 

This is literally a high end renderer and toolset for good looking games. 

 

@ Eduardo

 

Exactly what Sean says, the engine and core concepts will be written in C++.. Then a layer of abstraction for C#. CryEngine is written in C++ but you can use CryMono for example as an end user layer.. So that's the path I'll go down.

 

Also appreciate the input, XML might be a cool way to go for external resources.. 

Edited by ShadowKGames
0

Share this post


Link to post
Share on other sites

 

Also appreciate the input, XML might be a cool way to go for external resources.. 

 

XML is ok, just remember that parsing XML files can be very slow compared to loading binary files, especially in an age where loading times are becoming impacted as bigger resources are demanded. I personally use Assimp in a separate program and generate my own binary files for 3d models and animations from COLLADA, however xml is a good start. Creating your own binary file can be a pain in the ass, but it's kinda cool once you get it done :3

0

Share this post


Link to post
Share on other sites

 

 

I hope this is a good introduction and I'm looking forward to updating as I go along.

 

Ok, now give us the link! cool.png

0

Share this post


Link to post
Share on other sites

About doing in C++ allowing C# scripting, I found it great!

My experience making these two communicating is really shallow so I could not use this technique!

My point is that making the end-user working in C++ nowadays isn't that productive anymore.

 

Using XML as scene manager was my choice to avoid binary data being loaded with XMLHttpRequest (HTML5+WebGL Engine).

Other data is a mix of XML and Base64 bytes compressed using LZMA.

So a 'mesh' would be:

 

<mesh>

<vertex>base64_float_bytes</vertex>

...

</mesh>

0

Share this post


Link to post
Share on other sites

@ 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#

0

Share this post


Link to post
Share on other sites

 


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! smile.png

 

(...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. smile.png)

 

 

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..

1

Share this post


Link to post
Share on other sites
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! smile.png 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!
Edited by ShadowKGames
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0