Jump to content

  • Log In with Google      Sign In   
  • Create Account


Dave

Member Since 22 Mar 2004
Offline Last Active Today, 10:11 AM
-----

#5154012 Engine architecture questions

Posted by Dave on 16 May 2014 - 08:39 AM

The topic of whether it is a good idea to have global pointers to each manager in your engine is an open one. I worked on a commercial game for PC, PS3 and Xbox that had a global static pointer to each subsystem manager, so g_pRenderer, g_pScene etc. I now currently work on a commercial engine that doesn't have subsystem managers but does have lots of static data and a few singletons dotted around for good measure. There are many ways to skin a cat.

 

In some regards I would say don't worry about. Don't lose sleep over unnecessary architecture that you don't require. When writing an engine its easy to fall into the trap trying to write it too perfectly but at the end of the day no engine, no matter how well written or otherwise, is any good if it isn't being used to make games.

 

Anyways, to give you an idea for what I do in my engine is have it broken down into to two areas and these are separate libraries. I have Kernel and Engine. Kernel contains a the main interface that Main() deals with and contains the Command, Task, Core (utilities for platform access) and threading. The kernel class allows access to each of its subsystems. The second library has the engine code in it so resource loading, gui, scene management, physics, rendering etc. The engine class provides access to those subsystems. Nothing in the kernel area depends on the engine area, only the other way around.

 

Circular dependancies do happen and these are more easily identifable if each subsystem requires a pointer to its subsystem dependancies upon construction, for example:

 

GuiManager* guiManager = new GuiManager(pSceneManager, pRenderManager, pInputManager, pDataManager);

 

Being forced to pass in pointers rather than just using globals makes you realise something might be wrong more easily.

 

 

In short, it sounds like you're on the right track but just focus on it meeting your needs and not some unattainable goal of perfection that noone ever really achieves.




#4999480 The Singleton Pattern: To be or not to be [used]?

Posted by Dave on 09 November 2012 - 05:05 PM

I don't see that singletons or globals are particularly bad. I've worked on commercial games where singletons and globals have been used. One used them wisely and was the easiest codebase that i've ever worked on and one used it badly and it was extremely complicated and hard to ramp up on. I have also worked on commerical projects where "correct" OOP has been used and overused and this was also one of the hardest codebases i've worked on.

You can write bad code with "correct" practices. You can write great code with "bad" practices.

Writing tight OOP code in studios where iteration time is important and year on year you're rewriting large portions of code is common because of new platforms and new titles is a complete waste of time and it is important that you make simple architectural decisions that:

a) Allow new programmers to get on with things easily.
b) Make it easy to add features to.

It is argued that you can screw things up if you start touching global variables that you shouldn't. If you hire programmers with an ounce of common sense they generally won't do that and no matter what "barriers" you put in place to protect programmers from themselves, if a shortcut is really desired then it will be found. The friend keyword comes out in no time.

Stop worrying about writing perfect OOP and just get on with writing cool stuff for your game/engine.


#4994118 Create a Game Engine

Posted by Dave on 26 October 2012 - 06:21 AM

I had no intention of discouraging you, i actually encourage you to make a game engine. Apologies if it appeared otherwise.

The issue people bring up is how do you write an engine without a game to give you a set of requirements. Well, make up your requirements. Is there something you have seen in a game you'd like to emulate? Such as path finding, deferred shading, deformable terrain, destructable objects, gui ideas. Built up a set of demos, each their own executable, that do something different with your engine. As you develop more of those your engine code will mature, you might start again a few times because you realise you could have done something better.

At no point did i state that the article suggests Unity.


#4993801 Create a Game Engine

Posted by Dave on 25 October 2012 - 08:24 AM

It's just bad insta-advice.

The guy has expressed an interest in writing an engine and there is a hell of a lot he can learn from writing that technology himself. He expressed no intention of making a game in his OP and so an insta-reply with a link to that article serves very little purpose and it is of practically no help.

I have never made a single worthwhile game in my personal time, i have always worked on various pieces of technology and still do today and that has served me extremely well in the games industry. Using Unity to make games however is only going to get you as far (in terms of your skillset) as writing games with Unity. I have worked on a commercial product with Unity and you don't learn shit about making games when using it. You just learn to use Unity and how to cobble stuff together.

If you really want to learn to make games you need to have a good understanding of how the stuff your game code depends on actually works. Game programming is not easy, its very technical. You have to be aware of all the same technical considerations as engine programmers do in order to do it well.

Since the OP asked about engines specifically (albeit it turns out to be a bit misguided in later posts) its important to just point him in the right direction with regards to developing that kind of tech.

However, in light of more recent posts in this thread it is clear that the OP is a bit misguided with his need to write an engine and if his intention is just to make a game then there is no better solution than Unity. I just object to that article being banded about as if its THE answer to every thread similar to this one Posted Image.


#4993785 Create a Game Engine

Posted by Dave on 25 October 2012 - 07:27 AM


Why do you think it'd be more easy to create a game with your own engine instead of with a highly polished and proven solution like CE3 or UE3? Building something which can compete with those engines would require loads of time, money and expertise from you and your co-workers.



I know that my engine can't compete their engine but my game would be more prefect if i create my own game engine.


Yes and no.

What you would end up with is an engine that does exactly what you want. Often though this is alot more complicated that tweaking an existing solution to meet your needs. For a hobbyist who has the intention of making a game for production and making money it is often best to use a third party solution if what you want to do is fairly standard stuff.

In time you will know when you need your own solution. I've worked at studios that have exclusively rolled their own stuff and it was alright, you feel in control and licencing etc is less complicated. It comes at a cost of time though.


#4993784 Create a Game Engine

Posted by Dave on 25 October 2012 - 07:25 AM

http://scientificnin...mes-not-engines


This is really bad advice.


#4937144 Window appearance customization

Posted by Dave on 03 May 2012 - 11:01 AM

Cornstalks. Did you use QT edit to lay that out?


#4932834 C++ array and polymorphic objects

Posted by Dave on 19 April 2012 - 09:39 AM



I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.


You shouldn't really need dynamic arrays, is my point. Not if you've thought things through.

struct Pixel
{
	unsigned char r;
	unsigned char g;
	unsigned char b;
};

struct Image
{
	int width;
	int height;
	// Oh shiz, what now?! Obviously I haven't thought things through if I want to have images with varying sizes.
	// I was going to create an std::vector<Pixel> (or Pixel* if I was using C), but I guess I just need to "think things
	// through" more so I don't have to use dynamic arrays, because obviously I'm doing it wrong if I use them! I
	// guess the better option would be to create a Pixel[100000]. Yes, that sounds like a better solution. That way
	// I can only support images with 100000 pixels, and even if I have an 8x8 pixel image, I really think all 100000
	// pixels are necessary. Yes, this is better.
};


This is not a valid point.

This topic has been discussing the use of std::vector of c-style arrays, for your image scenario you don't need a std::vector anyways so i'm not sure what your point is. Dynamic allocation is not the discussion here.


#4932831 C++ array and polymorphic objects

Posted by Dave on 19 April 2012 - 09:33 AM

It's nice to know you deny the existence of C++ programs that work with text. It helps put your bad advice into context.


Or you could just give yourself some good old max sizes.


#4932817 C++ array and polymorphic objects

Posted by Dave on 19 April 2012 - 09:15 AM

I wouldn't recommend hand-coding a dynamic array without an utterly compelling reason. My post was actually written a few hours ago, before the latest replies. I'd use std::vector<> as a dynamic array, writing the equivalent by hand is a good way to get additional bugs and, unless you know what you are doing, your program will actually end up slower too.


You shouldn't really need dynamic arrays, is my point. Not if you've thought things through.


#4932795 C++ array and polymorphic objects

Posted by Dave on 19 April 2012 - 08:14 AM


There isn't anything wrong with using raw arrays or manual memory management at all. I would strongly suggesting thinking about whether you really need to use anything from the standard library or boost before you actually do.


I would consider this dangerous and unhelpful advice. The reverse should be true: Unless using something from the standard library or Boost is going to cause significant, documentable problems you should use those tools. Admittedly, there are situations where neither of those two will be helpful (like working on some platform with a horribly suboptimal compiler or under extreme resource constraints where you have to count each byte) but this is not the usual case.


If you're using STL you're usually also new'ing things up all over the place in your code. You're probably even using smart pointers now because you have no idea where things are getting cleaned up. Automatically using magic solutions like STL and Boost without any real thought (and i'm not saying this is you specifically) causes you to relax about how you are structuring and processing data.

If you organise your application well enough your memory layout will drive the architecture and you will find that you won't need STL for nearly anything.


#4932733 C++ array and polymorphic objects

Posted by Dave on 19 April 2012 - 02:55 AM

There isn't anything wrong with using raw arrays or manual memory management at all. I would strongly suggesting thinking about whether you really need to use anything from the standard library or boost before you actually do.

The answer to you question, as previously stated is to using an array of pointers, you were only allocating an array of objects.


#4738480 Is C++ being replaced with C#?

Posted by Dave on 27 November 2010 - 12:43 PM

Nah, C++ is a car without brakes.


#4727691 I have 120 games installed on my computer is that normal?...

Posted by Dave on 02 November 2010 - 01:40 AM

Only you can decide whether you have failed in life or not since it's relative to your own goals.


PARTNERS