Just submitted Pipe Extreme. Hopefully it'll be a bit more popular than my previous (boring) Space Inversion entry!

I'm still making changes to PE (submitted version is 0.9). I still plan to add another level or 2, and to add some more square colours and maybe another effect.

I'm a bit concerned that it may not run quickly enough on slower machines. If you have any problems in this regard, or have any comments at all, please post them here, and I'll see what I can do (still have 100 bytes or so )

Cheers, Tim.

Pipe Extreme (v0.9)

Jump and roll your way along the pipe. Score points for speed and for "picking up" yellow squares. Watch out for those other coloured squares though (and the holes)!

Are you just using graphics.fillArc() or implementing your own methods through pixel editing? Either way you've implemented it pretty well, no complaints graphically at all.

The game is a little difficult to control however (first impression, maybe it will get easier for me?) and I have yet to have been able to get through that loop. It's a bit easy to make (or neglect to make) sudden movements that will then result in your losing or slowing down. Maybe shorten the red distance required for those jumps and widen that loop a little?

I really like this game.. a great improvement to "Tube Blazer" (from one of the very first contests). the only thing that strikes me as odd is the control. like when the ball is at the top of the pipe, I would expect pressing the RIGHT arrow key would make the ball move LEFT.. but direction seems kinda.. absolute?

I'll think about it. So far people have said it's too hard, and making it even faster would make it harder still. Speed squares that speed up for a short time would be good I guess (you don't have to go on them ).

Looks really slick, but far, far too hard to be fun IMHO. I think it's that the momentum of the ball is so high, you end up pressing left and right for ages just to get it to start to move, and you always overcompensate and end up swinging back and forth. Tighter, snappier controls and it'd be great to play.

I'll think about it. So far people have said it's too hard, and making it even faster would make it harder still.

I don't really think it will make it harder, since you just give the player the ability to go faster. That doesn't mean that the player has to go flat out all the time. Have a look at trailblazer. That was quite fast if I remember correct.Pretty much agree with all previous posters. Would also be nice to have a few restart points in each track, so one won't have to restart from very beginning. Levels are quite short, so maybe not a must if controlls and levels get a bit easier. Lvl 1 was hard, lvl 2 way too hard way too early, then I gave up...

Make it easier for a few more levels and I'll definitely will play it some more

My Highscore is: 15608280 Don't know if thats good, but i got when i replayed the first level 3 timnes, as i always died in the end

It is possible to get around the corkscrew... but it seems that people do find it a little hard... so I've moved it to level 4 now. There's now an easier version of it (where you can't fall off ) in level 2.

yeah i thought about that after i posted, there's not many ways around it. i'll just have to get used to it

I think it may work if you can't control the ball while in the air at all, with the change that you can control how hard it jumps. I'm going to try to add this jumping control anyway, so once that's done, I'll try the other control method again and see what I think.

I guess that there are 2 problems here:1. The score and level info is obscured by the Java banner. This is 'cause I'm drawing directly on the Frame I guess. I'll have a think about it and see if I can work out a way around it.2. There are black dots where the tiles touch. This is a graphics glitch that I guess I'm probably not going to bother with trying to fix.

I've switched my own game to use JComponent (inherit JComponent).JComponent already gives you double-buffering, so you don't need to implement it yourself.Dunno if it works for fast games (my aichess4k is round-based).

The new levels are pretty cool! After training the loop in (dunno, level 3?) I actually made it through the more difficult one where tiles are missing.However, let me suggest you do the levels in a different order. First the really easy, short ones, and later the longer and more difficult ones.

Btw. do you happen to know Trackmania Nations? It's actually available for free, so grab it and try it if you want.Trackmania Nations is a stunt car racer and the levels are kind of similar to yours. TM starts of with a really simple straight road. Then it adds a curve. Then it adds a jump. Then you get more complicated jumps. And so on.

I've switched my own game to use JComponent (inherit JComponent).JComponent already gives you double-buffering, so you don't need to implement it yourself.Dunno if it works for fast games (my aichess4k is round-based).

You don't have to implement it yourself on Frame either... well you don't need to get a back buffer, and then copy it.

I guess your comment about real time is relevant. In a real-time game you want to take control of when screen updates happen, rather than invalidating then waiting for the system to ask you to draw.

how are you storing the levels by the way? is it like one chunk of map data for each level? if so.. you might can save some space by paritioning the levels by "features." for example.. each level has specific features.. the red ring, the loop, etc.

let's say the red ring is feature #1, the loop is #2, and ordinary greenspace is #3.

so what I'm trying to say is.. procedural (or hey, even random) level generation. something tells me you're doing something similiar.. because, i mean, these levels are kind of long just a thought though

It's pretty much like this... but using an array in this way is horribly expensive in byte use. Try it and see. Each entry takes 6 bytes! It took me ages to figure out why. (hint: the compiler actually writes the bytecode to stuff the value into each individual array entry... yuk!)

You don't have to implement it yourself on Frame either... well you don't need to get a back buffer, and then copy it.

I guess your comment about real time is relevant. In a real-time game you want to take control of when screen updates happen, rather than invalidating then waiting for the system to ask you to draw.

That's what I mean. However, if you do invalidate and wait for the system, that can save quite a bit of space. You are referencing BufferStrategy as well as createBufferStrategy and getBufferStrategy. That means three strings containing exactly that are part of your classes constant pool. If you just call repaint instead, that can save quite a bit.

And you know that you should do:

1

level[x] = "\03\03\03\01\03\03\01\02";

don't you?

Oh, and I really like the short levels. I'd rather put them at the beginning.

That's what I mean. However, if you do invalidate and wait for the system, that can save quite a bit of space. You are referencing BufferStrategy as well as createBufferStrategy and getBufferStrategy. That means three strings containing exactly that are part of your classes constant pool. If you just call repaint instead, that can save quite a bit.

But then you instead have another class: JComponent, plus a reference to JComponent.repaint(), plus you have to override paintComponent(), and, most significantly, all the variables that are required in order to paint need to be class members rather than local vars.

Here's my "minimal game" program. I wrote it to try various idea out about how to make the smallest possible game loop that has all the support I wanted. If you can make a version which has all the same functionality, and can have the drawing separate to the game loop, then I'd be glad to use it (in fact this is an older version, I've got a slightly smaller one now but I don't have the source with me.)

the compiler actually writes the bytecode to stuff the value into each individual array entry... yuk!

well yes, just an example

you should release your source code. I bet you *almost* anything I can throw it back to you with smaller bytecode.. ask anyone here (appel, kevglass, etc), I've been doing this waaaay too long. and there are others here who are even more insane than me!

you should release your source code. I bet you *almost* anything I can throw it back to you with smaller bytecode.. ask anyone here (appel, kevglass, etc), I've been doing this waaaay too long. and there are others here who are even more insane than me!

Well I may do later. I don't have the source here with me at work ATM anyway.

I've not completely run out of space yet, but I'm always mindful of the way that adding extra stuff uses it up.

It goes like this.... I add some code... now the progs to big... so I go through it and try to remove some code without losing functionality ... prog is now smaller ... goto loop. I've still got some ideas for things I can chop out (for example, I've got 3-d vectors in there... it may be possible to get away with 2-d ones in many cases. The code is still fairly 3-d generalised... the ball could go ahead down the pipe and still be rendered ok... this could probably be simpified a little, etc.).

I currently push the code through proguard and joga, and then bjwflate it. I've experimented with the internal pack200 stuff, and that'd save some space too, but at the moment I don't need it, so it's not in there (BTW I got the header class for decompressing the pack200 down to 1045 bytes -- although I haven't tested that it actually works! )

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