SFML community forums

General => SFML projects => Topic started by: foobarbaz on April 17, 2013, 11:26:57 pm

Title: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 17, 2013, 11:26:57 pm

.

Title: Re: Fission - A simple, object-component based game engine
Post by: Tank on April 18, 2013, 08:50:24 am

Quote

GUI with SFGUI (works great - thanks, Tank!)

You're welcome, but don't forget the other contributors. ;)

Speaking of myself, I often miss screenshots and/or videos from project announcements. Can't you provide some?

Title: Re: Fission - A simple, object-component based game engine
Post by: binary1248 on April 18, 2013, 12:40:40 pm

Bah... this means I still have a reason to work on SFGUI -_-

jk :P Nice job, it's always a good feeling to see the library put to good use :)

Title: Re: Fission - A simple, object-component based game engine
Post by: Tank on April 18, 2013, 01:22:29 pm

Nice, that project actually looks like you are working on it for quite a long time. I'm not a fan of the graphics style, but that's just eyecandy. ;)

Oh btw, are you accepting shirts? ;)

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 18, 2013, 07:09:14 pm

Quote from: Tank on April 18, 2013, 01:22:29 pm

Nice, that project actually looks like you are working on it for quite a long time. I'm not a fan of the graphics style, but that's just eyecandy. ;)

Well, this is actually a rewrite, so up to this point I've known exactly where to go next. Last semester, I worked on this game for like 2 months and ended up giving after I couldn't resolve the lag issues. But now all is well! Also, having Fission always helps - last semester the game had it's own game engine. I did have Fission last semester, but I felt like the game deserved its own game engine. It doesn't. Haha.

You can take the art up with my roommate ;)

Quote from: Tank on April 18, 2013, 01:22:29 pm

Oh btw, are you accepting shirts? ;)

Ehh. It's hot here in Hawaii.

Quote from: binary1248 on April 18, 2013, 12:40:40 pm

Bah... this means I still have a reason to work on SFGUI -_-

jk :P Nice job, it's always a good feeling to see the library put to good use :)

Haha, thanks! I am putting it to very good use. I hate GUI programming so, so much. But SFGUI is like my ibuprofen :)

Title: Re: Fission - A simple, object-component based game engine
Post by: Lo-X on April 18, 2013, 08:29:36 pm

Hell Yeah !

I'll definitely follow that github page, perhaps fork it if I think I can add something =)

A BIIIIGGG thank you !

Title: Re: Fission - A simple, object-component based game engine
Post by: ZackTheHuman on April 19, 2013, 01:34:21 am

Quote from: DrSuperSocks on April 17, 2013, 11:26:57 pm

Get it here: https://github.com/DrSuperSocks/Fission (https://github.com/DrSuperSocks/Fission)

This is cool; thanks for posting it. I'm poking through the code now.

I think there may be a problem in your example client/server files: https://github.com/DrSuperSocks/Fission/blob/master/mainClient.cpp#L16

int main()
{
    Game *game = new Game(800, 600);
    game->run(new GameState(game));    // where do I get deleted?
    delete game;

    return 0;
}

It looks like a memory leak -- how does the "new GameState" get deleted?

Title: Re: Fission - A simple, object-component based game engine
Post by: Nexus on April 19, 2013, 06:25:25 am

In general, don't use raw new and delete. Rather use RAII (http://en.sfml-dev.org/forums/index.php?topic=9359).

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 19, 2013, 07:50:21 am

States are deleted when they are popped from the state stack. So, you could have a main menu state, then push a game state. Then when the game state is popped, it will be deleted and you will return to the main menu. You were right though, there was a scenario in which the state wouldn't be deleted, but I just uploaded the fix :)

Title: AW: Fission - A simple, object-component based game engine
Post by: eXpl0it3r on April 19, 2013, 09:00:43 am

Have read the posts Nexus linked?
It doesn't really matter whether you think you've covered it all or not, because it's near impossible to cover ecerything (see link above).
With a std::unique_ptr around every state you're guaranteed, that it will get destroyed when it runs out of scope, no matter what. ;)

Title: Re: Fission - A simple, object-component based game engine
Post by: FRex on April 19, 2013, 09:09:08 am

Because memory management using new and delete is what all the cool kids do. :P
I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes. :P

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 19, 2013, 09:12:57 am

I glanced at it and will probably implement the smart pointers soon, but it's not an urgent issue as it's not a professional game engine ;) If it turns out that a ridiculous amount of people want to use it maybe I will take my memory management more seriously haha.

Thanks for the suggestions though, I will definitely get around to implementing it, as I do plan on releasing my current project on Desura, and hopefully it'll be good enough where I can sell it for at least a buck :P

Title: Re: Fission - A simple, object-component based game engine
Post by: Nexus on April 19, 2013, 12:34:54 pm

Note that using RAII is much simpler than manual memory management, so you spend less time on it, make fewer errors and thus develop faster :)

I have taken a closer look at your code, here are some more tipps:

• Use constructor initializer lists instead of assignments.
• To iterate over a sequence, prefer iterators over indices. It allows more flexibility to choose another container, and may be faster.
• Pass big objects like std::string per const-reference.
  
• Combining new[] with delete is undefined behavior (Scene.cpp). Use std::vector instead.
  
• Use the fixed-size types like sf::Int32 when working with packets. It is not guaranteed that int has the same size everywhere.
  
• Replace C casts with the C++ cast operators (mainly static_cast, const_cast, reinterpret_cast).
  
• For indices, take std::size_t instead of int or unsigned int, this avoids also conversion warnings. Or at least be consistent.
  
• Declare member functions that do not change the object (i.e. all getters) as const.
  
• By not making all the managers to singletons, you allow other uses. I don't see why they need to be a singleton, the alleged convenience has many disadvantages, which are not necessary with a clean design.
• You can reduce compile time if you do not include <SFML/Graphics.hpp>, but specific headers.
  
• I recommend to make member variables private instead of protected. Derived classes should have access via public/protected member functions.
• You don't need to re-declare the virtual destructor in every class, it is inherited.

Title: Re: Fission - A simple, object-component based game engine
Post by: ZackTheHuman on April 19, 2013, 06:25:06 pm

Quote from: FRex on April 19, 2013, 09:09:08 am

I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes. :P

I didn't mean to derail the thread -- it's just that the files containing the most basic example of how to use the OP's code have unclear object ownership, which makes me worry about any other part of the code.

Quote from: DrSuperSocks on April 19, 2013, 09:12:57 am

...maybe I will take my memory management more seriously haha.

I am in favor of this idea. If you want other people to use your code (and it's awesome that you do!) then you have to work hard at making it clear how it works.

I think there is a lot of cool stuff in Fission, and I'm still going through it to see how it works. Thanks again for sharing with us.

Title: Re: Fission - A simple, object-component based game engine
Post by: FRex on April 19, 2013, 07:21:24 pm

Quote from: ZackTheHuman on April 19, 2013, 06:25:06 pm

Quote from: FRex on April 19, 2013, 09:09:08 am

I knew this thread was gonna end like this after I've seen the code on github using bare news and deletes. :P

I didn't mean to derail the thread -- it's just that the files containing the most basic example of how to use the OP's code have unclear object ownership, which makes me worry about any other part of the code.

You didn't :P, in presence of Nexus any post that is traceable to manual memory management(and especially bugs in it) is derailed by definition.

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 19, 2013, 08:29:26 pm

Nexus, thanks for the detailed feedback! You sound like a pretty picky coder ;) I will definitely do that stuff this weekend. Here I was feeling like the hot-shot freshman who codes circles around all the seniors, but I guess I have a long way to go :)

Quote from: Nexus on April 19, 2013, 12:34:54 pm

By not making all the managers to singletons, you allow other uses. I don't see why they need to be a singleton, the alleged convenience has many disadvantages, which are not necessary with a clean design.

I've definitely been going back an forth with the singleton design for the Managers - the problem became more evident when I started coding a scene editor. Could the Game class be a singleton to access all of the managers?

Quote from: ZackTheHuman on April 19, 2013, 06:25:06 pm

I am in favor of this idea. If you want other people to use your code (and it's awesome that you do!) then you have to work hard at making it clear how it works.

I think there is a lot of cool stuff in Fission, and I'm still going through it to see how it works. Thanks again for sharing with us.

Yeah, I've been thinking about that. I need to go through and add comments for Doxygen, which I've never used before :0 And thanks! Means a lot :)

Title: Re: Fission - A simple, object-component based game engine
Post by: Nexus on April 20, 2013, 05:55:42 pm

Quote from: FRex on April 19, 2013, 09:09:08 am

You didn't :P, in presence of Nexus any post that is traceable to manual memory management(and especially bugs in it) is derailed by definition.

Meanwhile I at least point to the RAII thread, instead of explaining everything again and again. :P

And yes, I find it important to create awareness of idioms like RAII -- unfortunately, most game developers have very limited knowledge about them. In my opinion, modern C++ techniques are as important as other game development techniques.

Quote from: DrSuperSocks on April 19, 2013, 08:29:26 pm

Nexus, thanks for the detailed feedback! You sound like a pretty picky coder ;)

You're welcome. You're right, you have to be picky when you want to develop an open-source library :D

Quote from: DrSuperSocks on April 19, 2013, 08:29:26 pm

Could the Game class be a singleton to access all of the managers?

Why should it? Can't the game class just contain the component managers as members? There is almost always an alternative design to singletons.

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 20, 2013, 10:27:46 pm

Well, if neither the managers nor the Game class are singletons, pretty much every single class will need a reference to the Game. I suppose at that point I'd just create a base class called GameRef or something. Does that sound good? I apologize for the C++ lessons in the project announcements. Haha. Then I'd access the managers this way:

mGame->getSomeManager()->doMyStuff()

Title: Re: Fission - A simple, object-component based game engine
Post by: MorleyDev on April 20, 2013, 10:52:28 pm

The question here is: Why? What does Game do that everything needs to know of? And should it do that? Is that the kind of thing that belongs in Game? Or is it something that is not the responsibility of Game?

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 20, 2013, 11:50:50 pm

Quote from: MorleyDev on April 20, 2013, 10:52:28 pm

The question here is: Why? What does Game do that everything needs to know of? And should it do that? Is that the kind of thing that belongs in Game? Or is it something that is not the responsibility of Game?

Game holds all of the managers - RenderingManager, PhysicsManager, etc. If there are no singletons, every single class that needs to reference any manager needs a reference to its corresponding Game. I just finished implementing it - now off to finish Nexus' other suggestions. Right now, all classes that need to reference Game (primarily to take advantage of the Game as the middleman to get to the managers) inherit from GameRef, which takes a Game* as a parameter to the constructor, has a private Game* member, and has a corresponding accessor.

Title: Re: Fission - A simple, object-component based game engine
Post by: Nexus on April 21, 2013, 11:31:54 am

Quote from: DrSuperSocks on April 20, 2013, 11:50:50 pm

If there are no singletons, every single class that needs to reference any manager needs a reference to its corresponding Game.

Why can't it have a direct reference to the manager? You create a lot of dependencies if every class knows Game and thus every manager.

Quote from: DrSuperSocks on April 20, 2013, 11:50:50 pm

Right now, all classes that need to reference Game [...] inherit from GameRef, which takes a Game* as a parameter to the constructor, has a private Game* member, and has a corresponding accessor.

That sounds unconventional, but it's already much better than the singletons ;)

But I would still try to further reduce interfaces between different modules. If a game module only needs access to the audio component, there is no point in giving it access to all the managers -- that just adds dependencies between modules (which increases the complexity) and raises compile time.

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 21, 2013, 10:34:16 pm

Alright, I will give this some more thought. The immediate idea that pops into my mind is a template class called InstanceRef where the template parameter is the instance's class type. It'll be essentially the same as the GameRef class only an abstracted template for any kind of instance. Then I can typedef different Manager references in their headers. Then, I can derive classes that need access to a manager from the corresponding manager reference class.

I started out trying to have modules have no dependency on each other, but as I stopped focusing on the engine and more on the games I started getting sloppy and just adding quickfixes to make games work quickly haha.

Title: Re: Fission - A simple, object-component based game engine
Post by: MorleyDev on April 22, 2013, 01:17:58 am

In general the hardest and most valuable thing you can learn is to "listen to the code" (to sound all spiritual and woola for a second there). By that I mean programmers know when we're doing things that are sloppy, but often go headlong with it anyway. It's one of the most difficult things to just stop yourself there and then, back off and think: What are my alternatives?

More often than not the answer is just a simple refactor, to bring out some new class (a dependency) to allow for everything to keep the responsibilities in the right place. After all, feature creep is a danger to a project not only on a project level, but on a function and class level.

That's why I use TDD personally, means code has to be testable and the sloppy things tend to make code difficult to test so you get a nice early warning :) Unfortunately C++ and the tools available still makes the act of refactoring more cumbersome than it is for languages like C# or Java (especially since they have incredible tools like Resharper and IntelliJ available).

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on April 22, 2013, 11:20:39 pm

Hahaha - spiritual coding. Yeah, code refactoring is not my favorite chore :/

Title: Re: Fission - A simple, object-component based game engine
Post by: EpsilonJackal on May 02, 2013, 12:17:58 am

Some .cpp files are missing their header counterparts. Also getting a ton of redefinition errors.

This is all very confusing to implement x.x.

Nevertheless this seems very awesome.

Title: Re: Fission - A simple, object-component based game engine
Post by: foobarbaz on May 03, 2013, 07:28:43 am

Quote from: EpsilonJackal on May 02, 2013, 12:17:58 am

Some .cpp files are missing their header counterparts. Also getting a ton of redefinition errors.

This is all very confusing to implement x.x.

Nevertheless this seems very awesome.

Are you trying to compile this from the codeblocks project? If not, you can PM me how you have the project set up and I'll help you get it all sorted out. But if you are using the codeblocks project, that's really strange that these errors are coming up, but you can still PM me! I apologize for the lack of documentation. My finals are next week, so I'll have more time after that to get this more usable.

And thanks, I appreciate the compliment :P