Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Newbie & Debugging Questions / Re: Libgdx lagging on: 2014-04-27 09:41:26
Wait a minute


If enemies is really an ArrayList you wouldn't be able to index it like this. You'd need to use


Are you converting enemies to a bare array at some point? If you were doing that in each loop iteration I could see that being very slow.
2  Game Development / Game Play & Game Design / Re: Game Pausing. Opinions? on: 2014-02-08 06:56:43
IMO the value and fun of a PvZ style game is having to formulate and potentially modify a strategy under time pressure. Having an unrestricted pause feature has the potential to kill much of the challenge of the game.

I think a good solution would be to allow the player to pause, but completely obscure all gameplay relevant objects (or just the entire screen). This allows the player the convenience of pausing without being exploitable.
3  Game Development / Newbie & Debugging Questions / Re: Showing same number of tiles regardless of resolution on: 2014-02-03 14:23:19
A somewhat hacky solution just occurred to me. Instead of leaving the black bars in place, if necessary I'll simply make the window shorter at runtime (i.e. somewhere in the resize method). I don't intend to allow the user to arbitrarily re-size the window anyway, resolution will only be picked from a launcher or an options menu. The problem with this is that I may end up lying to the user about the size of the window they'll be getting. I could provide a footnote explaining this in the launcher/options menu.

Of course, this method won't help with fullscreen, but the black bars are barely visible there anyway.

What do you think? Would you be miffed if a game misrepresented it's window dimensions to you? I honestly think most people wouldn't notice as the black bars are usually no more than a dozen pixels high anyway.
4  Game Development / Newbie & Debugging Questions / Re: Showing same number of tiles regardless of resolution on: 2014-02-01 16:13:25
I suppose while I'm here I'll ask if anyone has an opinion on the existence of the small black bars in my game (see here). Does it look cheap, shoddy or incompetent? In fullscreen the bars are much less noticeable, assuming you have a black bordered monitor.
5  Game Development / Newbie & Debugging Questions / Re: Showing same number of tiles regardless of resolution on: 2014-02-01 15:04:46
Create a camera with a fixed viewport and then use the stage to set the camera.

OrthographicCamera cam = new OrthographicCamera(640, 480);

This will force the stage to never resize if resolution changes however no idea how this will affect the rest of your code.

Me personally I use like 2-3 cameras lol, I normally have one for UI, one for Box2D and then if using Scene2D for menus one for that as well.

Okay, I just gave that a try, using native stage dimensions derived from my actual texture sizes, and glViewport set to the appropriate on-screen size. Here's the result:

Note that there should be black lines on every visible tile boundary. In the original camera dimensions they're 1px wide, but since the whole map is being down-sampled(?) to a smaller size here, it seems that many of the 1px lines are not being sampled at all. Which isn't surprising, I guess. Also, when I pan the camera, the grid lines flicker on and off like crazy as they move.

Also when panning, I can see slight shimmering artifacts at the tile edges.

UPDATE: I just tried setting the texture minification filter to both Nearest and Linear and the problems remain. Seems the problem is not with texture filtering, but from projecting a larger area down to a smaller area.
6  Game Development / Newbie & Debugging Questions / Showing same number of tiles regardless of resolution on: 2014-02-01 12:11:53
Hi, I've been banging my head against this for a while now and would appreciate any insight anyone has to offer. I think it will be simplest to describe my requirements and my problem in list form:

  • I'm developing a game for desktop.
  • I'm using libGDX's Scene2d.
  • I'm intending to limit the aspect ratio of my game area to 16:9. If someone has a 4:3 or 16:10 screen I'll solve that by introducing letterboxing, but that is not what I'm concerned with right now and not the reason I'm writing this post.
  • My game is 2d, with a top down viewpoint, and tile based.
  • I'm not going for a pixel art look. My original textures will be larger than their ultimate display size, at least at 1920x1080 (unless someone can explain why this is a bad idea).
  • My main requirement/problem: I want to display the same number of tiles on screen, in both x and y, regardless of resolution.
  • The map will only scroll in terms of discrete tile positions. The map will only ever show partial tiles while in the middle of scrolling. When the map is stationary only whole tiles will be visible.
  • In the y direction I want the tiles to cover the entire screen height. In the X direction the tiles will extend from the left of the screen rightwards as far as they need to.
  • The number of tiles in both x and y is odd, so that there is a well defined center tile at all times.

I determine the onscreen tile size by dividing the screen height by the number of vertical tiles. The problem is that the number of vertical tiles doesn't always divide evenly into the screen height. This results in non integer tile size and consequently non-integer tile positions, resulting in "shimmering" artifacts as the camera pans. I'm also drawing vertical and horizontal grid lines at tile boundaries and the shimmering problems are especially noticeable with these.

The solution I came up with is to calculate the tile size and overall map size as follows:
  • Divide the screen height by my vertical tile count.
  • Floor this number to the nearest integer. This is my tile size.
  • Calculate the size of the viewable map area by multiplying the tile size by me horizontal and vertical tile counts.

This solution works as it gives me integer tile size and integer viewable map area. The problem is that at most vertical resolutions the viewable map area ends up being shorter than the screen height. Below is an example of what this looks like (I've centered the viewable area so the black space at top and bottom is the same. Also, the right hand side will be a UI area):

This isn't the most awful thing in the world but it does look kind of ugly and and it's something I'd like to avoid if at all possible.

I've tried the following to remedy this:
  • Render the tiles at their original dimensions to a Frame Buffer. Then set glViewport to the dimensions I want (maintaining the correct aspect ratio) and render.
  • As above, except simply set the Scene2d Stage size to accommodate the tiles at original dimensions, then set glViewport to appropriate screen size.

Both these methods result in the same kind of visual artifacts you get when using non integer tile sizes and positions. In fact it often looks worse as the grid lines I'm drawing (see above image) often get completely filtered out when stationary and only appear/disappear in a shifting pattern when panning the camera.

So, can anyone suggest any solutions to this? Would a custom shader be of any use here (I should point out that I only have a basic idea of what a shader is, let alone how to write one)?

Thanks in advance.
7  Game Development / Performance Tuning / Re: Libgdx performance testing. on: 2014-01-18 11:31:11
Unless I'm misunderstanding you the info you want is provided by This gives you the time (in seconds) that the previous frame took to render. To get a useful value you'll need to turn off vsync.
8  Game Development / Performance Tuning / Re: Libgdx performance testing. on: 2014-01-18 10:13:24
I'm not sure if this completely solves your needs but LibGDX has a rudimentary built in FPS counter:
9  Game Development / Game Play & Game Design / Re: Damage Types in RPGs and Roguelikes on: 2013-12-18 11:09:11
I don't know what DOT stands for, this makes understanding your message a bit difficult. Also I'm not sure what you mean by "mechanical effect" and what other effects there could be but mechanical ones. Angnabd has gravity hounds which can displace a PC, that clearly is a jmechanical effect, but likely not the one you meant Wink

Sorry, as Jimmt said DOT == Damage Over Time. Usually something like poison.

And the example you gave is actually exactly what I meant by "mechanical effect"  Smiley. I could have said "game mechanic". I was mainly trying to draw a distinction between "game mechanics", which are the rules that govern the events that can happen in a game, and what you might call the "theme" of a game mechanic (there might be a better word than "theme"), which is the visual/auditory/textual representation of the mechanic given to the player.

In the example you gave of gravity hounds, the mechanical effect would be "displace the PC", while the representation given to the player is the textual description and visual indication (i.e. the player's avatar is now somewhere else) of what has just happened.

So to answer your main question, I think you should add as many damage types as you can make fun or interesting. I don't think you should add damage types just because they exist in other games or in the real world unless you can find ways to give them interesting, useful and varied mechanical effects. I know that sounds a bit vague but I think games in general would be better off focusing far less on "simulationist" aspects (even if the thing you're "simulating" is a fantasy world) and instead prioritising solid gameplay systems.
10  Game Development / Game Play & Game Design / Re: Damage Types in RPGs and Roguelikes on: 2013-12-17 04:36:26
This is of course only my 2 cents, but I think you should start by deciding what mechanical effect you want to achieve by having varying damage types in the game. Do I want this damage type to slow or immobilise or incapacitate the enemy, or apply a DOT, or teleport the enemy away, etc. Once you've decided on the mechanics you want to include you can decide on an appropriate theming for them (e.g. DOT's are usually represented as "Poison" or "Fire" (although fire usually does some direct damage as well)). Having lots of different damage types that appear superficially different but are not mechanically distinct isn't particularly interesting IMO.
11  Game Development / Performance Tuning / Re: Software "history" storing methods. on: 2013-12-14 07:44:13
I came across this article recently on the Command Pattern. I haven't used it yet, but one of the things the pattern apparently enables is a method of undo/redo. The site that article comes from, Game Programming Patterns, has a number of great articles on general game programming and architecture.
12  Game Development / Game Mechanics / Re: Fast way to save game state on every turn? on: 2013-11-04 14:34:54
Thanks for your response Nate, I'll look into all of this further.
13  Game Development / Game Mechanics / Re: Fast way to save game state on every turn? on: 2013-11-04 08:15:29
I would save the entire game state with Kryo between turns. This is very likely fast enough for a turn-based game on mobile. On desktop it is fast enough until you are saving 7-8MB of data. Kryo is binary and the data is small, so this is quite a bit of data. Saving as JSON with libgdx might be ok, but being a text format it has never been intended for high performance. You could look at jackson for JSON if it is too slow and you want human readable.

Kyro does object serialization, correct? Wouldn't this mean rhat the format of the save file would be directly dependent on the layout of my objects? So, if I update the layout of my objects then existing save files would become invalid? This would be true of any object serialization scheme. I remember reading about such a concern somewhere, might've been here.

Still, if Kyro is fast enough that I can just brute force serialize everything on every turn (actually I'd still make sure I only serialize things that have changed) it might be worth the hassle of managing outdated save files (which may not even be a problem for my game anyway).

14  Game Development / Game Mechanics / Fast way to save game state on every turn? on: 2013-11-03 09:10:00
Hi everyone. First post here, hope this is the correct forum.

I'm planning on developing a turn based, top down, grid based, roguelike-ish game. For the moment I'm focusing on desktop only.

One feature I'd like to implement is saving the game state on every turn (or every significant user action). "Game state" in this case being the state of the player and all enemies in the level. The level structure itself will be static and I'll just serialize it on generation to json using the included functionality in LibGDX. I'll also probably limit the turn rate to no more than 2 or 3 per second.

The idea is for saving to work like it does in Dark Souls. DS provides no explicit "Save" option, instead it is constantly saving every little action you take in the background.

At a very high level it seems to me that the best way to proceed is to make sure that I only persist those things that have changed each turn, and in general optimise for write speed of my save file over read speed. Sqlite would seem to be the natural way to do that sort of thing but I've no idea what the overhead of sqlite is relative to other methods.

At present I still have only a vague idea of how much information I'll need to store, i.e. what attributes entities will have and how many entities on average will be in a level. Admittedly, this may be something where I'll just have to experiment and profile to find something that's fast enough but I'm interested to hear if anyone has any ideas or has implemented something similar.

Pages: [1]
EgonOlsen (79 views)
2018-06-10 19:43:48

EgonOlsen (59 views)
2018-06-10 19:43:44

EgonOlsen (78 views)
2018-06-10 19:43:20

DesertCoockie (261 views)
2018-05-13 18:23:11

nelsongames (159 views)
2018-04-24 18:15:36

nelsongames (158 views)
2018-04-24 18:14:32

ivj94 (901 views)
2018-03-24 14:47:39

ivj94 (162 views)
2018-03-24 14:46:31

ivj94 (813 views)
2018-03-24 14:43:53

Solater (177 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!