Jump to content

  • Log In with Google      Sign In   
  • Create Account


Writing a game engine


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
117 replies to this topic

#41 turbello   Members   -  Reputation: 115

Like
0Likes
Like

Posted 07 December 2011 - 07:27 AM

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 :)

Sponsor:

#42 EJH   Members   -  Reputation: 314

Like
0Likes
Like

Posted 07 December 2011 - 07:56 AM

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.

#43 crancran   Members   -  Reputation: 389

Like
0Likes
Like

Posted 07 December 2011 - 09:36 AM

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!

#44 patrrr   Members   -  Reputation: 984

Like
0Likes
Like

Posted 07 December 2011 - 09:45 AM


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!


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;
  }    
};


#45 froop   Members   -  Reputation: 636

Like
0Likes
Like

Posted 07 December 2011 - 11:49 AM

here is my personal implementation

class MyClass
{
public:
  MyClass()
  {
    if(mInitialized) PlayMovie('http://www.youtube.com/watch?v=48rz8udZBmQ');
    mInitialized = true;
  }

  ~MyClass() { Release(); }

  void Release(){ mInitialized = false; } 

private:
  static bool mInitialized;
};


#46 phantom   Moderators   -  Reputation: 7073

Like
4Likes
Like

Posted 07 December 2011 - 06:54 PM

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.

#47 L. Spiro   Crossbones+   -  Reputation: 13268

Like
5Likes
Like

Posted 07 December 2011 - 07:15 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#48 Hodgman   Moderators   -  Reputation: 29447

Like
2Likes
Like

Posted 07 December 2011 - 08:44 PM

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?

#49 crancran   Members   -  Reputation: 389

Like
0Likes
Like

Posted 08 December 2011 - 09:56 AM

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.

#50 T e c h l o r d   Members   -  Reputation: 186

Like
0Likes
Like

Posted 08 December 2011 - 10:34 AM

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.

#51 turbello   Members   -  Reputation: 115

Like
0Likes
Like

Posted 08 December 2011 - 11:05 AM

Wow I really love it, there are so many answers on such a short time!
Ok thanks! This lightened up my mind. It's not my fault the user didn't read how to work with my engine. :)
And yes, no one will ever work with my engine because there are better ones.


Hodgman, a long time ago I read you can't make 2 window classes ( WNDCLASSEX ) with the same name. I'm not sure this will call a break error when you try it, but it will do things you don't want to happen. But as you say, waisting time on this I don't really need now. Already got less time :)


techlord, I'm not sure if "Make your game engine" is bad advice. :wink:
I know there are many good libraries. I was going to learn DirectX for my GUI but this year I noticed we get graphics programming next year. And there we will see how DirectX works. And we will make shaders too( vertexshaders & pixelshaders ), these shaders are for our 3D models. ( we make 3D objects in 3DsMax ).

I'm not concerning about pure GUI now because GUI can be very hard to program.
Always creating things from scratch is foolish yes. A friend in my class has made his own string class. All because there is a _UNICODE and with his class he can do everything with the strings & wstrings. ( the type that will be used depends on unicode ).

But I use something else for the unicode :rolleyes:

#ifdef _UNICODE
#define tstring wstring
#else
#define tstring string
#endif // _UNICODE


#52 Oxford Oliver   Members   -  Reputation: 100

Like
0Likes
Like

Posted 08 December 2011 - 12:56 PM

Here is how I start a game in my engine. Might give you some ideas

#include "engine.h"

int WINAPI WinMain(HINSTANCE hInstance,
	HINSTANCE hPrevInstance,
	LPSTR lpCmdLine,
	int nCmdShow)
{
	Graphics * graphics = new Graphics(hInstance, nCmdShow);

	// parameters are title, width, height, fullscreen
	if(!graphics->initialize("Game", 1920, 1200, true))
		return 0;

	// Main game loop
	while(graphics->GameLoop())
	{
		graphics->BeginRender();
		
		// Render Sprite/Mesh/View etc
		
		graphics->EndRender();
	}
	
	graphics->release();
	return 0;
}

By the way many professional engines use a similar approach, an example would be leadwerks engine

#53 turbello   Members   -  Reputation: 115

Like
0Likes
Like

Posted 08 December 2011 - 01:15 PM

Thanks !!

I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

#54 Oxford Oliver   Members   -  Reputation: 100

Like
0Likes
Like

Posted 08 December 2011 - 01:20 PM

Thanks !!

I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?


This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object. Some times you want to have two instances of the Graphics class so it would give you more control

#55 turbello   Members   -  Reputation: 115

Like
0Likes
Like

Posted 08 December 2011 - 01:23 PM

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

Ok it is more easier for the programmer but I think it will have less performance.

#56 DarklyDreaming   Members   -  Reputation: 363

Like
0Likes
Like

Posted 08 December 2011 - 01:45 PM

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

Ok it is more easier for the programmer but I think it will have less performance.

Who knows? Why don't you profile it instead of making guesses - because, you know, that's how real programmers do it.

Also, negligible performance improvements are best left alone until you really need them.
"I will personally burn everything I've made to the fucking ground if I think I can catch them in the flames."
~ Gabe

"I don't mean to rush you but you are keeping two civilizations waiting!"
~ Cavil, BSG.
"If it's really important to you that other people follow your True Brace Style, it just indicates you're inexperienced. Go find something productive to do."
~ Bregma

"Well, you're not alone.

There's a club for people like that. It's called Everybody and we meet at the bar."

~ Antheus


#57 Oxford Oliver   Members   -  Reputation: 100

Like
0Likes
Like

Posted 08 December 2011 - 01:45 PM

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

Ok it is more easier for the programmer but I think it will have less performance.


I really don't recommend using the stack because it is some what limited. I have seen people create objects on the stack but it causes them so many problems like a program crash or exit unexpectedly. Using the heap also might cause memory leaks if the programmer doesn't free the memory. I would only use a stack for primitive types..

#58 crancran   Members   -  Reputation: 389

Like
0Likes
Like

Posted 08 December 2011 - 01:45 PM

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.
Ok it is more easier for the programmer but I think it will have less performance.

It is certainly faster to allocate objects on the stack rather than from the heap because it's a simple stack pointer manipulation. But the actual function call itself on a stack allocated vs heap allocated object is negligible. The key point to remember is that stack space is limited considerably compared to that of the available heap memory. Typically you would want to use a stack variable when it's lifetime is confined to the containing scope and it's size is known at compile-time. You should consider heap allocation should the scope of the object be beyond a simple function call's scope and/or the size is unknown at compile time.

EDIT: As Oxford points out, I prefer to use the stack for primitives as well and any class or structure objects I tend to allocate from the heap unless the context falls in line with where it's use is limited and therefore a stack allocation is sufficient.

#59 swiftcoder   Senior Moderators   -  Reputation: 9856

Like
0Likes
Like

Posted 08 December 2011 - 01:45 PM


I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object.

It's really not, and no it isn't. 'More OOP' is a nebulous claim at best, and because you are constructing the instance right there, there isn't any advantage to holding it by pointer (if you were allocating a concrete subclass of an abstract baseclass using a factory, it might be a different matter).

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

This is the kind of performance question you shouldn't care about at your stage of learning. Any difference is negligible.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#60 Oxford Oliver   Members   -  Reputation: 100

Like
0Likes
Like

Posted 08 December 2011 - 01:53 PM



I can see you made a pointer to your graphics object. Why haven't you just created an object on the stack?

This way is more OOP (Object Oriented) and it is much easier for the programmer to create new functions and call them from this object.

It's really not, and no it isn't. 'More OOP' is a nebulous claim at best, and because you are constructing the instance right there, there isn't any advantage to holding it by pointer (if you were allocating a concrete subclass of an abstract baseclass using a factory, it might be a different matter).

But will it have more performance? Because calling an object on the stack is faster then calling the pointer that points to the object on the heap.

This is the kind of performance question you shouldn't care about at your stage of learning. Any difference is negligible.


What you said is true but he want to do it in C++ not C. What I mean is I could just create a structure and do this
Graphics graphics;
graphics.initialize() ...

That would really look more like C not C++
I would rather use this for variables like
int x; ...
Not a class




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS