Advertisement Jump to content
Sign in to follow this  

Basics of engine

This topic is 4922 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

Hi, ive developed several D3D apps in the past, but they were always with "predefined" scenes, ie i knew how many vertices i needed etc. What im after is the beginnings of an extremely simple engine. All i want to be able todo initially is display some 2D objects. Ive got some questions to ask before i start: a) Is it best to build the engine as a set of c++ objects that are just inherited in a normal .exe, or is it best to use a dll or lib? b) Should the application inherit from the engine, or should it be a series of calls to public functions? c) Should there be 1 vertex buffer for all 2d objects? Or individual buffers for each 2d object? d) Whats the best way of separating game from engine? Should a series of functions be called in an external dll, like Initialise, Render, Shutdown, Keydown, etc. Allowing the external dll to choose what todo. If youve got any more pointers for me regarding where to start, id like to hear them. Cheers

Share this post

Link to post
Share on other sites
Hi the Skute,
The best way to design an engine is to think about what you want to accomplish from it.

Think about everything as objects... let's take a simple asteroids clone.
What do you have?

1) Bullets, asteroids, a Player, a Background
What is the first thing that comes to mind about them?
They are all entities? aren't they?
What do they all have in common?
They have a position, a texture... etc..

Now that you have thought about that for a bit. What methods do we need for each of these entities?

[The Entity]
1) Initialize() - Method that initializes all the resources for the entity
2) Update() - a Method that updates the matrices (positions ... etc) and other resources that doesn't involve rendering.
3) Render() - a Method that renders the entity and calls any rendering related methods.

See what we are doing? We are thinking about each of the components of the game as a single entity or Object, hence the term/method object orientated design.

So what would our entity class look like?

[source lang = c#]
#region Members
private Texture texture;
private Matrix matWorld;
private CustomVertex.PositionColored[] quad = new CustomVertex.PositionColored[4];
private VertexBuffer vb;
#region Methods
public Entity()
//whatever needs to be done
public abstract void Update();
public abstract void Render(Device device);

This is just an example of what I thought would be good to add to a Entity class.
So now we have some entities, you can derive your entities from it, like Player, Enemy, etc..
Then you'd create a class called EntityManager.In this class you'd have a EntityList that would have methods that call Update and Render of each entity.

I hope this pushes you in the right direction, I hope everyone contributes to this thread since it seems like a pretty interesting way to discuss small games.

Share this post

Link to post
Share on other sites
You can construct an engine in different ways, I personally believe that the best way is to make it independent from the game, this means no entities, bullets, walls etc. like Armadon suggested. Others believe that there is nothing wrong with binding an engine to the game and create all the objects Armadon suggested.

So here is MY opinion:

a) Since this is your first engine it would probably be best just to build it into the .exe, but for bigger engines I believe it is better to seperate the game and engine.

b) I think that the best thing to do is make an CEngine/Engine/engine(or whatever you call it) and then call its public functions.

c) Of course not, if you have used DirectX for some time you know about what is called FVF. Imagine that 2 objects have different FVFs, then it would be impossible to put them in the same vertex buffer(it might be possible, but very hard, and I don't know a way to do this.) But it'll be a good idea to get as many objects into each vertex buffer as possible.

d) Well the best way would be to only let the game access what it needs to, that is one of the reasons that i in b) said that you should not inherit from the engine class, then you would have access to all protected members.

Share this post

Link to post
Share on other sites
Thanks for both replies, in (c) the last question should have read:

Or individual buffers for each *type of* 2d object?

OK i think thats given me enough to get started a little, but im still wondering about 2D. I presume its better todo 2D in 3D, as opposed to doing the 2D via writing to back buffer, locking unlocking etc. Because then in the future you can implement your 2D functions into an actual world. (i.e. have a 2d dialog appear on a wall or floor or something).

Would the entity class contain *all* objects within the engine? Including all 2D panels / dialogs etc? I guess they all need initialising / updating / shutting down too.

Share this post

Link to post
Share on other sites
I don't think it is a good idea to let actual living 3d objects get mixed up with 2d dialogs and stuff. You can implement all GUI in a separate file used by the engine and the EXE.

Share this post

Link to post
Share on other sites
I was thinking more if for example, you were looking at a computer monitor in the 3d world, you could place 2d dialogs onto the computer monitor, and allow the user to interact with them.

which is the best approach when using direct3d? 2d in 3d, or using the backbuffer?

Share this post

Link to post
Share on other sites
There is really no reason not to do 2D in 3D. It's both easier and faster. If for some reason you need to render on a per-pixel basis (though I can't imagine why), then you could still lock the back buffer or write to a render target.

Share this post

Link to post
Share on other sites
Hi.I was recently doing my break out clone , so ill tell you how have i done.
I taken the OOP path.

First i created Z_Image class
that is the one with only *Texture and RECT
Then i created Z_Animation class
this one has array (vector) of Z_Images and
I added functionality for changing Images
(currImage = ImageSequence[currImage + 1])
Then i created Z_Sprite class
this one has a array of Z_Animations

For every (displayable) entitie derived from Z_Sprite ,
and added it specific functionality (DoLogic()).

In globals i have created arrays of entities and call theirs
DoLogic(),CheckCollision() and Render().

Thats how i done this game ,hope this helps you a bit but i am
still beginer so think and choose what you like.

PS. If you want i can send you my project files.

Share this post

Link to post
Share on other sites
Not sure exactly what yer looking for but I have found 3D to be a hell of alot easier. But that aside you can do both together or seperate. As far as design goes which is why I am posting, is you could build yer engine outside of yer game. It makes it a bit easier in the end after I found out. I had to rebuild everything because my engine was constantly changing and you dont want graphic and sound artists constantly at yer side asking you to implement more static objects for them. So I ended up coming up with a design that let me grow according to new technologies. I am not saying this is the best way, im not even sure if its correct. But it fits my needs and allows growth.

I ended up making alot of what I call "Managers" and "locals". So for instance an object class, I would have the ObjectManager and alot of localObjects. These managers make sure that I can remove or add to when I please and take care of all the processing inside of its self so I dont accidently remove or forget to change an index sometime. Things will start to become dynamic as yer game persists.

So I have it laid out like this.

and so on..

I simply pass pointers to the managers where they are needed and therefore im never duplicating or accidently doing something that will hurt when things start getting oversized. They automatically take care of themselves. Upgrading is easy as well because you can simply create a new type of manager and throw out the old crap with the rest of the program staying intact.

I hope this helps, if ya need any more info or if this was helpful just ask.

PS- I would build this to look ahead, make sure you can take care of the important(or MOST IMPORTANT) part now, the design. I didnt and I regret all the lost time spent.


Share this post

Link to post
Share on other sites
All of my programs have used very simple engines. Basically, I make one class (either called "engine" or "Graphics") that contains functions to create the D3D device, render the scene, control text output, etc. I have another class for Input (DirectInput) that will initialize and poll each device.

These two classes are directly created and called from my main exe. The Graphics class may also contain other classes for enemies, terrain, etc.

This way has worked for me and I haven't noticed any issues with it.

Share this post

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

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!