Jump to content
  • Advertisement
Sign in to follow this  
Warvstar

Starting a new engine

This topic is 4505 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 so I have been working on a game for the last two years in Torque. I decided recently that although Torque was great, I wanted to build my own game engine, so here is what I to do with the engine. I want to build the engine on C#(new to me). I want to eventually use a DirectX 10 version of XNA, but for now I will be using MDX. This game will be released late 2007 or early 2008, and so I'm hoping XNA in DX10 form will be released. Now a tough decision was deciding what physics to use, will PhysX or HavocFX be dominate next year? I decided to use PhysX because they allow free use of the SDK at development stage, and for good if the game uses the hardware. So right now I'm writing the graphics engine in C# MDX and I want to optimize the engine to use multiple threads(ie. physics/AI), How should the engine design look? I was thinking something like this, Graphics Engine- has a scenegraph, can do stuff like Robot newRobot1 = new Robot(_device, @"robot.x", new Vector3(0.0f, 20.0f, 100.0f), 1f, 10.0f, fireSound, moveSound); newRobot1.position(2, 4, 0); // I think this is directX to move mesh to position newRobot1.setmovedest(2, 2, 0); // This would be my own function to walk the robot to his destination, it would move the robot object, not just its mesh basically add simple collision in here too Now how about physics, how would this work with my graphics engine? Does anyone know how(or the best way?) someone might implement PhysX into a new game engine? Thanks for any help. also I'm comfortable using C++ and unmanaged directX, would it be better for me to stick with C++ and then use DirectX10?

Share this post


Link to post
Share on other sites
Advertisement
Go through some of the tutorials for some popular 3D engines such as Ogre and Irrlicht. See how they do things. They might provide you some insight into how you might like to build yours.

Share this post


Link to post
Share on other sites
Among many important thing, you have to be aware that a gane engine is so much more than a graphic engine.

Game engine must (perhaps in a multithreaded fashion):
- handle graphics
- handle sound
- handle physics
- handle data
[- handle network]

and last but not least:
- handle logics

Since this last point refers directly to "how will people (or yourself) use your engine", it is dramatically important. Thinl about simple situation. Imagine you want a NPC to walk and avoid a fieldmine. How will you express that ? How will you create and integrate a game scenario with your engine ? When you say
newRobot1.position(2, 4, 0);

where do figures 2, 4, 0 come from ? You think its just a detail ? it isn't ;)

What sort of data will your engine use as input ? What software will you create your levels with ? (or will it be procedural content ?)

So I'd say that you dont have to have a perfect design but at least it must be clear in your mind how things will work when you want to use your engine to create an actually playable game (for that is what it's meant for)

Share this post


Link to post
Share on other sites
Thanks for the replies so far,

I'm thinking of using raknet for the network.

I want to create a scene editor once I get a simple scene graph working nicely.

I already know how to create the scene graph, and to move objects around, I even know how to create the scene editor used to create/move objects.

What I don't know is how much(or what) I should be letting the PhysX engine handle, from what I understand PhysX can create actors and load meshes, however I was thinking that instead of letting PhysX handle the scenegraph in such a way, that my game engine would handle it, I'm not sure if I'm making sense, here are some examples of what I mean.

Ok so my question mainly is, should I code the game like this,
Player clicks on the terrain and units moves there, all handled by the engine
Actor is created in the scene graph and the move function coded in the engine.

or like this,
Player clicks on the terrain and units moves there, the actor is created by PhysX and the movement is handled by PhysX, so basically all my engine would be is a graphic engine..?

This might be more of a PhysX related question than anything, I will look at how Irrlicht integrated PhysX and see how that works.

Share this post


Link to post
Share on other sites
Quote:
Original post by janta
Among many important thing, you have to be aware that a gane engine is so much more than a graphic engine.

Game engine must (perhaps in a multithreaded fashion):
- handle graphics
- handle sound
- handle physics
- handle data
[- handle network]


I full agree. It also needs to handle:
Memory
File systems if you're multiplatform
Resources
Logging
Errors
Window Creation and OS events (some do some don't)

Amoung others

Quote:

and last but not least:
- handle logics

Since this last point refers directly to "how will people (or yourself) use your engine", it is dramatically important. Thinl about simple situation. Imagine you want a NPC to walk and avoid a fieldmine. How will you express that ? How will you create and integrate a game scenario with your engine ? When you say
newRobot1.position(2, 4, 0);

where do figures 2, 4, 0 come from ? You think its just a detail ? it isn't ;)

What sort of data will your engine use as input ? What software will you create your levels with ? (or will it be procedural content ?)

So I'd say that you dont have to have a perfect design but at least it must be clear in your mind how things will work when you want to use your engine to create an actually playable game (for that is what it's meant for)


Now with this I completely disagree. The engine should have NO clue about any of this. You tell it to render object A at position B and it does. Unless the engine is a one time use only thing (why?) do not tie any game aspects into it at all. The engine should care not if object A can speak or interact with the user. It gets input and passes it onto the game. The game takes that input and makes changes to data held within the engine (rotates something, translates another, etc) and then tells the engine it's time to render the scene again.

The engine and the game should be completely seperate projects. That is if you ever wish to use the engine for another project without taking weeks or more to extract and remove game logic from it then trying to fix it to run away.

Share this post


Link to post
Share on other sites
Quote:
Original post by Warvstar
Thanks for the replies so far,

I'm thinking of using raknet for the network.

I want to create a scene editor once I get a simple scene graph working nicely.

I already know how to create the scene graph, and to move objects around, I even know how to create the scene editor used to create/move objects.

What I don't know is how much(or what) I should be letting the PhysX engine handle, from what I understand PhysX can create actors and load meshes, however I was thinking that instead of letting PhysX handle the scenegraph in such a way, that my game engine would handle it, I'm not sure if I'm making sense, here are some examples of what I mean.

Ok so my question mainly is, should I code the game like this,
Player clicks on the terrain and units moves there, all handled by the engine
Actor is created in the scene graph and the move function coded in the engine.

or like this,
Player clicks on the terrain and units moves there, the actor is created by PhysX and the movement is handled by PhysX, so basically all my engine would be is a graphic engine..?

This might be more of a PhysX related question than anything, I will look at how Irrlicht integrated PhysX and see how that works.


Player clicks mouse, engine gets this event and fires off an internal event to whatever you have listening for it in your game (game registered this earlier). Game decides what to do (move object A and B to new position). Event is fired from game to engine, engine makes the needed changes after consulting the collision detection code, if all is right Scene Graph or whatever is updated. Your game tells the engine to render (or its on a set timer).

Keep game logic and engine seperate as much as possible unless you never want to use this engine again :) Using things like PhysX, RakNet, etc are excellent ways to speed up development.

Share this post


Link to post
Share on other sites
Thanks for the replies, I'm still deciding what I want to use for scripting though.

I can't seem to find any good scripting engines for C#, LUA apparently does not work nicely with C#.

Crysis looks amazing btw.

Share this post


Link to post
Share on other sites
Quote:
Original post by Warvstar
Thanks for the replies, I'm still deciding what I want to use for scripting though.

I can't seem to find any good scripting engines for C#, LUA apparently does not work nicely with C#.

Crysis looks amazing btw.


If you want, you can use C# for your scripting as well as your engine. You can compile files at run-time and discover their methods and types using reflection. I'd imagine this would be faster than using an interpereted language for your scripting.

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike2343
Now with this I completely disagree. The engine should have NO clue about any of this. You tell it to render object A at position B and it does. Unless the engine is a one time use only thing (why?) do not tie any game aspects into it at all. The engine should care not if object A can speak or interact with the user. It gets input and passes it onto the game. The game takes that input and makes changes to data held within the engine (rotates something, translates another, etc) and then tells the engine it's time to render the scene again.

The engine and the game should be completely seperate projects. That is if you ever wish to use the engine for another project without taking weeks or more to extract and remove game logic from it then trying to fix it to run away.


Sorry I should have been more specific. A good game engine IMHO knows how to handle game logics, but the game logic itself remains completely outside of the engine. What I call "handling game logics" is the part of logic code wich is re-usable, that is some code that provides level designers with facilities to write game logic (interfaces for example) If not integrated to the engine, you will end up rewriting it for every project. Thus the game engine I thought of is actually completely reusable, and is a reliable ally for anyone who wants/need to prototype a game quickly.

I think the design which is in your mind is a .exe game / .dll engine, whereas in my mind its the exact countrary. Thus I see the engine as the piece which orchestrates everything: loading, rendering, updating objects( calling their logics, their physics, their animation and so on) etc.

Both approach are perfectly valid imo.

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!