Cell - An Action Game

[cypher1554R]

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]

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

Lol'd very hard. Hint has been recognized. Updates commencing again in two days. STOP.

[K-Bal]

Update

- Team

I am proud to announce that Tank has joined the development of Cell as a further programmer. I feel very honored because he is the maintainer of pySFML and the German SFML web page and he is also the developer of SFGUI, the greatest GUI lib for SFML ever created. He also supplied the project with a git repository and a redmine project management page. His fields of work will be GUI- and network-related aspects.

- Game States

I came to the conclusion that game states are mostly pretty static and therefore the system actually does not have to be as dynamic or scriptable as I thought. However, I will make some minor improvements in my new implementation, considering the changing of game states and I will also make game states non-singletons. I haven't come up with a solution for shared variables between game states though.

Stay tuned. There is going to be some progress

Marius

[GroundUpEngine]

Nice update!

developer of SFGUI

Awesome!!!

[K-Bal]

developer of SFGUI

Awesome!!!

Indeed! He is one of the best programmers I've got to know so far.

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]

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.

[K-Bal]

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.

Thank you! I'll give a brief explanation of how it works

Game states are now self-managed and contain a full game loop (this is managed by the base class, so no need to reimplement it every time a state is created). There is no extern game state managing class anymore. There is still a game engine class, but it's only purpose is to provide shared data to all game states. Game states can spawn sub-states (e.g. main game spawns item inventory). Here is the interface:

Code: Select all

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

};

EDIT:

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.

Game states are no singletons anymore.

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.

State changes are now queued until the end of the game loop cycle.

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.

This is unfortunately still the case, but I came to the conclusion that it is not really that bad since state structures are very static and normally there are only a few states.

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.

Common data is in the GameEngine class. Didn't come up with a better solution but it doesn't seem that bad for now.

[K-Bal]

Update

So there is some work happening behind the scenes I have to say that we produce almost no code, but that is not a bad thing. We have extremely fruitful discussions on the underlying software architectures. All class interfaces are reviewed several times to assure that long term reliability can be assured. We are not writing much code but what we write is by all team members considered to be solid. This has led to a component entity system which is much different from what was discussed in the other thread on this board. I will go into further details on this system after I have implemented and tested it thoroughly.

Tank is currently working very hard on rewriting SFGUI to boost it from absolutely awesome to unbelievably epic. Meanwhile my friend Dens is testing different physics engines to evaluate which one is most suitable for Cell. This is a very important point due to the fact that Box2D didn't really fit into our vision of a neat physics engine. So here is a small demo using ODE as a physics engine and so far it seems to be quite nice:



There is a lot more going on than this thread might reveal

Cheers,
Marius

[dandymcgee]

Great to hear, thanks for posting!

[Milch]

Great update!
Already looking forward to your explanation of your component entitiy system

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

[K-Bal]

Thank you guys!

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

Indeed, that looks very nice. Thanks for the hint