Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Jun 2012
Offline Last Active May 11 2014 01:36 PM

#5059827 Problem with understanding data access and responding to events in component...

Posted by on 06 May 2013 - 02:54 PM

Components are objects stored within a class as members, components are not inherited and thus it's not a component based system.


Assuming Foo is inheriting SolidObject and GameplayObject you could do something like:


vector<Foo> solidsAndGameplayObjects; //A container of the class inheriting from SolidObject and GameplayObject


for(auto foos1 = solidsAndGameplayObjects.begin(); foos1 != solidsAndGameplayObjects.end(); ++foos1)  //Iterate through all foos
    for(auto foos2 = foos1+1; foos2 != solidsAndGameplayObjects.end(); ++foos2)   //Nestled for-loop to compare all Foo's with eachother exactly one time
        if( collision( foos1, foos2) == true) //Check for collision
            foos1.hitpoint -= foos2.collisionDamage;  //collisionDamage lives in Foo
            foos2.hitpoint -= foos1.collisionDamage;


While I wouldn't recommend this approach since you will find yourself programming HORRIBLY TERRIFYING CODE which is not maintainable whence you create more classes inheriting from SolidObject, as you would need another vector for each subclass of SolidComponent...


This is a simple and direct approach to solve your issue though, but I wouldn't recommend it as it will be difficult to maintain.

#5057609 Having a brain-fart about 2-D arrays

Posted by on 28 April 2013 - 07:04 PM

Well... that's pretty much how it usually works in the memory of a computer . The multiple dimensions just make it easier for you. I realize you can do that, but it's just easier for me to do foo[20,20,20,40], as opposed to foo[320000] .

How about foo[20*20*20*40] ;)?


Also, easy to understand picture:



#5055099 What is an entity?

Posted by on 19 April 2013 - 07:17 PM

As previous posts suggested an entity is pretty much everything. It's for sure to complicated to explain in one post, articles are more suited for the job. I'm not gonna try explain to you what an entity is, but I want to give you an advice - everyone has different opinions about what an entity is, why you need one, how it is implemented etc etc. Everything you read about the matter should be read with a pinch of salt (and in some cases a handful of salt!). You can't read an article and assume what that article explained to you is true in another article, that I learned the hard way.


The most common approaches of Entity Systems have unofficial labels that you will come across whence you lurk more... People talking about, for example, T-Machine ES (Entity System) are generally talking about the same approach of entity system. You might want to memorize the unofficial labels names each type of ES has been given and what's special about that entity system, it will help you from mixing up the different concepts of different entity systems.


Here's some helpful articles that helped me understand ES:


http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ (T-machine entity system)

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ (Objects (entities) as pure aggregation)


While it might be mind-boggling to read get into ES-concept, it is well worth it. I personally feel Entity Systems give the programmer much more freedom and it becomes easier to structure your game. Decoupling is very easy to manage.


I can answer your questions very briefly how I did it:


1. An entitiy is an integer, GUID (Globally Unique IDentifier), that is used to index arrays for it's components (data-collections). In my implementation it is NOT a class.

2. The entity GUID index arrays to access it's components.

3. Systems has access to relevant components. My moveSystem have an update function which can iterate through all positionComponents and velocityComponents and do the logic upon these, altering the component values.

#5046699 List of games based on complexity

Posted by on 25 March 2013 - 04:55 PM

In many  cases you can figure out complexity of a game by yourself. Look at what features a game, and what prerequisites these features have. IE: Pong, two paddles and a ball. All of these move, basic physics is needed. Collision-detection is also needed. There's no way to rate the complexity in any sequence, it'd be arbitrary.

#5040957 Alternative to Node/Grid-based pathfinding for 2D game

Posted by on 08 March 2013 - 03:11 PM

Hi there Little Coding Fox.


If you make your pathfinding Unit 1x1 in width and height, does your pathfinding issue persist? Or does he seem to navigate correct, not getting stuck in stuff?

#5023830 Killing AI

Posted by on 21 January 2013 - 04:27 AM


for (vector<zombiesClass*>::iterator i = zombies.begin() ; 
i != zombies.end() ;)
if( (*i)->Dead )
delete zombies(i);
else ++i;



Perhaps something like this? (argh, cant get rid of italic text..)


Im not to sure this works thou. It deallocated the object and removes it from the vector without invalidizing the vector. Atleast that's what I intent to do with this code.

#4986549 Taking resolution into considreation.. pc 2d games in c++.

Posted by on 03 October 2012 - 03:30 PM

Not sure what those random bugs would be, but just to get things straight you should never use any 'screen resolution'-variable to calculate anything but stuff related to the screen. Random bugs will definitely appear once you use SCREEN_WIDTH to calculate the speed of your spaceship... When I was new to game development I did some nasty stuff with physics calculation depending on screen-variables, resulting in different situations depending on the players resolution.