• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Bradley Benton

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

3 posts in this topic

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.
[list=1]
[*][b]Targeting/Attacking[/b] - 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.
[*][b]2D Camera[/b] - 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.
[*][b]User Interface[/b] - 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?
[*][b]Path Finding[/b] - 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.
[*][b]Selecting[/b] - 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?
[*][b]Picking stuff up[/b] - 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.
[*][b]Animations[/b] - 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?
[/list]
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
0

Share this post


Link to post
Share on other sites
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.

[quote name='Pahaz' timestamp='1342075632' post='4958274']
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
[/quote]
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 "[url="http://en.wikipedia.org/wiki/Space_partitioning"]spatial partitioning[/url]". Specific commonly used solutions include sorting your units into tree structures such as a [url="http://en.wikipedia.org/wiki/Binary_space_partitioning"]BSP tree[/url] or [url="http://en.wikipedia.org/wiki/Octree"]octree[/url]. 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 [url="http://en.wikipedia.org/wiki/Level_of_detail"]level of detail[/url].


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!). [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
0

Share this post


Link to post
Share on other sites
Thanks for coming here from stackoverflow, it's a much better place to ask these kinds of open-ended questions [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

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!

[quote]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.[/quote]
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.

[quote]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.[/quote]
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.

[quote]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?[/quote]
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.

[quote]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.[/quote]
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.

[quote]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?[/quote]
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).

[quote]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.[/quote]
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.

[quote]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?[/quote]
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?

[quote]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.[/quote]
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
1

Share this post


Link to post
Share on other sites
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.

[quote name='jbadams' timestamp='1342078567' post='4958287']
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.
[/quote]

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.

[quote name='Bacterius' timestamp='1342078571' post='4958288']
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.
[/quote]
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!

[quote name='Bacterius' timestamp='1342078571' post='4958288']
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).
[/quote]
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[b] "[/b]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
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0