Code Review - of project so far

Newbie & Debugging Questions
#1

I’ve just gotten “enough” ground done on a basic platformer done to have enough code so that people have enough code to tell where I’m going and any pitfalls I might run into. I basically have a very simple testcell prepared and functioning with most of the “physics” effects along with basic rendering tasks. It’s also worth noting that there are a lot of things to do(sprite animation, more complex poly features, and AI), I just want to get other’s views the project so far.

This project currently features.

Collision - Of an individual point to a polygon

Collision response - a hard coded method for figuring out what an object should do upon a collision. These responses can be tweeked for a very wide range of effects.

Physics - a core physics engine that allows for simple gravity, impulse, and acceleration forces. weight is not currently implemented or needed. It’s also worth noting that I’m doing very little cheating with the physics.

Imaging - a really broken image loading method that I will be working on when I work on actual sprite animation

Imaging Scrolling - the ability to implement scrolling, actually you’re expected to implement it.

Imaging Backround - A rendering class that allows for rendering of a backround/multiable. though very limited.

Pause - properly pauses the game and displays a different panel while paused.

The project according to eclipse should be compatible with java 1.4 though it’s compiled in 1.6(I think). Just recompile the PlatApplet if you need to.

I also provided everything as/in an independent folder(source, compiled, resources) and you should be able to run it straight from the HTML file.

http://lithos.110mb.com/BasicPlatformerCodeReview.zip

EDIT:

I’m not looking for style, I’m just looking for people to point out the “broad” implications, and/or mistakes for what I’m working on.

#2

If the code works, you good. I don’t think anyone is going to review it for code style.
As a suggestion, avoid duplicate code, put code that is used in multiple places were all the classes can get at it. If you want to be able to swap up functionality in code, use an interface, with your concrete implementations can be exchange.

#3

I think in these situations, it’s sometimes best to learn what’s wrong on your own. Sure, someone could tell you’re doing it wrong or right, but why is it wrong? and do you really trust them? or perhaps there are conflicting opinions.

Because you’re hopefully doing this for fun and as a hobby, you can take the time to explore your own style and fall down a few times. It might take longer, but in the end you’ll probably appreciate it more and you are likely to be a better programmer.

My advice is to keep making the game and if things start to nag you or it becomes difficult, figure out ways to solve it that are better. You’ll be better informed on what works well with how you program, and what can cause problems.

#4

If I didn’t want criticism I wouldn’t have asked for it. It’s actually the best way that I learn. I understand learning by yourself to learn it better but that only gets you so far.

Right now I just have a little bit of advice to be a bit more OO.

Outside of that I have almost 50 views and 2 responses, now a cocky game newbie like myself can only assume that my best “not done” “hobby work” isn’t bad enough to comment on and likewise isn’t good enough to comment on. Which means I’m sitting pretty comfortably, even if it’s on a live bombshell.

#5

I didn’t look at the actual code, but these are the things I feel should be worked on, judging from running the game:

  1. FPS should always be on top. I doubt 0 frames were skipped as well, as that would indicate that the FPS was some sort of constant value the entire time, which it wasn’t.

  2. most of the images didn’t load

  3. jumping feels very sluggish

  4. It’s hard to turn your guy

  5. The colors and textures really need more work

  6. flicker is visible when repainting the climbable obstacles

  7. what are you playing as? It looks like some sort of a plane, which doesn’t make sense if it’s a platformer.

#6

Cool atleast I know most of the bugs are consistant.

Though I have no idea why your skipped frames are 0, on most computers you should have at least 10,000 or so because it’s just the number of “update” frames the computer skips because no time has passed by. For this I would just briefly ask what OS you’re on because threading isn’t the same between them and I don’t have experience with programming for an OS outside of WinXP.

The last disturbing thing would be controls being sluggish. If you’re in the air they’re supposed to be on the ground they should be instant. Granted even if they’re supposed to be like that right now it’s something I still need to look into because even a playtest as small as this one is still that.

As for losing vertical sync when I’m climbing up ladders that would be from the updates being faster than the repaints. I havent’ implemented some stuff that I found to fix it yet.

I’d still like to see some other people’s views on some of the source code.

In particular how I’m handling collision since it seems wrong even if it does work right: Right now when the game senses a collision it creates a new object to hold all the information about that collision, that object is then passed around to whatever may be interested, then the objects that collided with the “whatever” takes the information on the CollisionResponse and uses it however it wants. Right now how the logic for handling it just doesn’t seem very OO.

If collision were purely OO(from my knowledge) that would mean that collidable objects would need to keep track of some sort of “index of last collision” so that the things that did collide with it could get all the data they needed about it, or to be even worse the objects that collided with the object would need to keep track of “index of collision”. In both cases that’s completely different objects knowing way to much information about the implementation of another object.

#7

Quickie impressions:

  1. Lotta hardcoded magic numbers in your PlayerAvatar class, personally I’d pull them from some kind of config file. At the very least make them into constants within the class so you know what they represent.
  2. I’d pull the keyboard state into it’s own class and pass that down to the PlayerAvatar rather than munging key state tracking into PlayerAvatar. Will make it easier if you need to use input state in other areas later (like other vehicles).
  3. I generally find it poor form to initialise object members when declared as this can have weird side effects when using inheritance. Keeping that stuff in the c’tor where it belongs is nicer.
  4. Stage dimensions should be defined within your stage abstraction, not hardcoded in the avatar.
  5. Hardcoded level definitions are obviously bad (PlatPanel). I guess you’ll be loading them from level files at some point.
  6. Seperate game loops and threads for different states (racing vs. paused) is a no-no in my book. Put your game loop in the main thread and push it up to the top level Applet class. Pass update() and draw() calls down to whatever the currently active state is.
  7. Similarly with JPanel usage - just have one top level panel and draw your sub states into it as needed.
  8. doubles are slower than floats without any useful gain in accuracy. Prefer floats to doubles unless you really, really know you need the range of a double.
  9. Multiple variables named “bleh” which may have different types and shadow each other is fricken’ confusing.
  10. Since Poly holds the coords for the polygon vertices, why have duplicate references held in the derived LadderPoly/WaterPoly/MixedPoly etc.? Either make they ‘protected’ in the base class or use the accessor functions.
  11. In fact, why even inherit from Poly in the first place? Keep it a plain class for representing poly geometry and have a seperate interface/inheritance tree to represent surface properties which can be attached to a poly.

Your physics/collision seems to be pretty broken to me. Not only is it sluggish to the point of being uncontrollable but you can drift through solid objects and get wedged against objects too. I suspect this is mostly due to you simulating the player avatar as a single point - it really needs to be something with volume IMHO - a circle would probably work best to stop you getting snagged against corners.

HTH.

#8
#9

I’d like to thank everyone that replied. Now I’m off to do some tinkering whenever I get around to it.