Beta: Crystals

WIP games, tools & toy projects Archived Projects
#21

[quote]Done; let me know what you think (just a simple impl at the moment).
[/quote]
It works, but I would prefer a fast fade too.

[quote] I think I’d prefer to do a fast-but-gradual fade - but 1.4.1 is VERY slow at drawing translucent colours to the screen - even fillRect is slow (slow enough that you don’t want to be doing it more than once or twice a second).
[/quote]
Really? In my duke rogers game I do fillRect every frame to clear the screen as well as another 200 fillRects to draw the stars and I well over 80fps on my p2/266 laptop. fillRect should be fast enough I think.

#22

[quote]At least no-one’s asking for a multipayer version yet
[/quote]
I want multiplayer ;D

#23

the mouse button cheat is still there :slight_smile:

about highscore stuff, why not give my super-bad-ass-cooler-than-“tickle me elmo”-highscore server a go? http://h55d205.delphi.afb.lu.se/apps/wellplayed/
notice that’s far from finished. uploading highscores is done and so is export to html. the next thing is to improve the export to html so it can be done automatically (either when a score comes in or using a timer).

by the time your game is finished it’s probably around version 1.0 :slight_smile:

i’m working on my game at the moment so the highscore server is stalled at the moment, but it will be cool one day.

back to your game… the flash is fast here anyway.

you could also have a rotating cross. that would make it harder and add a cool twist. all sorts of power-ups and downs come to my head as i type this. reverse controls, add noise to movement, add drunken-mode, resizable cross and so on! :slight_smile:

#24

[quote]the mouse button cheat is still there :slight_smile:
[/quote]
Yeah; its actually very useful for testing (being able to cheat whenever I need to, to simulate certain conditions :slight_smile: ). I just deliberately don’t use it when playing seriously :). Once I start adding powerups, I’ll get rid of it…

My requirements:

  1. It doesn’t use Java on the server side (the company webserver doesn’t - and won’t - run java) :(.
  2. This game might at some point become commercial; I’m happy to be a free beta tester until then - assuming that was OK - but after that I’ll probably switch to something more powerful (e.g. integrated SQL-based highscores; integrated with downloads, online savefiles, and other funky stuff).

Sadist :). Actually, though, I’m afraid that might not currently be possible. I’m being cunning and getting high-precision collision detection out of Java2D, despite the fact that Sun didn’t think to include it - I consider this to be on a par with “forgetting” to include standard data structures like “List” until Java 2. However, it does require that the player object/silhouette be composed entirely of rectangles - what I don’t know is if you can AffineTransform those Rectangles; given how buggy most of Sun’s libraries are when you start using them in imaginative ways, I would expect I’d probably get a recurring NullPointerException deep in Sun’s classes if I tried (that seems to happen depressingly often with 1.4 libraries. Sigh.).

#25

Hmm. I have an app that makes heavy use of Java2D, and runs smoothly (approximately > 30 fps) - until you fill any rect, anywhere, with a transparent colour. Then it slows down to about 5 fps or worse. It could just be Java2D + certain AfffineTransforms + transparent fillRect - I don’t know, but I was only drawing that one rect. ?!?

#26

well, i think you should ditch your line crosses and replace them with nice looking images. now boy, fire up Blender and render away!

what do your company use on the server then?

i will switch to sql in a very distant future if hell freezes over and i win $10000000 on the lottery, oh and yeah if the new JGO site launches in my lifetime :slight_smile:

#27

instead of fillRect, try drawing a translucent image instead

#28

Why translucent? It’s the background, right?
I would guess you’re clearing each frame black anyway, and if so, why not clearing it with a different color and forget about tranlucency? That’s how I did it with duke rogers anyway (in which the background slowly fades to different colors), just a completely opaque fillRect.

#29

[quote]Why translucent? It’s the background, right?
I would guess you’re clearing each frame black anyway, and if so, why not clearing it with a different color and forget about tranlucency? That’s how I did it with duke rogers anyway (in which the background slowly fades to different colors), just a completely opaque fillRect.
[/quote]
Actually, the game uses a custom layered-components system I wrote; it makes it VERY easy to have a complex GUI with lots of independent layers; very easy to add new features, and even new interactive features (which normally tends to be quite tricky in a complex program).

The flash is implemented as an extra layer that is normally just empty (i.e. lets the layers below show through), but then flashes itself when necessary. Easy to code, easy to maintain.

I never clear any frames - I just let the layer below show through, and if the stack of layers isn’t completely opaque for all pixels, you get weird effects a la doom and idnoclip ;).

Basically, I wrote the bits of JLayeredComponent that Sun should have; if you look at JLC, you’ll see that it’s missing loads of basic functionality. I would much prefer that JLayeredComponent were actually a useful classes for users - it appears that the swing designers just thought of it as a building block for creating their classes-with-internal-frames etc; it could have been so much more than that!.

FYI: I created a few classes that, in essence, allow you to stack JComponent’s on top of each other, and get various extra methods that JComponent SHOULD have, but Sun forgot to include (some of which I’ve logged RFE’s for). For instance, although Graphics is specified as “storing the translation”, there’s no clear way (nothing using just Graphics; presumably there IS a way, but it’s probably in the wrong place, and I certainly haven’t found it yet :frowning: ) to actually read the translation - and this is an ESSENTIAL requirement to writing any GUI where translation is used, because you need to know in order to correctly interpret things like the mouse co-ordinates from MouseEvent’s…

#30

idnoclip lol

#31

[quote] On this version, my personal best is 49,746
[/quote]
70,629. I think it was level 22. Maybe it was higher. ;D

#32

[quote]The flash is implemented as an extra layer that is normally just empty (i.e. lets the layers below show through), but then flashes itself when necessary. Easy to code, easy to maintain.
[/quote]
Smart, but as it seems to turns out, not very fast in execution.
Isn’t the background (with the stars) also a layer that’s drawn anyway which you can just draw in other colors instead of black to get the flash effect?

#33

  1. I think the execution-speed problem is merely because my Swing painting is highly un-optimized. It works fine on my test 1ghz laptop, so as long as it’s smooth enough for testing not to be unpleasant :slight_smile: I’m not yet ready to start optimizing.

  2. Sneak peak of what I’m going to do with the layers:

http://grexengine.com/sections/people/adam/crystals-full-v1.299999.jar

(note: please don’t bother telling me about the ConcurrentModificationException - I know; this is not a “real” release, it’s just the latest working build…Ditto don’t get too concerned about the fact that all the mines now attack you - it’s just for testing the movement! :))

EDIT: FYI, there are 3 or 4 backgrounds in that build, and each level randomly selects a background; you might have to play through as many as ten levels to see all the backgrounds. Not too exciting, but once the background-selection is working perfectly, I can worry about adding more interesting ones :slight_smile:

#34

haha it’s great fun! i know my dad is gonna love this.

with “moving bombs” i thought that they would jiggle a little, but this is also cool.

it’s another game now. it would be cool if you had two modes: one with following bombs and one with jiggling bombs. just suggestions.

how about letting the starfield follow the mouse? think it’d be a cool effect.

keep us posted!

#35

Nice :slight_smile:
On my 1GHz desktop it’s not yet very smooth, but I’m sure that’ll come in time. Also sometimes the background completely stops moving when I move the cross. Probably related.

#36

[quote]Nice :slight_smile:
On my 1GHz desktop it’s not yet very smooth, but I’m sure that’ll come in time. Also sometimes the background completely stops moving when I move the cross. Probably related.
[/quote]
Yeah, at the moment I’m only using 40% CPU to handle everything on a 1ghz PC, so I should have a lot of room to e.g. increase the frame rate (but I have no idea until I start delving what the causes of jerkiness will actually be…)

Out of interest, is the lack of smoothness a constant thing (i.e. could it be just that the frame rate is too low?) or is it occasional jerks? I’ve just checked, and the starfields are currently all aiming to run at a measly 25fps!

The background “completely stopping sometimes when you move the mouse” is quite scary; I fear it could be a VM-specific issue.

#37

It really looks like a logic/event handling issue. It stops completely for me anytime the mouse is being moved. BTW there is a really easy way to cheat. Move the mouse outside the window and then back into the window at a point close to a gem, then you don’t have to move through the mines. This also allows you to get at mines buried in a blob of mines. Hold the mouse out side of the window and jerk it onto the window very quickly. The cross never “goes through” the pixels between the edge of the window and where the mouse ended up when you stop moving it.

#38

There’s an even easier way to “cheat”. Click and drag the mouse and the cross won’t move until you let go of the button. Thus you can transport your cross anywhere you like. How do you think I got 70,000 on my first try? ;D

#39

[quote]It really looks like a logic/event handling issue. It stops completely for me anytime the mouse is being moved.
[/quote]
The thing is, it NEVER stops for me, and the logic means it never should. And I don’t think I’m the only person who doesn’t have that particular problem?

Going “outside the window” is actually intentional - otherwise the game would quickly get totally impossible on harder levels.

However, the “jerk the mouse in quickly” bit was something that didn’t occur to me (doh!). As mentioned in an earlier post, the current link between mouse and player’s cross is only temporary - there will be a variety of different versions (some enabled by powerups/powerdowns, others enabled by specific levels).

However, I would like to keep the current behaviour (note: I AM intending to remove the mill/jbarnes cheat; sorry, guys :)) - except that your “jerking the mouse” is something I’d like to do without.

Hmm. Guess I’ll have to start doing proper swept-volume collision detection; this is not going to be as easy as you might imagine: it will probably mean writing a new collision-detection routine from scratch :(. Alternatively, maybe I can get away with a “maximum step-size” which is the largest amount the player can “jump” by - so that even on a long jump, of distance say 300 pixels, I only have to do (300/max-step-size) * numObjects collision checks… that might be OK (a the moment I do one: for the end point :slight_smile: - hence your cheat!).

#40

Well, my cheat is pretty easy to fix. Just make “mouseDragged” call “mouseMoved”. The jerking motion however, would need you to move the cross along a line from the last point of the mouse to the current point of the mouse. (Time to go study Breshenham’s (sp?) algo, eh? ;)) You can make the “out of bounds” trick work correctly by listening for MouseEntered and MouseExiting. Sadly, jumps from outside the window will have to start from the first point received bv MouseMoved.