Jump to content

  • Log In with Google      Sign In   
  • Create Account

L. Spiro

Member Since 29 Oct 2003
Offline Last Active Today, 07:34 AM

Posts I've Made

In Topic: Game State management in Entity Component System architecture

23 October 2014 - 08:11 PM

In all my previous games I've used an FSM-based approach where each Game State is an object with its own Update and Draw methods. Each Game State would mantain a local list of Game Objects to update and draw.

Like the system I described here:
General Game/Engine Structure

 

1) We still have Game States as individual objects

As you should.
 

2) Each Game State has its own list of Entities (probably some kind of "EntityManager")

So far no problem whether you are using an entity-component-system or any other scheme.
Directly under the state object you should have 1 or more instances of a SceneManager. The SceneManager would have an EntityManager if you go that route, or if you don’t it could have an ObjectManager etc. In either case you would want a SceneManager to orchestrate all the high-level rules of the scene (knowing when to run systems, etc., or how to tell object managers when to perfrom certain types of updates, etc.)
 

3) Game States have their own initialization logic: they can create their own entities during init. This logic is executed when the Game State is created or when it becomes active. We have a GameStateManager object to manage Game States life cycle

Now you are making the engine too restrictive. Your goal is to make the engine easy to use and have the updating of entities less of a copy-paste operation for each state but rather an automatic operation, but you end up trapping yourself into being unable to do anything at all without it going through the entity-component-system.
As I said above, updating the entity-component-system should be done via a SceneManager, which can be evoked by the state object directly (at any time the state object pleases). Not only can you have multiple scenes in a single state, you will certainly find it handy in the future to be able to perform some state-specific custom logic and rendering via the state’s Update() and Draw().
Update() and Draw() should always be there, even if you move to entity-component-systems.
If you want to make a point that most of the time every state will have the same Update() and Draw():
bool MyScene::Update() {
    m_SceneManager.Update();
}
bool MyScene::Draw() {
    m_SceneManager.Draw();
}
 
…then you can simplify without losing the freedom of Update()/Draw().

Add 2 virtual functions to the base State class:
virtual SceneManager * State::GetSceneManager() { return &m_DefaultSceneManager; } // Doesn’t need to be overridden often. All scene objects can use m_DefaultSceneManager.
virtual bool State::AutomaticUpdate() const { return true; } // Override to return false to activate the use of Draw()/Update().
The Game class will check AutomaticUpdate(), and if true it will call m_CurState->GetSceneManager()->Update() (etc.) automatically.
If false, it will call m_CurState->Update() (etc.) instead, allowing the states the freedom to manually perform updates and renders.
 

4) Entity Systems belong to the Game (not the Game States) but they only process those Entities that are contained by the currently active Game State

I don’t have any strong advice on where the systems should live. They likely won’t change throughout a game so they could be part of the Game object, but you could make them context-sensitive (to quote Conker’s Bad Fur Day) by making them part of the states. You could avoid rewriting a bunch of them for each state by making a common set of systems and allowing the states to pick from those (or add their own), with a function available to pick the “default” set. You can also make a hybrid system, taking systems from the Game object usually but with another State virtual method they could come from the state object instead.


L. Spiro

In Topic: Opengl Spazzing out for no reason

20 October 2014 - 11:43 PM

You will notice i commented out the assertion because i do actually get values outside 0 and 1.

So what do you think will happen to Factor at the end of the animation, or if 2 keyframes are on the same time-stamp, etc.?


L. Spiro


In Topic: Loading multiple 3D models in the VBO

15 October 2014 - 08:05 PM

Why are you trying to put multiple models into the same vertex buffer?

Why don’t they all have their own vertex buffers?

 

 

L. Spiro


In Topic: Why not use UE4?

15 October 2014 - 04:42 PM

Some potential  reasons, off the top of my head...

  • You don't want to pay money for an engine (keep in mind the $19/mo is only for code and tool access, you also owe 5% of gross revenue after the first $3k per quarter)
  • You want to something really weird and/or unique that could be better expressed with a custom engine, or that would be very difficult to do by modifying an existing engine
  • You think it will be fun and/or educational to make your own engine and that's more important to you than making and shipping a game
  • You already have a large engine or codebase that you're comfortable with, and that your team is also comfortable with
  • You just plain don't like something about UE4, and/or think you can do things better

Emphasis on what pertains to myself. Double emphasis on the main reason.

I make engines as a way to explore the technology.
If I feel like it, on a whim I can bust out from-scratch the code I need to put a game on the AppStore, or use an engine to do it, etc.
But that’s just for the sake of getting my idea made. It doesn’t teach me anything, especially not if I use an engine to do it.

 

Writing my own engine allows me hands-on in-depth exploration of the technology that goes into games, which makes me a better candidate for all of the jobs out there, and raises my overall market value, all while allowing me to still make any games I want on a whim if I please.

 

I just took a test for a high-paying position, and one of the questions asked to explain 2 problems with using decals to paint graffiti on a wall and then the solutions to those problems.

If I just use engines to do all the work for me, I doubt I would know the answer to that question.

 

When you can look at a game and see decals, soft shadows, realistic graphics, heavy particle simulations, etc., and say to yourself, “I know how all of that works,” it is a level of freedom above that of a programmer who relies on the work of others for all but the very basic game logic.  You are forever stuck with the limitations of the engines out there.  We are not.

 

 

Engine programmers are still game programmers.  Nothing stops us from making our own games the same as everyone else.

But we have higher market value because we can actually implement all the hard stuff.

 

And implementing all that hard stuff turns out to be more fun and rewarding than rewriting game logic every time for each new game.

That is why I write my own engines.

 

 

L. Spiro


In Topic: How to Create an Angle from a Yaw/Pitch matrix

09 October 2014 - 03:57 AM

Multiply a forward vector ([0,0,1]) by the resulting matrix (matYawPitch).

Normalize for safety (but it should be normalized already).

 

The vector is the direction of the bullets.

 

 

L. Spiro


PARTNERS