Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Nov 2005
Offline Last Active Jul 15 2013 08:20 AM

Topics I've Started

Question about the Entity Component System architecture

15 May 2013 - 07:03 PM

Hey everyone,

I've been reading up on the Entity Component System paradigm ( http://www.gamedev.net/topic/643095-good-articles-on-entity-components-systems/ has been very helpful) and I think I understand everything I need to implement it except for one thing:

Where do the components "live"? Getting into implementation specifics, I'll be writing this in C++. So, for the sake of example, let's say I have a position component, a velocity/movement component, and a motion system which acts on both components.

Would it make sense for each entity to have a data member container consisting of pointers to components? If so, how would the motion system keep track of which entities have position and velocity/movement components? Or maybe a better way of phrasing the question is: How does the motion system keep track of which components it needs to iterate over when it runs?

When I look at diagrams and read articles about ECS, everything seems to make sense to me. But when I sit down with a pen and paper and try to map out the class relationships, my level of understanding starts to break down.


Edit: I've thought about this a little bit more, and maybe the a good approach would be to have each system contain a container of pointers to entities that contain a matching set of components. This would mean that every time an entity adds or removes a component, it would have to be examined by each system to determine if it contains the right components to be used by that system. However, this also means that each system doesn't have to go through and check EVERY entity to see if it has the right components in every iteration of the game loop. Thoughts? Am I heading down the wrong path?

SDL - Error in Visual Studio 2010 Express when Debugging

01 March 2013 - 07:42 PM

Hey everyone,


I'm going through lazy foo's SDL tutorials using Visual C++  2010 Express and have noticed that everything in the first basic tutorial works fine when I run the application directly from the .exe, but when I try to click "play" to start debugging, I get the following error:


Unhandled exception at 0x681247d8 in test_game.exe: 0xC0000005: Access violation reading location 0xccccccf8.


I'm guessing this is due to one of two things:

1) The debug environment isn't finding the necessary DLLs

2) The debug environment isn't finding the necessary images to load, so it's trying to dereference a null pointer.


Unfortunately, I know next to nothing about Visual Studio or how it sets up its debug environment and I haven't been able to google a solution to this.  Any thoughts?


Thanks in advance, please let me know if I should provide more detail.

Shmup design question: int vs float/double

19 June 2010 - 04:59 AM

Hey all,

I've been working on writing a 2D shoot 'em up in C++/SDL. Pretty much everything coordinate-related is type "int", which makes things very easy when conceptualizing the conversion from an in-game coordinate to a pixel on the screen. However, the limitations of int are quickly becoming apparent.

- All game objects contain xVelocity and yVelocity members that correspond to "number of pixels moved per frame". This in itself severely limits the number of options I have for bullet speed.
- My function that fires bullets "at" a gameObject ends up being horribly inaccurate as I'm essentially doing trig on ints.
- When doing collision detection, I end up converting the relevant variables to double anyways.

When looking at issues like this, it seems obvious that ints aren't the way to go. However, I have two primary concerns about switching to float/double:

1) Performance. The long term goal for this engine is bullet hell, and if I'm moving, updating, and detecting collisions for tons of floats instead of ints, am I going to have performance issues?

2) Displaying everything on the screen. I have absolutely NO idea how something like this would work. Do I just round all the coordinate values that I'm going to display on the screen? This seems a little inaccurate when precision movement/dodging will play an integral role in the game.

Am I worrying about nothing? Computers are fast, and pixels are really small. This is my first real-time game, so I'm not sure how valid these concerns are.

So... to int or not to int? Thanks in advance!

Edit: Typo

Debugging SDL

11 June 2010 - 02:50 PM

I'm still trying to find my way around Visual C++ 2008's debugger. One thing I really don't understand is why nothing seems to work when I debug instead of build and run the binary on its own. Whenever I debug the window appears but nothing is drawn, the game doesn't start, I can't move around the screen, etc.

How do I run programs using SDL through the debugger?

Thanks in advance!

Looking for informational interviews

07 June 2010 - 02:31 PM

Hey everyone,

I've been considering pursuing a job as a game programmer, with longer term hopes of eventually moving into game design. The resources on this site have been tremendous (Tom Sloper - I can't thank you enough for the FAQ).

That being said, I'd really like to get on the phone with a couple people from various segments in the industry (The Blizzards and EAs as well as the 2DBoys and the one man indie shops) for 15-30 minutes. My questions would center around people's backgrounds and their experiences. Ideally, I'd like to talk to programmers and game designers, but I'd also be interested in talking to project managers and producers. I've been having a lot of fun working on my own project in my free time, but, in the interest of figuring out if this is something I want to take to the next level, I'd like to chat with various professionals to get a feel for what it's like to work in the industry.

If anyone in these forums would be willing to chat for a few (or knows someone in one of these positions that would be interested), I would be VERY appreciative.

Thanks in advance!