Sirrf version 0.2.1 released! (30/08/2009)

[ZCCdark203]

Thank you for the kind words for Sirrf.

It has becoming more and more clear to me which potential Sirrf has. Reviews like the one you posted only confirm this to me. We'll certainly continue developing Sirrf and many more features will follow. Physics and networking are certainly on my mind. The question is not if, but when; at some point Sirrf will definitely support physics and networking.

Regarding multiple audio back-ends. Such feature would require a proper abstraction layer. At least, if we want to use the same kind of interface for all back-ends. In that light one could also ask whether it would actually be needed to implement multiple audio back-ends. After all, in the end the same features would be offered regardless of the back-end. Of course, we could also provide additional methods to provide back-end specific features. However, I'm not really sure if that would be worth our development time (contributions are welcome, though).
I do understand, though, that irrKlang is a lot more popular than SFML-Audio here. However, irrKlang is not an option for Sirrf as it's not open-source.

[FuzzYspo0N]

Thanks for posting the info d3jake. We appreciate the feedback!

On the audio abstraction, i agree with zccdark03 and the point of using a certain library is based on the library you choose, with reasons. Supporting everyones reasons is just a bad idea, as everyone has different needs.

Although, i do think that openAL is a better choice over SMFL, as its a lot smaller and we already have a decent interface for it, namely cAudio.

I think noting the abstraction is a good idea, and possibly implementing an interface for you to change the basic features of an audio engine, but if you want a full audio package you will most likely just suck it up and use something that works.

The point of writing an "engine" or framework that others can use to make games is so that the others can make games, and forget about all the underlying nonsense. Do you need sound in your game? This is how it is achieved. And you do it, thats all it takes. If you wanna be semantical though feel free to implement a third party interface for sirff, and others can use that all will as well

[omaremad]

This looks very intresting, are there any included examples?

[FuzzYspo0N]

Hey omaremad, thanks for the comment.

There are currently only a few tutorials, 0.3.0 promises to have all new tutorials, examples as well as the full website and better documentation.

For now though you can read more here :

http://sourceforge.net/apps/trac/sirrf/ ... als/v0.2.0

There are some docs here :

http://sirrf.sourceforge.net/docs/0.2.0/

And of course you may ask any and all questions here in the thread!

Please remember guys, the aim of this is to make it as great as we possibly can for your sake. We NEED feedback and ideas. Once the foundations are in we will even need teams to assist us in completion of certain tasks..

For now though, why not put some ideas up for us :

http://sourceforge.net/apps/ideatorrent/sirrf/

[d3jake]

Well, I've got a question or two, come to think of it.

Fuzzy told me that with Angelscript that everything will be scriptable. Aside from singleplayer scripts (i.e. switch x turns on forcefield Y) and multiplayer mods, what uses are there? Would it be used to script menus, or would that be done in the C++? Will the next version supply multiple examples?

Also, how is the control system going to work? Will it be an array of bools (like in many example code snippets), or will it be more similar to mine in that the eventreceiver (however it is done in this framework) a certain key is bound to an action so a flag isn't set and then checked in the game logic?

[ZCCdark203]

Fuzzy told me that with Angelscript that everything will be scriptable. Aside from singleplayer scripts (i.e. switch x turns on forcefield Y) and multiplayer mods, what uses are there? Would it be used to script menus, or would that be done in the C++? Will the next version supply multiple examples?

At the moment it's not possible to create menu's from scripts. So far scripting should be used for tasks you would normally perform with the help of scripts. These include the scripts you mentioned, but it could also be applied to AI.

The biggest advantage of the integrated AngelScript, however, is that it provides users the ability a safe (sandbox) way to define their application without the needs of compilation.

As for examples, we're definitely need to work on that.

Also, how is the control system going to work? Will it be an array of bools (like in many example code snippets), or will it be more similar to mine in that the eventreceiver (however it is done in this framework) a certain key is bound to an action so a flag isn't set and then checked in the game logic?

In Sirrf you can apply both methods. Sirrf's EventManager class provides the appropriate methods for both ways. You could use the event system itself:

Code: Select all

GameManager::Instance()->getEventManager()->connectEventSignal("EventManager", "onKeyDown#KEY_UP", this, &MyClass::onKeyUp);

However, you could also do the following:

Code: Select all

GameManager::Instance()->getEventManager()->getIsKeyDown(KEY_UP);

Which one you're going to use is up to you.

[d3jake]

Interesting... Could something like HUD building be scripted? So you could define: x% from the left, and y% from the bottom make a status bar for energy, use this animation and iterator through the frames every 15 energy between 0 and 100, and automatically tell the framework\enigne to auto update it?
I think being able to script the user's HUD would be a great addition. Some way to define which parts represent which varibles, so it's taken care of and the user won't have to worry about updating it every frame, etc.

[ZCCdark203]

From what I understood you're asking for a system that observes a certain variable (i.e. health), and triggers a change elsewhere in the framework. If that's not the case then please correct me. If it's the case, then I'm not sure if it should be implemented, because said behaviour can already be accomplished.

Here's an example:

HealthComponent.h

Code: Select all

// Include files
#include "/path/to/core/EntityComponent.h"


// HealthComponent class
class HealthComponent : public EntityComponent
{
public:

     // Initialisation and deinitialisation
     HealthComponent(Entity *parent);
     ~HealthComponent();

     // Public methods
    u32 getHealth() const;
     void setHealth(u32 health);

private:

      // Private methods
      u32 mHealth;
};

HealthComponent.cpp

Code: Select all

// Include files
#include "HealthComponent.h"


// HealthComponent class
// HealthComponent constructor.
HealthComponent::HealthComponent(Entity *parent)
: EntityComponent(parent), mHealth(100)
{
     pParent->createEventSlot("onHealth");
}

// HealthComponent deconstructor
HealthComponent::~HealthComponent()
{
}

// Get health.
u32 HealthComponent::getHealth() const
{
     return mHealth;
}

// Set health.
void HealthComponent::setHealth(u32 health)
{
     mHealth = health;
     pParent->emitEvent("onHealth", &mHealth);
}

// End of File

And then the "observer" would need to connect to the appropriate event slot:

Code: Select all

PlayerController::PlayerController(Entity *parent)
: EntityComponent(parent)
{
    ...  // Initialisation
    pParent->connectEventSignal("onHealth", this, &PlayerController::onHealth);
}

void PlayerController::onHealth(void *p)
{
     u32 health = reinterpret_cast<u32*>(p)[0];
     // Do something fun with the new value.
}

Please note that sharing events between entities is also possible.

[aanderse]

btw line 78 of the scripted game state class is wrong in trunk.

[FuzzYspo0N]

Thanks for pointing that out aanderse. It will be corrected asap.

For those interested i am nearly finished the first example

[ZCCdark203]

Sirrf 0.2.1 has been released!

---

Sirrf - Simple Irrlicht Framework - version 0.2.1 released!

0.2.1 is here, 9 days later the simple irrlicht framework team re-emerges with a feature and bug release. Some bugs have been fixed and some new features introduced, the changes include :

• Script-side GameStates
  It is now truely possible to derive from the GameState class (through CGameState) in scripts. A bug in previous versions prevented this, but this bug has now been fixed.
  
  Script-side Components
  EntityComponent can be derived from script-side (through CEntityComponent), classes in script can now create components and register them with entities from script or engine side.
  
  Script-side Events
  The event system is now integrated into the script engine. Script-side classes can derive from IHasSlots and can register, connect and disconnect from slot events.
  
  Important Bug Fixes:
  
  • Construction of entity components with parent is now relatively safe. If you are not sure whether your component has a parent, check it after construction. If the component has no parent, destroy it as quickly as possible
    
    AssetProcessors on windows were never loading assets unless the files were all lowercase, restrictions were irrlicht related but solved.
    
    Minor bug fixes with script side things, Scolor fixes, asset groups on entities and much much more.

Useful links
SourceForge.net page - http://sourceforge.net/projects/sirrf
Downloads - http://sourceforge.net/projects/sirrf/files/ | http://www.ohloh.net/p/sirrf/download?package=Sirrf
Documentation - http://sirrf.sourceforge.net/docs/0.2.1/ | http://sourceforge.net/apps/trac/sirrf/ ... als/v0.2.1

[lulzfish]

I think it might be helpful if your website or somewhere explained what Sirrf actually does.

I see it's a "game framework", but I'm not sure what it's supposed to do, and I'm too lazy to download it just to find out.

[FuzzYspo0N]

You didnt look very far? not very far at all (from the sourceforge page, right at the top)

Making a game isn't a simple task. That's where Sirrf steps in. The goal of the Sirrf project is to create an extensive, but simple open-source framework to enable rapid game development.

From the documentation :

Sirrf, the Simple Irrlicht Framework, is a free, open source, extendible, and cross-platform framework for building games based upon the popular Irrlicht Engine

From the tutorials :

Sirrf provides end-users a game skeleton which implements concepts such as states, component-based entities and a datastore. That means that you can focus on the development of concepts that make your game unique, instead of working at the earlier mentioned common concepts.

If you dont understand what a framework is you can just ask google, pretty sure its quite extensive. PLUS the API has loads of information right online, no download required.

Hope that clears things up. Feel free to ask more

[leave]

can You write a small game examples? It is intuitive.we need it to study.

[ZCCdark203]

can You write a small game examples? It is intuitive.we need it to study.

Small game examples are planned for the upcoming version (0.3.0) of Sirrf. I can't give an ETA, though, as I don't have that much time as I had a couple of months ago. For now I would suggest to look at the tutorials and Doxygen documentation. And if you have further questions you can post them here.