Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 7 developers from Canada and 18 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 06 Oct 2007
Offline Last Active Aug 28 2015 02:20 PM

Posts I've Made

In Topic: Equipment/modules for ships

01 April 2015 - 11:44 PM

Well it seams logical that fleets and ships manage repairs and upgrading them selfs. No deep micro management there.

If you have many fleets some might be reserve to re- enforce or replace battle reduced fleet.

Ship damage comes in light and heavy. Light can be repaired by ship crew medium need repair assistance heavy damage a repar frigate. Or equipment dock. While severe damage means shipyard or repair dock.
That means depending on mission impotance. Some mission have a high priority and are crusal for the war. Then ships go all the way. While less urgend missions depending on damage, ships return to shipyard. Or fall back to the support group.

So as commander you can set the urgency of mission and treshold when to go to defensive stance to where return for repairs.

Repair are costly but lot less then build a new ship.

In Topic: Make an engine from scratch's resources?

27 February 2015 - 12:53 AM

As I am beginner to I did think about this. The problem I see to develop a engine as a novice is. Your produce something where the end users are not gamers but fellow gamedevelopers.
So as I am alone to, these users are the artist scripters. Not fellow coders.
Which means already starting with a script engine and a content pipeline is a huge task.
These are heavy features.
Also it make sense to have a game that shows of most game engine features.
And as of being alone, for your show of example game, you need to take these roles to.

But instead of a full game I would go for full featured gameplay demo.
I have seen the C4 game engine architecture. And it seams there goes a lot of modules and systems into a full fledge engine.

So the advice I read make sense to just make games and start simple. A reusable framework will emerge after some refactoring and with each follow up game it grows in features until it could be called a small engine.

As I am alone and tent to be for long time as a lone hobby programmer. I also avoid the heavy need for artist or a team if I would scale up so I prefere to stick with more procedural content generation.

Thinks I would avoid to implement in my first simple game would be.
Content pipeline
Script engine
Resource cache
Resource manager
Advance memory management.
No mplay

So stick first with the very basic parts for very basic game.

In Topic: Entity-Component Confusion

24 February 2015 - 11:53 AM

You can choose the WARP device for C++ AMP and then abuse your CPU as a GPGPU device. Multithreaded and SIMD.

As for why. Well it depends. I aim for PC and windows only and PC hardware can be very unbalanced.

Your target audience could have bit balanced low to high-end game RIG. But a Extreem edition with lowbudged or midrange is possible. Or midrange CPU driving high-end SLI or CF set. Some Retail game do test the system it is installed on.

Also lot of game rigs with a APU and a dedicated G-card. And often the kind that can't cooperate with the APU GPU in SLI or CF. So some do have a dedicated GPU a viable for GPGPU use on the CPU.


Yes loops, got this impression:

The main application loop process each components manager after each other.

within each component manager there is a loop that transforms the component data.


Memory management is important but for data locality in my case using PC as target and when I get something substantial which could or would be never or some few years from now. Like 5. So in essences my target hardware doesn't exist yet.


As PC memory is in surplus now at least for simple beginnings. So for simple start a wasting fixed memory pool will do.

What could matter early on is memory defragmentation.

Also the performance cost of regular allocation and deletions.

In Topic: Entity-Component Confusion

18 February 2015 - 12:23 PM

Oh yes there is a lot of confusion. Me as novice starting hobby C++ game programming. Just figuring out C++ with DirectX 11 . 

Have also read a lot article about ECS. And I notice some conflicts.

If your more into abstract small indie scoped project. And start from scratch the next project. Or begin programming like me. Then one core often fit's the requirement. Even with a large margin. And far into the future.

But as starting programmer it seams the future is important for those who build on there code base. And are looking to get ready for the bigger in scope games. As gamer I have only interest in the bigger Retail game often triple A and very strong IP based games. Most of them with realistic rendering theme. And also simulators. Sandbox games etc. 

My favorite are the Space free roaming sandbox games. Of course I have to start very simple. But I will do grow in scope as learned skill made hopefully possible.


So make sense to Learn programming for CPU that have a dozen core or execute dozen of threads will be very common. Many more cores is the future.

Today the top high end is a 8core 5th gen Ci7 which eats 16 threads. A few years this would be mainstream.


So I read that design your software architecture to handle Multi threading is difficult. Well that right. But then again often it because the solution of choice is not multithreaded friendly.

I read about ECS systems avoiding OOP for many reasons. Multitreaded as after though is bad thing. Why refactoring a already big grown code base is just a lot of rework.


Currently hacking a DX11 toolkit tutorial. My C++ skillz are very poor. Bit it still compiles. Without warnings.  


But a basic start of a ECS could for me would be like this.


Also at the moment got a very vague idea about memory management. For now I avoid that. But it's a important field. So stick for fixed pool. Templates are weird to me, avoid that to.


A entity is key a ID. 

component manager got a entity ID array and component data array.

The data of each component is independent to each other. Which means easy paralyze able.


So in the game loop you process all component managers. Sequential. But within a component manager you can transform the array data by a number of threads. But the very multithreaded related thing about it is. To almost infinite number of cores. And with that much more future proof. |The limit becomes the number of entities.

the transform could be implemented with C++AMP.

Even GPGPU and thus compute shader are possible. On PU with thousand of cores.



And the concept isn't that difficult. Code might still easy to read and to follow.


So what I want to see or find is a basic Pure DOD ECS based example of a ECS


The unrelated tutorial doesn't have input so I stick with a position velocity and AI component. With some render primitives.

Also reading about instancing.

In Topic: Entity component system: data locality vs. templates

04 February 2015 - 12:56 AM

Also reading a lot about ECS. And I find this online book to go very deep into it.


After reading so much different perspective on ECS.

I got this impression.

ECS is not a solution. But more a group of solution it looks more a name for a specific problem domain.

Depending on the kindof game you got a specific problem to solve with ECS so there might be right and wrong soltutions for a specific game but if they are wrong or right for other game might differ.

First step is going the OOP way to avoid inherritance and go for composition or aggegration.
Then up to a OOP And DOD hybrid
To pure DOD.

I also see some resistance to DOD or ECS. It might be because the veteran experienced programmers are indoctrinater or very used to the OOP kind of thinking.

As a novice programmer I don't have this legacy so OOP and DOD I have not much experience with.
But as a novice I want to learn programming the right way and future proof. And DOD seams to have the more and best argument to go for.

OOP would be nice to prototype something very basic and small. As it modeled to real things.
DOD is more taking the perspective of the hardware platform how it execute your code and data.

My back ground is electronica and with limited experience with Z80 and 6800 assembler.
So the hardware perspective isn't that weird for me.

But to get the most out of DOD you need to know the platform you program for. Where OOP ignors that.

Also I read a lot about how bad multitreaded games are. And DOD makes concurrent computing much easier to implement.

As novice I would start small where ECS and DOD and Concurent computing are not that relevant. And are heavy weight solution for something very basic. But I want to scale up pretty fast.
Because as hobby programmer I want to make the games I also want to play. And I am not into retro gaming. And not into the small indie projects. The games I play are those triple A or Retail games.

The kind of game Which is my favorite are the space sim sandbox games.
There are two big independed games made by professional studio.
Elite dangerous and Star Citezen.

This genre has it specific group of ECS requierments.

Like could. Entity be a component to.
Thinking about docking.
Have more then one of the same component. Many guns turrets thrusters.

This genre suits DOD very well. You got many different type of things and of a lot of them you get often many.

Currently just hacking a dx11 tutorial or example. Got position array in it. It a start.
Also get instance rendering up and running.