The Escapades of Wiggles

Since I’ve been helped in the past by may users on this site, I felt that I should show my work in progress. Using Slick2D, I plan to make a very lengthy platformer (so long as I don’t quit in the middle, right?) with a couple of friends. The people I have in mind to help me, however, are kind of busy at the moment, but I digress.

Everything you see here in this game is my creation, excluding a few resources:

The characters within the speech bubbles come from my favorite indie game of all time, CaveStory, and the background music , called Swing Bit Brawl, comes from Waterflame of Newgrounds.com. I don’t actually plan to use these resources in the final product, but I felt like I needed something to fill it out, you see.

Tell me what you think. Does it run smoothly on your computer? Does it run at all??? 50fps is the expected frame-rate. Any amount of constructive criticism is welcome, but be cool, guys. This is just a work in progress with only 3 rooms and demonstrates a small portion of the game logic. I’ve also included the source in case someone is zealous enough to look through it.

Beta 1: http://www.mediafire.com/?4sy6zcu94vp349i
Beta 2: http://www.mediafire.com/?1f96dskhyijlnr5
Beta 3: http://www.mediafire.com/?tpp2upe3chtaeu3

From Beta 2 and onward, I will be including a log.txt file that SHOULD log every thing that is printed out. I’ve included this because I’ve run into a couple of people who have had trouble getting my game to run, and I would like to eliminate some compatibility issues that I don’t encounter working on my little ol’ lappy!

It looks really good. It ran fine. Controls were good. (really need a running graphic) My only complaint would be the file size. 20+ meg is a little large for a demo. At least for my slow ass connection. Because most of your fluff was from natives and libraries, the only way I can think of reducing it would be have different links for different OS.

Please make more. I love platform games a lot and this looks really good.

Yeah, I know what you mean. There’s actually a lot of unused resources that I left behind. Thanks for checking it out, though!

Ah, it seems to work alright. However, I get weird sounds. A thumping the whole time, that would sometimes increase in pace and loudness. Heh.

Runs fine here :slight_smile: I liked it a lot! Keep it up, please! :wink:

I THINK you’re referring to the sound that plays when Wiggles lands or hits the ceiling. Is it a little much?

I agree, the filesize is a big large. The game overall looks nice, good collision work. The player should be able to float up in the water, though.

Dunno if people are still checking this out, but I managed to crunch down the file size significantly by removing unused .oggs, and some library files that served no purpose to the already compiled program. It’s about 8megs now. My B…

Runs fine here as well and looks good.

I was.
I would make all member variables private instead of package private. Programmers need to be put on chain, otherwise they will misuse every chance. Choosing the right/most narrow scope is also an important implicit source documentation.

A hierarchy chain of Movable, Collidable etc. can easily become very inflexible. So I would rather use object composition/delegates/interfaces.

Checking parameters is good:


if(visuals == null)
   throw new NullPointerException();

Even better would be a meaningful error message.

else if(item instanceof Sprite)

instanceof-checks can be a hint of incomplete design.

Heck, I’m surprised, really! Didn’t expect anyone to actually go through it!

[quote]A hierarchy chain of Movable, Collidable etc. can easily become very inflexible. So I would rather use object composition/delegates/interfaces.
[/quote]
I had actually never heard of composition using delegates, so I thank you for that. Sounds like a good workaround for the lack of multiple inheritance outside of interfaces in Java.

[quote]Even better would be a meaningful error message.
[/quote]
I get that the NullPointerExceptions need to be specific, so I won’t ponder that any further.

[quote]instanceof-checks can be a hint of incomplete design.
[/quote]
I’m curious as to how instanceof is a problem, though… I recurse through an object tree to obtain certain visual effects in my game, and I can’t imagine another way of doing so without checking which type of object each is (there’s really only 3). I’m not questioning you, but I’m concerned as to what I should be doing. The system uses objects nested within object containers in my game, so what would be an appropriate way to iterate through this object tree?

It could be? But it played even when I was standing still or running across a piece of flat ground. It’s like the sound file repeated when it wasn’t supposed to.

I get that the NullPointerExceptions need to be specific, so I won’t ponder that any further.
[/quote]
To be really nit-picky, actually something like an IllegalArguemntException would be more precise, cause you are preventing null pointer access.

I’m curious as to how instanceof is a problem, though… I recurse through an object tree to obtain certain visual effects in my game, and I can’t imagine another way of doing so without checking which type of object each is (there’s really only 3). I’m not questioning you, but I’m concerned as to what I should be doing. The system uses objects nested within object containers in my game, so what would be an appropriate way to iterate through this object tree?
[/quote]
You could let polymorphism find the way to the right code chunk.
You already have a Displayable interface, so you could add a render method and just call that from the Game class.
Thus, the game class does not need to know how to treat each type and you get rid of some dependencies. And when adding a new type, the game class stays untouched.

I am not saying to never use instanceof - I do it by myself sometimes. As always, it depends. But for a case like this, I would - and did - extract the render code. It might even make sense to introduce dedicated renderer classes.

Technically it’s IllegalArgumentException, but it’s not uncommon for java APIs to check for null args and immediately throw NPE. But since you’re throwing explicitly, it wouldn’t hurt to say “visuals must not be null” in the message.

Mind you, don’t bother doing this sort of thing in a private method – use assert for conditions that are supposed to be impossible.

[quote]You already have a Displayable interface, so you could add a render method and just call that from the Game class.
[/quote]
I’m not a huge fan of creating render methods that automatically render images to a particular graphics object. I prefer to have the graphics object decide what to render. The system I developed allows me to not have to think about rendering/painting images to a canvas altogether. I could write something like this…

// Creates image
Image uberImage = null;
try
{
uberImage = new Image(“res/uber.png”);
}
catch(SlickException e)
{
e.printStackTrace(); // Vague error message… Have I learned nothing???
}

// Adds 2 sprites to a container
Sprite sprite = new Sprite(uberImage);
Sprite sprite2 = new Sprite(uberImage);
sprite2.setLocation(200, 0);
DisplayContainer container = new DisplayContainer(2);
container.add(sprite);
container.add(sprite2);

// Moves the container
container.setLocation(1337, 9001);

// Adds the container to the root container
add(container);

This way, I can easily decide what objects overlap what, and also, move groups of objects with ease. Instead of considering both sprites when wanting to move them both, I can simply add them to a container and move the container. By doing this, we’re treating both sprites as one image. This is vaguely similar to developing software in Swing in which you create objects, add them to a container, then add the container. Rendering is also not a concern as it is automatically done for me. It does feel a little silly, though, to wrap an image within my own class, Sprite. The Image class is already a wrapper for an lwjgl texture, and I’m just wrapping it again in my own sort of Image class. This HAS saved me a lot of time, however, as I don’t have to write long lines of code in any sort of render method.

All very well, but this does not stand in opposition to my remark. I was only referring to the implementation.
Think of a render method doing all the work for the complete Swing widget palette. It would be an unmaintainable mess. Swing has the *UI classes for actual rendering while still being a hierachical widget library.
If there is only one god like render method, it means by modifying it, you would have to test each and every existing functionality again and again, instead of just plugging in new widgets or game objects.
Classes should have a very limited set of responsibility and dependencies.

Lucky for me, as I have already planned out the recursive method of displaying images. The complexities of the of the engine are of course, kept secret under the hood. I come from a flash background where displaying objects using a display list hierarchy is the norm. I kind of see rendering images in a set order to be kind of linear. Seeing as we’re dealing with a purebred Object oriented programming language, I see no reason against using a hierarchy to express what I want to be seen. I have already planned out how the so called God render method is supposed to display objects, and I agree that it would be cumbersome to have to make a big change. Luckily, that won’t be necessary as it is rather lightweight not even supporting rotation (I don’t plan on using this, anyway).

You should know that changing my engine to allow simply calling a render method to display objects would be a nightmare at this point. The core of my game is fundamentally hierarchical, and I’m loving every second of it! ;D

I think I get what you’re saying now a little better, but the god render method only knows how to talk to 3 basic type of Displayables. Sprite, DisplayAnimation, and DisplayContainer. Any extension to these 3 basic classes could decide how to render themselves in any way they feel appropriate so long as they abide by the fundamentals of the system. For instance, if I wanted an option to add a blur filter a sprite, I suppose it would make sense to add than implementation to the Sprite itself rather than the render method like you said.

Very nice work :slight_smile: I like it!
I’ll be sifting through the code a bit too. Mainly because I have a fetish for collision-systems right now, and I want to see what you’re doing.

About the landing sound: sounds like he’s a rock landing on concrete. It doesn’t have to be that loud or sharp.

The code is a little outdated, and I’ve never been 100% satisfied with the collision code, but then again I’ve always been critical of my code. I’ll be updating the download link every once in a while, though. Can’t guarantee that I’ll always be including the source. Good luck, though, trying to interpret the heap! I’ll be sure to update the sound effects… eventually…

Anyway, glad to see that you like my collision code! I’ll tell you one thing, though… Slopes have never been fun to write! The slope doesn’t exactly calculate the intersection with the player’s trajectory and the slope itself, but it can at least determine when it has gone through it. I’m sure a Physicist would have a field day explaining the inaccuracy of my game’s logic. It checks to see when the player collides with the slope, and also checks instances when the player skims the top and bottom of it and determines if the player should hook on to it.

Like

Player
0 ------> Player skims the top of the slope and should hook on to it.


        \       < ---Slope
          __________________

Sorry… I just like explaining my code.