Jump to content


Member Since 06 Oct 2007
Offline Last Active Today, 05:45 AM

Posts I've Made

In Topic: Physics and entity-component system (ECS)

01 March 2017 - 01:03 AM

There are much more reasons for ECS then performance. In that case Hardware is important and the most obvious thing about current hardware is many core CPU so Multithreading in efficient way. AMD is comming out with friendlier priced 8cores with SMT. So 8cores could become the new 4 thread limit. So utilising future CPU and wat mainstream wil become is supporting beyond 10 threads?

Those other reasons depend largly on what type of game you gonna make and if ECS is solution that support specific features best.

ECS in the DOD way offers this.
If you game have high numbers of entitys.
If you have lot of different types of entities.
If you can assemble types in runtime.
If you want to procedural generate types with different mix of components.
If you want to change entitys runtime.

A bad case for ECS is 1 on 1 counter sniper game with complex balistics.
A good case is game like Arma where few units spam bullits with 2K to 10K Rounds per minute from gatling gun. Mounted on armored units air units attack heli in large scale warfare.
A even better fit would be space game where there are no fix classes but design units in game with procedural but can also load design in or designing ships is part of core game.

ECS for game like Pong or tetris clone. Then ECS might be huge overkill solution.

My idea of space game is like as with cars naval ship. In Century of carse there are a lot of types spread over years in the few hundres so procedural need.
Naval most ships have a specific design and there are only few build of the sane type and bigger the more uniek they are. Also lot of diversity.

I expect the counter part of T- ford to bugaty Venyon in space.
But also naval counter pars of century of torpedoboats and nimitz class carriers.
Many types of bombere fighters frigates of centuries of space Warfare.

Often you don't rely on ECS but my case i might need it badly.

In Topic: UML diagrams for video games

16 October 2016 - 07:07 AM

The way I understand it. UML is a standard. And it explains it self rather very well.
The L wich stand for " Language"
It purpouse it to communicate Modeling. If both participant know UML then they communicate the model to each other.
If only one ore none knows UML but uses there own way of expressing model. Sketches.
Then they need to explane what it means to the Other.

Me thinks in specific branches like game development and small teams The use of it is often not needed.
But in large corporation with huge teams and lot of junior programmers its good thing to speak the same language and know the same modeling language.
In software where there is lot of change and no clear target as in games.
But in large scale bussness software where there is legacy stuf from decades no drastical changes.
But if new employer come in they can read the UML and see the bigger picture or that part of the package or module.

Two fictional examples.
Mostly in UML example they come from bussness side.
Like bank where your department team design the ATM software for specific new ATM model.
In this case the use cases are clear also as it done before for older ATM models .
In your team are two new employers. If corporation uses UML and the new team members knows UML . Communicating the job can be started right on.

Indie dev team of 5 experimenting with new idea going for prototyping a few ideas
How do you usecase gameplay and fun. Where most are self tought programmers and there dev experience are of one man to less then 7 teams . No UML. Sketches wil do.

My experience as first impression of somebody else software base. A DX11 example bundle and framework.
Then I compile that frame work of other dev from internet as DX11 example bundle .

You see long list of project which depend on other projects in that list where some project are end app tech sample demos using the framework project. Mixed in that long list.
With in each project there is huge list of .H and Cpp files where there is no insight of dependancies.

In my own very little pet project it not a problem one project and a short list of files.

My own project are so small I don't need UML. I am alone so for Communicating with myself. Make sense after 6 month I have no clue what I did. If my project got bigger. It would be nice.

In Topic: Multi thread rendering engine

18 September 2016 - 04:11 AM

Multithreaded renderengine is not the same as a multithreaden game engine. To me it means the render system or component and render backend is that multithreaded or not.
DX11 supports multithreaded with defered contex , but the result of that , it doesn't yield much Gains.

With Mantle and DX12 and Vulkan is it possible to use eficently multithreading for rendering and ACE Asynchonoc compute engine
For rendering compute and kopy Engines
That means if your game load and GPU settings are CPU bound. Like a huge amount of drawcalls.
And with these new efficient low overhead API it factor 10 x or so more drawcalls are possible compared to the old API.

So to me it seams do you want to render multithreaded and go wild with drawcalls then you need DX12 or Vulkan.

Where the game engine often already is multithreaded and there is also the same isue you can do it easy way with low or limited gains , or better advanced ways where you can gain a lot.

Multithreading game engine is is something differrent then multithreaded rendering. The last is specific the new API and the whole engine is complex topic to not only multithread tread save but also do it efficently so to scale well on more cores. But also beyond 4 cores. But the render component is part of the larger full engine so there architecture need to fit very well so they are strongly related.

So I would read into DX12 multithreading.
Don't know yet if my DX12 book dives deep into that matter.

In Topic: Space Simulation Game Design (Finding The Fun)

07 July 2016 - 11:57 PM

X- series I have a lot of fun with . But not Rebirth which is very different .
The problem with Egosoft is small budged complex game production . A production that don't fit within budged . Bad decision to try go for consoles . Where unfinished rushedout games are blocked .
So there 1.0 releases are Alfa sold as Release games . Where 2,x are Beta .
Depending on mod community to fix thing to finish gameplay mechanics and making it feature conpleet .
Because at that time there wasn't anything big in the genre . They where the only one I thank them for supporting the genre . Now the genre got mild revival .
They did some thing right compared to current big ones . And that staying away from MMO .

Biggest problem is A cumbersome GUI that not fully implented and a hog to handle the farious gameplay the game offer .
Yes they did have carriers but with no GUI and gameplay workt out for it . There where mod to ease the pain.

So because my interrest in game development
I get strong impression that these complex games depend highly on strong AI and GUI development .
As one person can not manage a whole nation doing work of milions and babysit milions .

In Topic: Component based architecture .... for game!

14 June 2016 - 05:40 AM

>>  It's how often you combine these things into game objects like ships, or cars, and make new ones with tweaks etc.  [/size]
that's what i call defining a new "entity type". IE a new kind of "game object".   some games must do this often and have many people who must be able to do it with various skill sets, and some games do not. like most things it depends on the work to be done, and the size and skills of the team.[/size]
IE if you were going to bang out pong, pacman, galaga, space invaders, or missile command, etc. by yourself on weekend just for fun, you wouldn't bother with ECS.[/size]


Personally, I like the Unity approach. You get most of the benefits of components without the unnecessary trouble that complete decoupling causes. None of the games I've worked on that shipped - or the ones that were cancelled! - used the "entity is just an ID" mantra because it buys you little but costs you a lot in terms of code clarity and predictability. Some of the people above will disagree, obviously.

As Norman Barrows stated. It depends on the game. The example there don't need it.
Entity is just a ID is used in the Data Oriented Design. The value of that and its features used in pure form might be noticed in much bigger game.
The way it noticed is if you got a lot of something. If entity need to change component on run time. Move components in memory. Make new entity by combining components even in run time.
I think it would be noticable the benefit if your making a game. With the scope of.
A Space tactical stratigic game , where game is about
* In game design ship types . By player content driven game. Not just data driven but beyonpd that.
* in game tweak components stats . Bigger ship can have bigger guns.
* build fleets .
* And watch the AI fight it out or act like armada Admiral player vs player etc.
* if you got carriers with dozen types of Fighters etc. It makes Entity in numbers very large.
* drone frigates it can make entities insane. Launched 300 or so in a X series game.
* Missile frigates. Missile barage like Egosoft Xseries

Then a more pure form of ECS the DOD way make sense.

There are a lot of games from small to big there is not a lot of something and no need to mutate objects. So it make no sense to go with ID for Entity. But there are game concept where it have great value.