Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Pahaz

Member Since 30 Apr 2012
Offline Last Active May 19 2014 01:55 AM

Posts I've Made

In Topic: Are my programming methods for java games sufficient (Using slick2d)

12 July 2012 - 02:03 AM

Thanks to both of your answers, I will have a look into spatial partitioning tomorrow when I am more awake. This is a game that I'm basically learning java through trial and error with.

It's not so much that I am looking for the 'best' ways, I just want to know if my 'ways' are acceptable. I believe the checking zombies to survivors and vice versa will become a problem in the future, which is why I'll look into the partitioning. I believe a grid will solve the picking items up and I'll try to get a grid in the game.

This should work just fine for a small number of actors (survivors and zombies), but will not scale well; as you add more actors the number of checks you have to do increases drastically, and obviously this will start to have an impact on performance at some point.


I guess the number of entities would be relatively small. I would say no more than... 150 entities would be on the map at the same time? Kinda hard to say until I get further along with it. And performing less detailed simulations might work, but the map we're using now is 5k x 5k pixels, so it's not that large of an area.

Firstly, don't set hard pixel values like a 50px range - you want your game to be able to be played on any resolution whatsoever, and for this to happen you need the game logic to be r esolution-independent.

I understand that scaling is an issue but for my first attempt at a small game, it will be forced to 800X600 resolution. I will take your advice in the future though, good idea!

You should probably check if there is a click before doing any position analysis, since nothing will happen anyway if the mouse isn't clicked (more efficient). This can't really be answered because it's unclear how you manage your survivor entities, but you could just make it that if no survivor is near the mouse when it is clicked (= open space), then you loop over all survivors and "unselect" them. But it depends on how "selection" is defined inside your game, it could be a flag in each survivor entity or it could be a "selection list" attached to the player (if that makes sense).

Yea the selection is a boolean in the survivor class. I've tried doing a "If there is a click, check the mouse X and Y and see if a survivor is near" method but it absolutely would not work. I'll have to try and fiddle with this again.

As for the animations, good advice on that. So I'd need spritesheets with however many frames I'd need. So for a pistol it's a flash+recoil, really simple, probably only needs two frames. As for a shotgun,shoot+recoil, brief pause, pump out, pause , pump in. So maybe (counting frames per action) 2 + 1 + 1 + 1 + 1 at a slower rate. Makes sense.

I've heard plenty of "Premature optimization is the root of all evil" quotes. I'm not necessarily optimizing yet, just trying to avoid what I know will become an issue. Thanks a ton for the advice so far!

PARTNERS