So I set out to make an entity manager that would allow individual entities search for other entities and get limited amounts of entities for processing, like collision detection. Well here is what I came up with:

So an individual entity can ask the manager for only the entities within firing range for example (no need to do operations on things out of range)or you can ask for only the entities within visible range, so you only render entities visible on the screenlot of things you can do...

My only concern is when there are thousands of entities registered with the manager... if asking for limited entity sets every update is actually slower than doing operations and decision logic on all the thousands of entities every update instead. I will only know when I have thousands of entities! haha!

Anyway I thought I would share, and hopefully get some pointers, and maybe inspire someone to climb one step higher in the quest for the perfect entity manager!

You get rid of the relatively expensive square root operation and replace two Math.pow operations for faster multiplication calls. It's a micro optimization but could make a difference when dealing with large numbers of entities. Also is there a reason you flip between lists and arrays? Given that you are already storing the entities as lists, why not have the functions return lists of entities rather than converting them to arrays?

For dealing with thousands of entities in a frequently called game loop, I wouldn't create array copies each and every time. Theoretically its good for protecting the private members (if entities was private here...).Instead, a visitor callback would be an alternative.If you want to return copies, lists are more flexible and abstract than arrays.Then, using enhanced loops creates lots of avoidable iterators in the background.If you absolutely need static access, instead of making each method static, rather deal with a static entity manager in a whole.

Using purely algebraic reductions that you're familiar with is a good habit to get into. Calling Math.pow with an integer (esp small) exponent should be avoided (bad habit)...it's much much slower and less accurate (plus it's more typing). Not that the accuracy is likely to be important.

I think that break would only break out of the if-clause. Thats better IMO:

No, it will break out of the for loop.

Okey... that version was strange anyways. So if that code would break out the for loop, why do it that way, and not just return ?

Not sure for the OP's motivation, but some believe that a function or method should only have a single exit point (let's forget exceptions for the moment). You can Google function single exit point to find links to various discussions. In a method this short I don't think it matters.

I think that break would only break out of the if-clause. Thats better IMO:

No, it will break out of the for loop.

Okey... that version was strange anyways. So if that code would break out the for loop, why do it that way, and not just return ?

Not sure for the OP's motivation, but some believe that a function or method should only have a single exit point (let's forget exceptions for the moment). You can Google function single exit point to find links to various discussions. In a method this short I don't think it matters.

Personally, I don't see anything wrong with having multiple exit points. If your methods are relatively succinct (as they should be!) then I don't see any practical or theoretical negative consequence of having multiple return statements.

I'm a big believer in early returns for edge cases right up at the top so you don't have the rest of the code stuffed inside conditionals ending with a diagonal wall of curly braces. Even scala, which eliminated 'break' and 'continue', has a 'return' statement that can break out early (you don't otherwise need it at the end).

Structured programming is a good guideline for clarity, but it shouldn't get in the way of clarity.

The EntityManager looks pretty neat, although it would be cool if its functionality was broken out into multiple areas. For example, collisions usually should be handled altogether, so once per frame you might calculate all collisions and store the results somehow with very quick access later. Your code means that every single entity is going to need to perform a check that could be very redundant, so your code will be extremely expensive in comparison.

Thanks for all the tips! Yeah, to be honest, I have no idea why I was converting to regular arrays! I even create new ArrayLists in each method! Thanks, Actual, for the tip on the math for the getEntitiesByLocation method, small performance boost, Ill take it! As far as the static access is concerned, It is just easier for the rest for the program to have static access. I could make it into a nested static class, but I couldn't be bothered! haha! I plan to add a few more methods to help with collision detection, but I won't work on that until later.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org