Fission - A simple, object-component based game engine

[foobarbaz]

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

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?

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

[Nexus]

You didn't , 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.

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.

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

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.

[foobarbaz]

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()

[MorleyDev]

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?

[foobarbaz]

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.

[Nexus]

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.

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.

[foobarbaz]

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.

[MorleyDev]

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).

[foobarbaz]

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

[EpsilonJackal]

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.

[foobarbaz]

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