Messages

1

General discussions / Re: Resources and discussion about good game engine design and clean code

« on: February 21, 2017, 04:57:33 am »

Much like Ironbell I think game and engine should be separate, but I think go one step further split up your code into two main aspects, each having very modular and as much as possible separate libraries:

• Game Engine
• Rendering
• Physics
• Networking
• File
• Logging
• Command Line Parsing Library
• Reflection
• Serialisation\Deserialisation
• Entity System
• Scene Management
• Input
• Audio
• UI
• Pathfinding
• Framework
• Inventory\Item\Equipment System
• Statistic System (Health, Mana, Strength etc)
• Quest System
• Ability System
• Weather System
• Player Controllers
• AI Controllers

Then all your game really is, is linking and initialising the systems, libraries and modules you want to use and then providing the data for them.

The next step is then have a clean API. By clean I mean only have one method for doing something. Look at this as an example:

Entity* entity = new Entity(...);
world->AddEntity(entity);

// And

Entity* world->CreateEntity(...);

// And

Entity* entity = new Entity(world, ...);

 

What you want to think about is, will the end user be confused by this many options and what is my actual use case for this code? Does an entity need a world or vice versa? Who owns the entity? Can we simplify to one option?

From there it's the basic:

• Const correctness
• Smart Pointer \ Owner semantics
• Single Responsibility Principle

2

General / Re: Why not decouple transform \ render?

« on: September 23, 2016, 08:03:16 am »

inherit from Transformable rather than contain one, why is that?

What would the API look like if entities contained a transform rather than being transformable? Something like entity.setTransform(sf::Transform)?

I don't see a reason to set a transform after creation although there might be a use case, I prefer to force it as a dependency as it is required. Although I may be wrong! E.g this is my code copy-pasted:

SmartDrawable::SmartDrawable(SmartTransformable& transformable) : sf::Drawable(),
                m_smartTransformable(transformable)
{
}

So I guess a simplified question would be: Using that node class as an example, is it better to do my implementation (Making a transformable directly have parent\child relationships and removing the inheritance usage of Transformable) or use that node class and changing it to separate where the combinedTransform is calculated and the drawing occurs?

I'd say it's easier to calculate the transform elsewhere. You can also collect the nodes and reorder them as you want for rendering. There are many possible implementations.

Unless you split the transform calculation and node drawing you can't reorder nodes as that might mess up some specific child->parent relationship. E.g an orb that hovers in front of \ behind a character while also inheriting it's transform wouldn't want to be re-ordered to be the characters parent.

3

General / Re: Why not decouple transform \ render?

« on: September 23, 2016, 02:27:23 am »

SFML doesn't force any design

The given drawables are given a design choice and that is to inherit from Transformable rather than contain one, why is that? I assume it's purely from ease of use perspective rather than good coding perspective.

You can perfectly use external transforms (in sf::RenderState) and leave the internal ones to identity.

Yes, I do this in my code now. Yeah the typical solution creates a situation of a set rendering order in the hierarchies, something I don't want. That's why I started this discussion on a non-typical implementation.

So I guess a simplified question would be: Using that node class as an example, is it better to do my implementation (Making a transformable directly have parent\child relationships and removing the inheritance usage of Transformable) or use that node class and changing it to separate where the combinedTransform is calculated and the drawing occurs?

4

General / Why not decouple transform \ render?

« on: September 22, 2016, 08:17:08 am »

Hey guys, I would like to start a discussion about why all things drawable inherit from transformable. To me it makes sense to use composition to give drawables a transform. E.g. sf::Sprite HAS A transform rather than sf::Sprite IS A transform.

First my use case:

• I want to have a hierarchy of transforms for my sprites or drawables.
• But I don't want that hierarchy to control the draw order

To that end I re-wrote those classes into what I call 'SmartDrawables and SmartTransformables'. They aren't really smart they just allow me to write this:

sf::SmartTransformable rootTransform;
sf::SmartTransformable someTransform;

sf::Sprite rootSprite(rootTransform, texture);
sf::Sprite someSprite(someTransform, texture);

rootTransform.addChild(someTransform);

// In an update somewhere.
rootTransform.rotate(0.1f);
rootTransform.updateTransforms(); // Goes through the heirarchy.

window.draw(someSprite); // Draw in whatever order we want, regardless of parent->child relationship.
window.draw(rootSprite);
 

So my questions:

• Is this a dumb idea and have I missed something obvious?
• Are there better ways to do this?
• Should SFML follow the 'Prefer composition over inheritance rule' in this situation?

A pic is attached, the blue one represents the child and is being rendered below the parent.

5

General / Re: Trouble building SFML 2.0 snapshot with VS 2010 Pro

« on: June 06, 2012, 06:36:51 am »

MSVCRTD.lib(crtexew.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function ___tmainCRTStartup

Have you tried solutions from googling this error ID?

Here are some potential solutions:

1. Please change the "subsystem" in your linker settings from "Windows" to "Console".
2. In the Output category of the Link tab in the Project Settings dialog box, set the Entry Point Symbol to wWinMainCRTStartup.