Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Code Review - of project so far  (Read 1454 times)
0 Members and 1 Guest are viewing this topic.
Offline lithos

Junior Member


Medals: 1
Projects: 1



« Posted 2009-07-08 22:53:27 »

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.   

There are no such things as bugs...  Only happy accidents.
Offline aazimon
« Reply #1 - Posted 2009-07-09 00:26:23 »

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.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #2 - Posted 2009-07-09 01:40:59 »

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.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline lithos

Junior Member


Medals: 1
Projects: 1



« Reply #3 - Posted 2009-07-09 22:40:07 »

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.

There are no such things as bugs...  Only happy accidents.
Offline marinepower

Junior Member


Projects: 2



« Reply #4 - Posted 2009-07-10 05:32:46 »

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.
Offline lithos

Junior Member


Medals: 1
Projects: 1



« Reply #5 - Posted 2009-07-10 16:58:09 »

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.

There are no such things as bugs...  Only happy accidents.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #6 - Posted 2009-07-10 18:02:25 »

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.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline lithos

Junior Member


Medals: 1
Projects: 1



« Reply #7 - Posted 2009-07-10 19:56:05 »

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.

Was going to be changing this eventually, just a knacking of laziness for why it wasn't done alread

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).

I'll put it down to the 5th or 6th thing to do, sounds like something that would be very nifty for future updates


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.

Poly test = new MixedPoly();   if this is what you're talking about that's something that I can see happening but haven't seen before.   Will change


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.

Now the game loop to the applet in sounds like a very good idea.  I'm working on changing that right now.

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.

This is something that's changable

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.

The plan was to save memory by using referances to the Poly objects themselves, rather than their vertices which I plan to be too varied in a finished level to be worth reusing the vertices.

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.

It seemed like a good idea, but then again the only thing that's different right now is how it generates a collision, and in the future how it renders itself it's something that I might change again.


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.

I'm working on it.  Right now I've just increased gravity, and increased up force vectors.   It seems a bit smother right now.   As for being only having one point I plan on having startLeft/Right/Top collision methods

Physics changed
HTH.

There are no such things as bugs...  Only happy accidents.
Offline lithos

Junior Member


Medals: 1
Projects: 1



« Reply #8 - Posted 2009-07-11 20:44:17 »

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

There are no such things as bugs...  Only happy accidents.
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

List of Learning Resources
by SilverTiger
2014-07-31 18:26:06

List of Learning Resources
by SilverTiger
2014-07-31 13:54:12

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
java-gaming.org 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‑gaming.org
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!