Quick questions for mechanims & optimizations.

Newbie & Debugging Questions
#1

Hi there. (I apologize in advance for my bad english, i’m french)

I’ve recently decided to switch one of my game to Java.
Long story short, I was using GML (Game Maker Language) and… well, let’s just say that my project got too big over the last year.

First, I’m coding a 2D game (beat’em up), which is mainly based on sprites.
I’ve created my own engine, since I wanted to add “modern fighting-game mechanisms” into it (like parry feature/ defend/ combo cancel ect…)
The fact is, since I’ll be able to have a full OOP approach with Java, I had several ideas for managing my objects, but I just wonder if they’re good or bad.
Well anyway here are my questions :

  1. Since i’ve got LOTS of sprites, I’ve started to create my own editor (to be able to create a sprite from a spritesheet & “attach” all the hitboxes I need). I planned to serialize a set of thoses objects (as a “Character” object) so I’ll just have to load or unload them from that external file whenever I want in the game.
    Though this seems a logical approach for me, is it actually a good thing to do in Java? I wonder, for example, if my serialized objects will be properly loaded when running on a different OS?

  2. Using Java now, I know that I’ll be able to apply colors/effects easily on my sprites (and everything else actually).
    …still, I’m using lots of “photoshopped” effect (for example - alpha 25% on a sprite with a background containing a circle with a blue-orange gradiation, without covering the transparent pixels, blabla…)
    … I wonder if such a thing is actually possible to do in Java itself when running? If that’s the case, is it bad, or REALLY bad for the FPS? (I guess but… it never hurt to ask)
    Using additionnal images would be perfect, but I fear for the memory, since I’ve reached fast huge numbers with GM, even though I cropped everything to the max.

  3. When it comes to sounds & musics, now we can use pretty much everything thanks to the librairies.
    Still, what would be the wiser thing to do for a good overall compatibility? .wav, .ogg or .mp3?

Anyway, as you noticed I’m mainly trying to figure out what would be the best thing to do before coding, since I don’t want to have to rewrite the code X times because I did not consider the best option at the time… (which happened to me a lot in GM ;D)

Oh and last thing, but it’s more an opinion thing than everything else ::slight_smile:
Lots of people STILL won’t even try a game because it’s written in Java (was told that much again 1 hour ago) - Is it running that bad on some OS or is it again an urban legend?

#2

1 - This is perfectly acceptable, however I’d be careful. Using ObjectInputStream (which I assume is what you’re doing) to read files from disk doesn’t create them as you’d expect using your constructor etc. I’ve had issues with this in my projects. Generally what I do is make soem Data objects that simply have all the values I need to construct each object, then I read and write those. From there I manually create the objects in memory. This isn’t strictly necessary, but I just like all object construction to go through predictable paths.

2 - Also totally fine. I’ll bet you could make one 1024x1024 sprite sheet and put almost all of these effects on there as individual images. You can certainly do all the effects manually by editing the Raster directly or using shaders or other options, but some paths are indeed slow, and others are just difficult. I’d simply stick with images for now - a 2D beat 'em up isn’t going to max out memory.

3 - I’d use ogg. I find wavs are far too large, and the mp3 libraries for Java don’t work very well.

Yes, running Java applets is certainly an issue. Chrome shows a warning each and every time, and applets don’t even really work on Mac OS X anymore. If you make a downloadable application and bundle it right, though, nobody will even know you’re using Java.

#3
  1. Serialization is meant to be platform independent. However, there are caveats there. If you release multiple versions of the code base, you will need to ensure that you set up the serialization correctly. This means specifying a SerialID and updating it when required (Serial ID helps the deserializer identify whether the serialized object is of the correct version, so that you don’t try to deserialize an older/newer version of an object that might have changed too much to be compatible.)

This practice works fairly well. There are also options like using JSON which provides a different type of serialization that might work better for you.

  1. Depending on your engine, and how your sprite sheet is set up, you shouldn’t take too big a hit using transparency. If you haven’t looked at them yet, look at LWJGL (Including the libGDX framework and Slick2D), which will help with setting things up to render quickly.

  2. This is less of a compatibility issue and more of a space issue. If it’s a short file, like sound effects the .wav format would work well. If it’s a longer sound file, then .ogg or .mp3 would be better just because .wav files tend to be comparably large.

Java has a bad rap for video games, and the delivery is less than desirable to some people (A lot of people have .jars set up to be extracted, rather than ran, etc.) If you provide them with the .jar and the .bat file (The .bat typically ensures a one-click execution) or even just package it as an executable, using one of the several tools for such so that they don’t even know it’s Java until it’s running (Or, until they get told, some how, that it’s not compatible due to being written in the wrong JRE. xD)…

#4

Serialization is a pain if you finalize some container classes but want to also save other app state that is entangled on the broader constantly changing app classes.

What i ended up doing in this case was ‘cheating’: the serialization protocol works as normal until you get to your container/data class. There you replace writeobject and readobject (and add something to your constructor as you’ll see).

On the write/read object you completely ignore the passed streams and create new ones of a completely different file and read/write the object into that file; this isolates the non-changing part of your program into another serialization graph.
Problem is, that since the first graph can go kaputz independently of the second, you need to try to read the data in the constructor too; no big deal, just call readObject(null) there.

This will make your version upgrades a bit more consistent, so that adding a new field ‘window position’ doesn’t nuke the ‘highscore table’ or something silly like that.

This might make you make a bit more of work than before on the failure case (if the state app graph serialization read fails after new-ing your container class the second graph gets read twice) - if worried about that - you really shouldn’t since it’s the failure case - you can use a static singleton for you class and read in a static block (that only happens once per class).

#5

First, thanks for the answers.

I did plan to create the game with Slick2D, but… I don’t know.
Yes, it’s a good library (of course !), but I feel like that it’d be better for me to learn LWJGL directly, since when having a first look at Slick I noticed that i’ll definitely run into several problems (the Z-axis for example, which is important for my project… and yes, there’s a tutorial about “emulating” a depth in Slick, but from there again I feel like that it’d be better to learn how to use OpenGL directly with LWJGL)
Someone told me that “reinventing the wheel is useless” (true) but I KNOW that i’ll have to create, for example, my own spritesheet & sprite classes due to several reasons, and using a library without using its build-in function sounds a bit… hmm… awkward ?

I intented to use the serialization mainly for storage to be honest, which may not be the “good” way to do it in the end.
I didn’t really want to use lots of XML files, or anything related to a database since it’ll be more like a PC game than anything else, but maybe I should give it a try first.

Darn, I’m trying to plan everything and learn the max before starting to code, and in the end I still haven’t written a single line of code in my project, how ironic ;D

#6

Serialization is mostly used for storage (except for weird ‘deep’ cloning) - that’s what i meant.

By the way a warning: doing what i did above (having two different files containing different serialized object graphs) may cause the same object reference that was originally in both object graphs to be != on the reconstructed application.

I avoid this by not having the same object in both graphs, ie: i only ever get my data objects from my data container which is the secondary graph.

#7

EDIT (last) : I’ll use HashMap ! I won’t delete the post, just in case someone wants to suggest something better…

Hmm… I got new questions (I should try using the irc, but it’s always empty…)

I’ve seen LOTS of differents Collections in Java, and frankly i’m a bit loss about which one to use…?
Well actually I can achieve my goal using differents way, but I wonder which one would be the best considering Java.
Here’s the thing :

First, I intended to make a SpriteSheet Class, mainly to store severals SpriteSheet object (bound to an image file, or more).
A SpriteSheet object will have a Sprite[] collection, Sprite being an object too, which stores severals integers AND additionals HitBox[] collections (Hitbox being also an object).
Yes so basically :
[—] (Object)SpriteSheet <— (Object)Sprite <— (Object)HitBox.
I took this solution because, since I have my own editor, I need to have a dynamic storage for sprites & hitboxes.
But, with this configuration, I’ll have to Serialize the SpriteSheet class, being at the top of everything, and so everything else inside. (If I got the serialization thing right)

From there, I just wonder if it wouldn’t be better to use Tuples? (Since I don’t need any particular methods in Sprite & Hitbox, only getters and setters)
Basically all my objects (SpriteSheet excluded) store single Integer OR ArrayList only, so the *3 objects solution might be a bit overkill for such a thing…?
Or, should I stick to this Object approach because it’s more Java-like?

Sorry if my questions are stupid, but I don’t want to start coding with bad habits…

Edit :
OR, I said tuples, but i’m also considering the List<List<ArrayList>> approch.
BUT, I wonder from there if it wouldn’t be better to use severals HashMap, mainly for a better readability for me, as the programmer…
Darn … :confused:

Edit 2 :
Nevermind, I’ll use HashMap since I don’t need to retrieve the elements in any particular order ;D

#8

[quote]I did plan to create the game with Slick2D, but… I don’t know.
Yes, it’s a good library (of course !), but I feel like that it’d be better for me to learn LWJGL directly, since when having a first look at Slick I noticed that i’ll definitely run into several problems (the Z-axis for example, which is important for my project… and yes, there’s a tutorial about “emulating” a depth in Slick
[/quote]
It’s very unlikely that you’ll want to use the z-buffer for a side-scrolling 2D game – instead it’s generally easier to just sort using draw order.

[quote]Someone told me that “reinventing the wheel is useless” (true) but I KNOW that i’ll have to create, for example, my own spritesheet & sprite classes due to several reasons, and using a library without using its build-in function sounds a bit… hmm… awkward ?
[/quote]
Not really. Slick is very “thin” in the sense that you can use it purely as a utility library. For example, my last project used Slick only for windowing/states and a few other things (Color, text field, etc). I had my own vertex array renderer, texture handling, shader programs (now in Slick branch), Framebuffers, sprite sheets, etc. Using Slick for some parts was easier than doing everything from the ground up.

I don’t know why you need complex serialization. A sprite sheet is just a series of “texture regions” – i.e. rectangles that tell GL what part of a larger texture to render. You should just be saving the data with JSON, XML, Properties, or plain text.

e.g. “sheet1.png” also has “sheet1.def”

# let's say our sprite editor can edit texture regions and hit boxes...
# format: TextureRegion(x, y, w, h), HitBox(TYPE, w, h)

player = 5, 5, 100, 100, CIRCLE, 55, 55
crateBox1 = 100, 100, 20, 20, BOX, 20, 20

I’m also not sure why you need tuples or lists-within-lists. It sounds like you are either over-thinking this, or you aren’t very familiar with Java and object oriented programming.

[quote]I feel like that it’d be better to learn how to use OpenGL directly with LWJGL
[/quote]
You need to choose. Do you want to learn OpenGL, or do you want to make a game? Truth is, you’ll probably spend more time learning and writing OpenGL than you would writing a game with Slick/LibGDX.

If you want to learn how to render sprites with OpenGL, I encourage you to stay away from Slick and do everything from the ground up. This means learning the programmable pipeline (i.e. shaders only) with OpenGL 2.1 or greater.

If you want to make a game, on the other hand, then you are much better off using a high-level library like Slick or LibGDX. LibGDX is really growing and has some great multi-platform support, plus it’s much more flexible than Slick.

But since your “big game” is probably not really that big, I suspect either Slick2D or LibGDX would work fine. Try them both out and decide for yourself which is better suited to your skill/goals/needs.

#9

Well, fact is that the game is already “finished”, but on GameMaker.
I switched to Java mainly because this is what i’m currently studying and because I needed more performances. Let’s just say that at some point, if you want to have Rain/Lots of Characters/AI checking paths/Battle effects/ect ect ect… well, GM is good but still have its limits.

For the SpriteSheet thing, yes maybe i’m just overthinking the thing.
The numbers of hitboxes are random (might be 1, might be 10), and I didn’t want to start calling the thing using “Hitbox1, Hitbox2…”.

For OpenGL, hum…
To be honest I heard about particles effects/dynamic shadow blablabla… Though it’s possible to do in Slick2D, since it is still a library for 2D game, I thought that I might as well jump to something more closer to OpenGL (like LWJGL), I’ll have to learn it someday anyway…
Or maybe it’s me underestimating Slick2D (bad habit I got from GM, thinking that using too much images will slowdown drastically the game)

#10

My last Slick game was able to render tens of thousands of alpha-blended sprites/fonts/etc per frame (pretty much on par with LWJGL/LibGDX sprite renderers in my tests), and it had some fancy shader effects to boot. e.g. This one which you can see implemented in Slick here. So, yes, Slick is very capable.

LibGDX is very close to OpenGL and still includes familiar functions (shaders, glBlendFunc, etc), so if you want OpenGL without the actual hassle of OpenGL, I’d suggest that. It’s also got a lot of tools (texture packer, particle editor, etc) and a booming community.

#11

Huh… yeah, it was really me underestimating Slick2D after all.

Mkay, I think I’ll just go with that and see how it turns out. Thanks for the answers.

#12

Try them both before you decide. Compared to LibGDX, Slick can be limiting at times and does not cater well to “modern” OpenGL (it’s a very old library, after all).