Jump to content
  • Advertisement
Sign in to follow this  
chimera007

HELP! Just joking ), Where do i start in my engine?

This topic is 4492 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Ok, hello. Thanks for looking at my post and possibly answering my question. That said i can now move to the begging part. I have started my engine desgn. I didnt want to over complicate the whole thing so what i thought of was to start with the very basic stuff, creating the window and seting up d3d. The rest is what i will implement as needed. Here is what i have now: WindowMgr -> Sets up the window and handles resizes, messages, ... D3DMgr -> Does the nice work of setting up D3D, ready for hanging it... Next?! Now to the question: Whats next? I might be finishing a GUI Valve Source wannabe alike :). Eh... LoL my english is fine i just cant manage ideas.. All wanna come out at the same time. What do i do after gui, since i want to make a pong wanna be i wanted to know how to implement collision detection: Per-class or In whole engine or ... i dunno. If so, why and how to implement, dont need code just design ideas. I'll slave over code later ;) Thanks for looking at my messy post.

Share this post


Link to post
Share on other sites
Advertisement
I found the Enginuity series to be very good. Even if you're designing it yourself and not sticking to the code as it is laid out there, it gives a very good idea of the components of a game engine.

Check out the Game Programming > General category under articles.

Share this post


Link to post
Share on other sites
Since you want a proper design, you might want to combine the DX manager and the Window manager, since those will always be working close you might as well attempt to combine them into a single class.

Eg. I have a class name "VideoDriver", which basically handles everything regarding the window and everything that is graphics API dependent, like creating textures, OpenGL function calls, etc, etc.

If you feel like having two object continually calling functions in each other might be inelegant or would cause problems, you can always have the window management stuff implemented in a base class and have the direct X stuff as a class that inherits the window manager base class. Or, you could do what I've done and just throw it all in together in a single class.

Second, figure out exactly what you want to do next. Do you want to work on creating a GUI system? Or would you like to start with something like a simple rotating cube?

I'm not sure about a GUI as I haven't actually attempted to seriously create one as of yet because I've heard from other GameDev members that unless you really want to create your own, to just use a third-party one and mish mash it with your engine.

Else you should start thinking 3d. So, create a class and functions for manipulating a 3d vector. Also probably a 4x4 matrix.

From there, you'll probably be able to just display a cube on the screen without anything extra. But also be thinking about a vertex class that contains a position, normal, texture coordinates and perhaps a color. Even if you end up deciding to keep these things in seperate arrays and not have them together, it's a good starting point.

Well, I think I just gave you at least a couple of days work there. And, a good thing is that by the time that you've accomplished all that, you'll have a better idea of what comes next.

Share this post


Link to post
Share on other sites
Zekeva, Endar i liked both of your replys. It gave me some stuff to think about. Heres the deal: I am basically new to this whole thing, i cant draw a triangle on screen without looking for help :). So the gui is to get the hang of coding in C++ and DirectX. I thought about mixing the to classes up but... but not sure if i should. I will get the GUI running using a book, DX User Interface blabla.

After i was thinking of Sound. How should i attack that? I dont want to use FMOD or BASS since i am planning to Charge for my games and either charge more than i can afford. Still a teeny :D. and 1k USD for 1 fmod licence isnt my goal.

Soon after sound i am planning for Collision detection. I am wondering how it works. Is it individual? or applied to the engine? and if it is then how do i do it?

Thanks yall for helping me :D

Share this post


Link to post
Share on other sites
As said above, you should check out the Enginuity series. Also do some forum searches for "engine design" or the like, something will come up.

It may all seem like a daunting task right now (and it is) but after reading about people's designs and ideas it will all kind of snap together and you will have a better picture overall.

If you just want to get an idea about components, I think the following are important things an "engine" should support: entity management (scene graph but not necessarily, you have some options and decisions to make when it comes to managing game objects), messaging, ai (state, goals, pathfinding, etc), physics (gravity, collision detection, etc), sound (music, sfx), graphics (abstraction maybe, scene graph, renderer), gui (+cursor), input (mouse, keyboard, joystick, key bindings, gamepad, etc)

On the other hand, if you are struggling with just putting a triangle on screen, it might be a little early to design a full-blown engine with all bells and whistles. As you learn more about the topics at hand, you will probably start refactoring heavily, eventually throwing away your first code ^_^;

For sound, OpenAL or DirectSound. To research collision detection, you may want to take a look at ColDet.

Share this post


Link to post
Share on other sites
That sounded very smart. I am no being sarcastic. Exactly what i needed :) The components.

About the tringles on screen: I know how to do it but i cant memorize the functions :), i need references.

Share this post


Link to post
Share on other sites
It sounds like you are just starting to get your feet wet with a functional engine. The best advice I can give you is to not expect anything close to Valve's source on your first run through. Take some time and develop components seperately, for instance just do a model viewer or terrain renderer. Then move onto integrating some sort of scripting language. Once you have an idea on how everything works you can look into a full complete engine.

The hardest part of engine design is figuring out how all the components interact with each other. I spent the better part of a year prototyping out components and testing some different design philosophies before I ever started designing my engine. And then I spent an entire month away from the computer drawing diagrams and laying everything out on paper. If you want to make a true game engine expect to spend a lot of time doing stuff that isn't fun for a few moments of feeling great. It's something that you can spend years on before you see anything worthwhile come of it.

Share this post


Link to post
Share on other sites
if you looking for a valve source type of gui take a look at blender the guis are somewhat similar in style. they are also rendered using gui primitives and they have coded in support for freetype fonts. most of the work is there for you all you have to do is taylor it to your application. maybe write a wrapper around there api.


also I start thinking about how your going to write your scene graph and resource manager.


since we are on the topics of engine writting I was wondering how everyone feels about operator overloading in objects. I've noticed that many api's built in c++ don't really use them for builting scene graphs or setting up interfaces with other objects. Example: in the STD namespace everyone is familar with cout << "hello" << endl; but no api seems to use:

framebuffer fb;

windowstruct ws;

ws.fullscreen = true;

fb << ws;

fb << init;


I'm not saying its a good idea to use this exact example but it seems for certain things that the code could be much more readable like this. expecally since everyones used to using streams in c++ anyway. just a thought!

Share this post


Link to post
Share on other sites
Quote:
Original post by Lemonaid
framebuffer fb;

windowstruct ws;

ws.fullscreen = true;

fb << ws;

fb << init;




Wow, thats horrible. I love it :-)

Imagine the possibilities:


lpDevice << mVShader << mPShader << mVertexBuffer << mIndexBuffer;



Alan

Share this post


Link to post
Share on other sites
Quote:
framebuffer fb;

windowstruct ws;

ws.fullscreen = true;

fb << ws;

fb << init;

A dude, indead horrible. Nice!! Don't know why I didn't come up with that. :D

Quote:
lpDevice << mVShader << mPShader << mVertexBuffer << mIndexBuffer;

If you could do that, it would be so much more readable! But I doubt that you could make it as flexible as it is today though.

GBS

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!