Writing a game engine

Started by
116 comments, last by freeworld 12 years, 3 months ago
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 :)
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.

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 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;
}
};
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;
};
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.
I used to think no one would be senseless enough to make two of a critical one-time-only class and did not bother adding protections.
Until my coworker came along and cost me hours of bug tracking before I realized he had done the thing I least expected any human to do.

I didn’t want to walk all the way over to his desk to slap him so I quietly added double-instance protection, checked in the code, and waited for him to come to me complaining that my last check-in gave him errors. That way I could slap him without having to get out of my chair.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

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

This topic is closed to new replies.

Advertisement