Jump to content
  • Advertisement
Sign in to follow this  
turbello

Writing a game engine

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

Kyall,
I know my engine will look as good as the engine i've been given. But if I copy and change some stuff, I don't learn alot from it, I won't go deeper into the code I copied.

If I write it myself I need to know what I am doing and how it works so that way I learn what it all does.

You won't be crucified for it trust me :)



Hodgman,
yes, my code will be safe now because I'm the only user now. :)


freeworld,
I never said writing an engine was easy.. After some of you adviced me not to write it but focus on the game itself. I'm still not going to listen sorry. I'm hard headed :lol:
I didn't asked of I should write an engine or not. I was asking if I was going in the right direction.
With keeping saying I should not write it I'm losing important time.. :)



I'll use the third way and I'll make a new post with the progress. I'm now testing all events :)

Share this post


Link to post
Share on other sites
Advertisement

Hmm I don't think that will solve the problem.

Suppose I write the GameEngine with that bool;

GameEngine object1;
GameEngine object2;
GameEngine object3;

object1.Initialize();
object2.Initialize();
object3.Initialize();


I can only have 1 GameEngine object but with that code I can write multiple objects.
I'm not sure but I think a 'static bool m_bInitialized'' will help.

As soon this is set to true once, it will always be true in the whole application ( at least if you don't change it to false again ). I'll test in tomorrow.


Yes I'm the only user, but I asked in the question " suppose if the engine is for more users ".


There won't be more users. These game engines (and dozens more like them) exist and are free for non-commercial and/or students projects:

http://unity3d.com/
http://www.udk.com/
http://www.crydev.net/

Therefore nobody will ever care about or use the engine you made in one month for a class project. Worrying about "other users" making a second game engine object in your code is tantamount to studying what techniques Jessica Alba enjoys in the bedroom. The likelyhood of you dating her and someone using your class project game engine are about the same - 0.00000%.

Please ... just make the game. Do not code anything unless it is aboslutely needed to complete the game.

Share this post


Link to post
Share on other sites

Change that to a static.
class MyClass
{
public:
MyClass() {
assert(!mInitialized);
mInitialized = true;
}
~MyClass() { }

void initialize() {
// do initialization here
}

void shutdown() {
assert(mInitialized);
// do shutdown logic
mInitialized = false;
}

private:
static bool mInitialized;
};



bool MyClass::mInitialized = false;

Now it is not possible to make 2 of this class (threading issues aside).
Add #ifdef _DEBUG for less release-mode clutter.


Good point! Thanks YE!

Share this post


Link to post
Share on other sites

[quote name='YogurtEmperor' timestamp='1323219520' post='4891292']
Change that to a static.
class MyClass
{
public:
MyClass() {
assert(!mInitialized);
mInitialized = true;
}
~MyClass() { }

void initialize() {
// do initialization here
}

void shutdown() {
assert(mInitialized);
// do shutdown logic
mInitialized = false;
}

private:
static bool mInitialized;
};



bool MyClass::mInitialized = false;

Now it is not possible to make 2 of this class (threading issues aside).
Add #ifdef _DEBUG for less release-mode clutter.


Good point! Thanks YE!
[/quote]

Why not do like this?
namespace MyEngine
{
namespace priv {bool initialized = false; }

void initialize() {
// do initialization here
}

void shutdown() {
assert(priv::initialized);
// do shutdown logic
priv::initialized = false;
}
};

Share this post


Link to post
Share on other sites
here is my personal implementation

class MyClass
{
public:
MyClass()
{
if(mInitialized) PlayMovie('
#39;);
mInitialized = true;
}

~MyClass() { Release(); }

void Release(){ mInitialized = false; }

private:
static bool mInitialized;
};

Share this post


Link to post
Share on other sites
Here is my personal implimentation to stop this.











Nothing.

Trying to protect against user malice is wasted effort. Document clearly and when it blows up in their face point out the document which says clearly "do not do that shit you've just done!" and then get on with your life.
I swear more harm has been done to projects by trying to protect against people trying to do stupid things then happens when the same users ignore and do it anyway...

OP; you are in school. Finish the assignment to get your grade, worry about other stuff once that is done.

Share this post


Link to post
Share on other sites
You know, I don't think there's any classes in my engine, where making two instances of them would be an error...

Assuming you don't use global state, then this should be the default behaviour of any class.

Create two clocks, you can measure the global time twice... Create two OS windows, you get two windows and two message pumps... Create two GPU devices, you get two separate GPU devices... Create two thread pools, you'll have twice as many threads running as you otherwise would... Create two heaps, you've got two places to allocate RAM from...
Most of these things aren't sensible use-cases for me right now, but they're not errors. Maybe some day I will want to create two OS windows, each with their own GPU device, who knows?

Choosing not to enforce the "single-instance only" rule is simpler than enforcing it, and I've no requirement to enforce it, so why would I waste time adding unnecessary restrictions?

Share this post


Link to post
Share on other sites
I agree with phantom because spending precious time trying to avoid asinine cases of pure idiocy lead to programming checks that often add performance impacts or make the code base less flexible and readable. This is the purpose of documentation in the end and making sure that the code is being used accordingly. I understand Yogurt's point as well and there have been cases where I've done the same when I knew that the code added wouldn't be a long-term problem or would take a few minutes to implement, but meeting the deadline and being fault tolerant on legitimate use cases have far more importance than silly developer mistakes because someone failed to read documentation :S.

Share this post


Link to post
Share on other sites
Hi Turbello,

I'm going to give you extremely bad advise: Make your Game Engine. I'm a advocate for developing game engines as they can be just as fun developing for yourself, as developing a game for others. I'm developing one here. My engine design evolved from multiple GUI and Particle System Tech Demos. These can be the starter systems for your engine as well.

I find it interesting that game devs rarely mention developing a GUI when starting up a Game Engine, when any interactive 2D/3D game world is a complex GUI. From my perspective, there is very little difference between moving a player character in a 3D world and colliding with an Event Trigger, verses, moving a Pointer across a 2D Screen and colliding with a Hotspot.

There are all types a game creation secrets hiding in GUI design. In developing the most basic GUI and Particle System, you will touch upon many different topics that can be shared amongst many different high-level game systems. For example, in my Engine Design, Gadgets (GUI Entities) use the same Physics, Rendering and Audio Components that other High-Level Game Entities use. Just add/remove Input Components to transform any Game Entity into GUI Entity.

Although, I'm making a game engine I'm not foolish enough to try take on creating every system from scratch. There are some really powerful feature filled libraries out there that are freely available. Besides, there is enough challenge in working out how each of the systems will integrate together.Good Luck to you.

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!