Elysian Shadows

wearymemory wrote:Oh, I get it now; that thing in your first video is a cell! I thought it was going to be like rockin' ragdoll tits or something, where you could brutally maul some awesome boobage. For some reason, I'm less attracted to the videos now, but nice progress nonetheless.

cypher1554R wrote:

wearymemory wrote:Oh, I get it now; that thing in your first video is a cell! I thought it was going to be like rockin' ragdoll tits or something, where you could brutally maul some awesome boobage. For some reason, I'm less attracted to the videos now, but nice progress nonetheless.

@K-Bal: This is a hint for your near future marketing plan reconsideration. ("near future" = now, that you're reading this) lol

K-Bal wrote:developer of SFGUI

GroundUpEngine wrote:

K-Bal wrote:developer of SFGUI

Awesome!!!

K-Bal wrote:I discussed the game state system with Tank and we ended up with a very different approach, that is much less error prone. I will go into further details on this soon.

rolland wrote:

K-Bal wrote:I discussed the game state system with Tank and we ended up with a very different approach, that is much less error prone. I will go into further details on this soon.

First, I'd like to say that your project looks pretty amazing so far. Second, I'll be waiting for that update.

#pragma once

#include <Cell/GameEngine.hpp>

namespace sf
{
    class Event;
}

class GameState
{

public:

    // Construction and destruction

    GameState( GameEngine& engine );

    virtual ~GameState();



    //

    bool Run( GameState* parent = 0 );



protected:

    // Allocate and deallocate Memory

    virtual bool Init() { return true; }

    virtual void Cleanup() { }



    // Logic

    virtual void Update( float time ) = 0;

    virtual void Render() const = 0;

    virtual void HandleEvent( const sf::Event& event ) = 0;



    // State changing

    void LaunchSubState( GameState* state, bool cleanup = true );

    void LeaveState();



private:

    // Non-Copyable

    GameState( const GameState& );

    GameState& operator=( const GameState& );



    // Enums

    enum Result
    {
        Continue = 0,
        LaunchState,
        Leave
    };



    // Member

    GameState* mSubState;

    bool mCleanUp;

    Result  mResult;



protected:

    GameEngine& mEngine;

    GameState* mParentState;

};

1) Since states are singletons you obviously can't have more than one state of one type. It is fine for what I'm doing right now, but it looks messy to me.

2) States have startup and cleanup functions which are called on a state change. However, if a state triggers a state change, the change is instantanious. That means while the main function of the state is still running, it's cleanup function is called and the startup function of the other state is called. This is bad but should be quite easy to change.

3) To create a state I have to create a new class, let it derive from GameState and implement all the functions. It works well enough but it is kinda slow. I want to have something that allows rapid development of game structures, e.g. through scripting.

4) I'm wondering what would be the best way to share common data between states, e.g. the GUI. I currently keep that stuff as a member of the game class with get/set-methods. Don't ask me why, but somehow it does not feel right to me.

Milch wrote:btw: You might also want to try out Bullet ( http://bulletphysics.org/wordpress/ )