Jump to content

  • Log In with Google      Sign In   
  • Create Account


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Pahaz   Members   -  Reputation: 112

Like
0Likes
Like

Posted 12 July 2012 - 12:47 AM

Hey all, I'm new to the forums. Posted this over at stack overflow but I'm not really sure if the people there will have the information for this.

So I'm making a 2d Java game with the slick2d and MarteEngine libraries. This is the biggest project since I made checkers for my Java class. I am still pretty new to programming concepts and using optimal ways to get stuff done.

The basic structure of my game is you are a player/hero in a zombie apocalypse and you can gather survivors to help you. There are a many areas that I'm concerned about in my programming. I'm not sure if my methods are a good choice for what I want. This game also does not currently have a grid/tile system.

I've looked at some open source java games and they don't really answer my questions to my methods. So I'm going to make a list here of what I'm uncertain about and I hope you guys can confirm/deny if my methods are appropriate. Sorry if this list gets too long, I'm thinking of the questions as I type.
  • Targeting/Attacking - Survivors will automatically attack zombies once they get within the gun's target range. To do this, I have every survivor get the distance (using distance formula) to every zombie and find the closest one to attack. I check for this constantly so if a faster zombie gets closer, the survivor will change targets. For zombies, they acquire a target and stick to it (for now). The zombies constantly check if they are within the attack range (around 50 pixels) using the distance formula. If they are within range, stop and attack, otherwise, move towards the target.
  • 2D Camera - So a camera in a 2D environment moves the world around instead of you. My current method is have my zombies/survivors/any entities on the map stored in array lists. First the background is adjusted, then all the lists are cycled through and every entity's x and y values are modified. This seems to work alright but some stuff you can really notice sliding around on the background. Not really sure how to avoid this.
  • User Interface - I really have no clue how to work with UI. What I've been doing so far is simply using a background and then generating button objects and manually lining them up. Then, I check if the mouse is over any of the button's areas and if there is a click while moused over the button. I have three different backgrounds and buttons that I switch out with booleans. I'm going to recode that area though, using objects with the background and buttons. Is this the correct way to do UI?
  • Path Finding - I have no path finding system yet. Do I have to stick to a grid system? I really rather my entities move freely along the terrain and not in a weird square to square motion.
  • Selecting - I have it so you can select survivors, upgrade them, and other random stuff. My current method for selecting is constantly check where the mouse X and Y is. I get the distance from the mouse to every survivor and check if it is within 30 pixels. Then, I check if there is a click, if so, select the survivor and unselect all others. I'm still trying to figure out how to unselect all survivors if I click on open space. Is there a better way to go about doing this?
  • Picking stuff up - Same way as said before. I check the distance from the player to every item that can be picked up. If the item is within 30 pixels of the player, it picks it up. It seems to work fine for the moment I suppose. Maybe there really is no other way to do this.
  • Animations - I understand the how to animate with sprites, but I just want to make sure. So if I have 7 different guns to be shot, do I need to manually make functions that have precise timing on each sprite. Say if I have a shotgun, it needs a recoil, pump forward, brief pause, pump back, and ready again. For a pistol I need just the recoil really. So I'd have to make unique functions for each of these animations?
Sorry to type this long list of questions. I try to gather information on this stuff as much as possible and I haven't been able to find many examples on this stuff. I greatly appreciated any answers, even just a yes or no answer. Thanks in advance!

Edited by Pahaz, 12 July 2012 - 12:48 AM.


Sponsor:

#2 jbadams   Senior Staff   -  Reputation: 17321

Like
0Likes
Like

Posted 12 July 2012 - 01:36 AM

Just to get it out of the way first -- there is (usually) no universally "best" method of performing any particular task -- there are methods that are more or less suitable for a given situation. If an approach works well enough for you then there's no point spending time looking for a method that is supposedly better. When evaluating the suitableness of any given approach you should have a specific set of requirements in mind to measure it against.

Targeting/Attacking - Survivors will automatically attack zombies once they get within the gun's target range. To do this, I have every survivor get the distance (using distance formula) to every zombie and find the closest one to attack. I check for this constantly

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.

The usual solution to this is to sub-divide your game so that you can avoid unnecessary checks. Look into "spatial partitioning". Specific commonly used solutions include sorting your units into tree structures such as a BSP tree or octree. At a more basic level, you could consider simply sorting your actors by grid cells, and only doing performing checks between actors who are in the same or neighbouring cells.

You might also consider that it probably isn't necessary to simulate actors the player isn't actually able to see or interact with, or that you might be able to get away with a less detailed simulation for them -- rather than actually calculating and performing specific movements you might simply calculate that a few have died, and that they should have moved gradually closer to the player. This concept is usually referred to as LOD, or level of detail.


Hope that's helpful -- I'm just running out the door at the moment, but I'll try to remember to respond again later (assuming others haven't already answered all your other queries!). Posted Image

#3 Bacterius   Crossbones+   -  Reputation: 8188

Like
1Likes
Like

Posted 12 July 2012 - 01:36 AM

Thanks for coming here from stackoverflow, it's a much better place to ask these kinds of open-ended questions Posted Image

I'm not sure you are ready to attack such a complex project if you have done only checkers before, but even if you don't succeed you will learn much along the way. It's the journey that counts!

Targeting/Attacking - Survivors will automatically attack zombies once they get within the gun's target range. To do this, I have every survivor get the distance (using distance formula) to every zombie and find the closest one to attack. I check for this constantly so if a faster zombie gets closer, the survivor will change targets. For zombies, they acquire a target and stick to it (for now). The zombies constantly check if they are within the attack range (around 50 pixels) using the distance formula. If they are within range, stop and attack, otherwise, move towards the target.

There are a few things that aren't quite correct, but I suppose this would work. 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. This means you want to convert your coordinates to floating-point numbers between, say, 0 and 1, and say that the attack range of a zombie is for instance 0.05 (e.g. 5% of the screen width, for instance). This also helps for logic overall.

2D Camera - So a camera in a 2D environment moves the world around instead of you. My current method is have my zombies/survivors/any entities on the map stored in array lists. First the background is adjusted, then all the lists are cycled through and every entity's x and y values are modified. This seems to work alright but some stuff you can really notice sliding around on the background. Not really sure how to avoid this.

I guess it depends how you look at it. You could imagine the 2D world scrolling under a viewport, or a camera scrolling over the world, both are equivalent (in fact, with no external reference point you can't tell which is which - relativity). I'm not sure this is the right way to approach it. You should keep track of the camera offset, and translate your entities' positions accordingly, but without modifying them permanently. You only keep a "translated copy" for rendering purposes. Unless I misunderstood.

User Interface - I really have no clue how to work with UI. What I've been doing so far is simply using a background and then generating button objects and manually lining them up. Then, I check if the mouse is over any of the button's areas and if there is a click while moused over the button. I have three different backgrounds and buttons that I switch out with booleans. I'm going to recode that area though, using objects with the background and buttons. Is this the correct way to do UI?

GUI's are tricky to do in Java. Ultimately it boils down to this at the lowest level (detecting where the mouse is and providing visual feedback based on user cursory input), but you could certainly use a library to make your life much easier. Perhaps Slick2D has some sort of addon/plugin to make GUI management less of a pain (I don't know, I've never used it), so you wouldn't need to deal with all that stuff and just provide the locations of the different UI objects and attach events to them.

Path Finding - I have no path finding system yet. Do I have to stick to a grid system? I really rather my entities move freely along the terrain and not in a weird square to square motion.

In general, the optimal shortest path to a destination doesn't look natural anyway as it's usually just a bunch of lines pieced together (connecting each node of the grid solution). However if you use a velocity-based approach for moving your entities, it will smooth out the movement of your zombies, making them move in a more realistic curvy way as they slowly change their direction instead of instantly snapping from one heading to another.

Selecting - I have it so you can select survivors, upgrade them, and other random stuff. My current method for selecting is constantly check where the mouse X and Y is. I get the distance from the mouse to every survivor and check if it is within 30 pixels. Then, I check if there is a click, if so, select the survivor and unselect all others. I'm still trying to figure out how to unselect all survivors if I click on open space. Is there a better way to go about doing this?

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).

Picking stuff up - Same way as said before. I check the distance from the player to every item that can be picked up. If the item is within 30 pixels of the player, it picks it up. It seems to work fine for the moment I suppose. Maybe there really is no other way to do this.

Well, yes, it seems logical to do it like this. There are more complicated and efficient ways to do this (which involve subdividing the world into a grid with smaller and smaller cells and quickly finding which object is the closest one to the player faster than just iterating through all of them) but if you only have a handful of objects on the screen at any given time the overhead is usually not worth it. What you are doing is good enough.

Animations - I understand the how to animate with sprites, but I just want to make sure. So if I have 7 different guns to be shot, do I need to manually make functions that have precise timing on each sprite. Say if I have a shotgun, it needs a recoil, pump forward, brief pause, pump back, and ready again. For a pistol I need just the recoil really. So I'd have to make unique functions for each of these animations?

No, you certainly don't need to make multiple functions. You need to manage your animations so that they include:
- the number of frames in the animation
- each frame, as a texture (or whatever image system you have)
- optionally, the speed at which each frame should be displayed
Then you can easily handle different animations with only one function which will take the animation as a parameter and display it properly taking into account the details above. Does that make sense?

So I'm making a 2d Java game with the slick2d and MarteEngine libraries. This is the biggest project since I made checkers for my Java class. I am still pretty new to programming concepts and using optimal ways to get stuff done.

Don't get obsessed over "optimal ways". Most of the time you'll get people saying "quicksort is faster than bubblesort", "octrees are faster than naive intersection", etc.. but the truth is, this is only correct in an asymptotic sense, e.g. it's only true if you have enough objects for the more efficient method to even make a difference (and in fact, the "faster" method may be slower if you have very little objects because of overhead of getting the efficient method into gear). Remember: if it's fast enough, don't optimize it (unless it's an easy and guaranteed optimization). And yes, as jbadams says, the best way is the way that works for you!

Edited by Bacterius, 12 July 2012 - 01:37 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#4 Pahaz   Members   -  Reputation: 112

Like
0Likes
Like

Posted 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!

Edited by Pahaz, 12 July 2012 - 02:05 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS