Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Apr 2011
Offline Last Active Jul 01 2016 10:12 PM

Posts I've Made

In Topic: Questions before I start solo on a basic 3D RTS...

06 August 2015 - 02:55 AM

In my opinion by gameplay RTS is the second hardest genre, with MMO being the hardest (harder by several order). So it would probably be better if you forget about the 3D part for a while. If you really want to learn about 3D programming, try make a FPS or TPS instead. RTS has too many stuff to hit your toe with before it can barely become a "game".


Start with a flat, 2D world, model everything as simple circles and rectangles.


Make a tiny circle as your "unit".

Make it move around.

Make a rectangle wall.

Stop the circle from going into that wall.

Make other circles.

Stop circles from going into each other.

Make circles fight.

Make circles die.

Make a map format so it can contain many walls and probably a basic map editor.

Make circle figure out how to get from A to B (pathfinding).

Make circle actually go from A to B (steering).

Make a lot of circle go from A to B together without traffic jam (boids or other techniques).

Make simple AI for circle auto attack, etc.

Make UI.


Steps above had took me 4 week solo for a prototype our studio was investigating, and another 2 week for LAN multiplayer. Definitely doable but some of the subjects are hard, especially for beginners.


And you have a full model for your RTS world, then you can try to render it in 3D. Make your tank go up and down, pretending it was following a ramp while it was actually in a 2D world.

In Topic: C++ Operator Overloading: Bitwise Operators & If-Check

04 August 2015 - 01:13 AM

1. Wouldn't that be quite heavy for performance? Since every single of those instances has it's own list, and is used only shortly anyway..



If you do care about performance, you should revert to normal flags. Your linear search through the deque will already be too slow if you check a billion time through a billion flags.


But I guess this is not the case you're going to use it with. For these non performance critical part you should always choose the easier way. Easier to code, understand, maintain, less chance of misusing. Those 2 microseconds you saved from the user's CPU which you're not paying for is not worth a week of debugging hell.


Your method have severe flaw in it: people don't expect normal operators other than assignments or ++/-- to modify their operand. If you write y = x+5, you'll expect only y will change, not x and certainly not 5.


If you write

UFlag foo = getFlags();
if(foo & 1){

if(foo & 2){

you are going to run into trouble because the content of foo have changed in the first if statement. You'll have to state clearly in your documents that UFlag can't be used like this and hope people (and yourself) will remember.


Although if you have access to c++11 you can avoid some of the performance penalty by using rvalue reference

//this operator is called when the left hand side is an rvalue, which is some temp value that is going to be thrown away.
//google rvalue for more details.
UFlag &&operator&(const UFlag &rhs) && { 
	//we are not going to use "this" later, so we are free to mess with it to improve performance.
	//return as an rvalue
	return move(*this);

In Topic: C++ Operator Overloading: Bitwise Operators & If-Check

02 August 2015 - 09:17 AM

1. Normally the only operator that will return a reference to itself is an assignment operator like = or +=. The rest should take constant parameters (including "this") and return a new object. "c = a + b" does not alter the content of a or b.


UFlag<T> operator |(const UFlag<T> &b) const


should do the trick.


2. Implement explicit operator bool() const;



In Topic: Game entity system: Interactions between Lua and C++

02 August 2015 - 03:09 AM

Are you sure it is going to cost you too much performance? My game calls several hundred Lua scripts and a few quite complex ones per tick, and the Lua VM itself have never cause me any performance trouble.


My metric is if some operations happen less then 1 million times per second, then even considering to optimize or not is often not worth it.

In Topic: Managing engine subsystem interactions

11 June 2015 - 10:18 AM

Seems you do know why then smile.png

I know globals are bad only because people say so, but I didn't fully understand why they are bad, especially the public access part. With your explanation now I know how they are bad for cache coherency.


I still have some questions regarding your engine structure.


Different features might have data the flow through the subsystems in different order, and might go through the same subsystem multiple times. For example, we might need to do several consecutive raycasts that depends on each others result. How do we ensure all the works are done before we finish a single frame? Do we start by raising a update event and loop through all the subsystems until there are no more works queued for this frame?


By batching jobs subsystems will operate on a command pattern. I once used a engine whose rendering system is done like this, but debugging it was quite a headache. With procedural methods, if we received a segfault or other exceptions, all the inputs and callers down until main() is probably still on the stack so it is easier to track where it went wrong. But with a command pattern the information of who gave us this garbage is lost, unless we do some excessive logging. For the footstep example, suppose one of the many sound effects played is wrong, how would you suggest to track down where went wrong?


Thanks a lot!