Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Xith3D Forums / Re: Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-12-13 15:43:46
Oh, I'm sorry. I hadn't been checking the forums for awhile - mea culpa. Sad Thanks for helping me to commit it, arne.
2  Games Center / Archived Projects / Re: Paradroidz reloaded... on: 2005-11-24 13:13:52
(Edit: ACK! Sorry for the necromancy; I didn't realise the first-page threads were that old until I took a closer look.  Embarrassed )

Brilliant. I suppose you've had the advantage of having an existing (excellent) design to work from, but this is still pretty damn brilliant.

FWIW, I never owned a C64 - my first computer was a PC-XT - so this is my first crack at a Paradroid-like game, and I think I like it.

Please get the consoles working!

I've also got a couple of suggestions...

(1) Whenever you send a pulse, the pulser's position resets. Could you adjust it, or at least offer a control option, such that:
- sending a pulse doesn't reset the pulser's position, and
- pressing the "influence mode" (?) key does?

So the player could pulse a bunch of control lines and then reset the position of the pulser to hit another line that's near the start position (for example).

(2) I noticed that some droids don't use lasers (like the 300-series) and some have special weapons (I don't even know what series those are; my 400-series got chewed up pretty quick by them!). Could you adjust it so that when those droids are taken over by the player, they retain their unique abilities? (Do they already?)

(3) This may sound like sacrilege, but maybe there should be a minor puzzle-solving element to the game. Like, there might be laser barriers in an area that only certain droids would be immune to, or extreme temperatures which would damage certain models of droid, or pits that could be hovered over by a hovering-capable droid. This would make the droids very, very different in their abilities and encourage more hopping!

(4) Have an "easy"/"wimp" mode where the player can rack up multiple "lives" by taking over droids. So if the player took over two 300-series and then failed to take over a 400-series, the second 300-series would be destroyed but they would revert to the first 300-series. (Needs balancing... I can see players taking over a bunch of 100-series and then using them to kamikaze some high-level droids. Perhaps in this mode, the high-level droid would shoot the player once before attempting to self-destruct... if it managed to one-shot kill the player, it wouldn't self-destruct.)

Edit: (5) An optional command-line input interface for the hacking minigame would be awesome! Just label the connection lines 0-F and pop up a text I/O window next to the pulse display (or above/beneath it).

> PULSE 0,1,3,7,D

Thanks, and good luck with the project!
3  Games Center / Archived Projects / Re: Space Dudes (Java 1.1 compat) on: 2005-11-24 11:37:35
I can't quite put my finger on why, but it's good stuff... "Robotron" with a couple of extra bells and whistles. Not quite "I'd pay to play that" good, though - partly because personally I'm not a huge fan of the style. Still, I like it.
4  Games Center / Archived Projects / Re: Magic Carpet Game just finished on: 2005-11-24 11:12:31
I like it!

I'm not sure there's much that can be done to improve this other than what's already been stated. It's a small game with a fun hook.
5  Games Center / Archived Projects / Re: Cyberion - 2D Shooter Game! on: 2005-11-24 10:31:54
Oh, sorry, I forgot to add: there's another thing that's problematic. When you die, your shot power goes down - fairly standard, right? The problem with that is that this tends to lead to more deaths because the game is balanced based on the player being at maximum power (so it seems, at least).

Possible solutions (pick one):

- be more generous with powerups
- don't make the player lose power when they die
- adjust the enemies' HP/aggressiveness according to the player's gun power (a common design strategy in shooters)

In the last case, be careful how you do it. Don't go so far that players will suicide to make the enemies less aggressive Grin
6  Games Center / Archived Projects / Re: Cyberion - 2D Shooter Game! on: 2005-11-24 10:14:36
I think you've got something fairly good going here - it just needs a bit of tweaking.

First, yes, the levels are a bit too long. Tongue

Another thing is that certain enemies are a bit unfair - especially the ones that fire fast blue bullets. If the player isn't expecting it, those can prove instantly fatal with no chance to dodge. I would suggest that you do one of the following:

1. if the enemy is going to fire a fast bullet, make them play a "charging" animation (blue particles?) just before so the player has some warning, or
2. make the bullet start slow and accelerate.

The weapons also need balancing, it seems. Red is a bit overpowered, while green and blue seem a bit underpowered. (btw, in the applet version, the green weapon doesn't have a sound.)

Scoring system would be more interesting if you added bonuses for doing interesting stuff.

Finally, THE PLAYER'S HITBOX IS HUGE! In practically all commercial shooters these days, the player's hitbox is smaller than their sprite. About 80% of the time, the hitbox is miniscule - say, about the size of the plane's cockpit. IMO it would help to decrease the size of the hitbox - THEN you could add more bullets without worrying about unbalancing the game. As a start, try making the hitbox cover only the centre portion of the plane - not the nose or wings.
7  Games Center / Archived Projects / Re: Ship Shooter - Java Space Shooter Game on: 2005-11-24 08:43:40
Okay. Where do I start?

First off, please don't take this the wrong way, but your game has a couple of fairly nasty gameplay flaws. I don't want to just hurl destructive criticism at you, so I'll explain those in a bit.

The GOOD parts:

- I like the ship design. Very retro, very cool.
- The boss movement AI is fairly well-tuned, neither idiotic nor too smart to be beaten.
- Your extra powerups (+score, weapons, health) are well-done, although they could use some sprucing up in the visual department.
- The game runs very smoothly - no tearing or jerking, at least on my machine. (Consider making an FPS counter?)

The UGLY parts:

- No explosions. Consider doing a simple particle system for explosions; it works wonders.
- The quantization issue, as mentioned by another player. (This gives me headaches. Please fix it.)
- Enemies don't move horizontally enough. The game degenerates, in the later stages, into a "zone-defense" game because the player can keep the enemies out of a particular "no-fly zone" by means of overwhelming firepower. If some enemies swooped quickly across the screen before opening fire, you could force the player out of their safe area.

The BAD parts:

- Enemies come in very haphazard waves.

I understand it's random, but consider implementing a limited formation system, e.g. occasionally randomly spawn FORMATIONS of enemies (say a 5-ship arrowhead formation) rather than individuals. The human mind thrives on recognising and adapting to patterns, and this is very much true for games. As you've probably noticed, most shooters have enemies which spawn in specific patterns and formations.

- Your ship's weapons are broken.

My mouse hates you. Wink Implement a rapid-fire system at least, so I can just hold the button down. At the higher levels, the optimal strategy seems to be "spray and pray" anyway, so players are NOT going to be taking carefully-considered shots. Also, it's too easy to box the bosses in and finish them off, at least up till level 14-15 or so. (I suicided on level 15; it wasn't that the game was too easy, just boring for the reasons I'm mentioning here.)

I would suggest that you implement a dual-weapon system and give most enemy ships a certain amount of HP:
The main weapon is a rapid-firing laser or something similar. It just projects a beam up to the top of the screen that hits anything in its path, but only drains a miniscule amount of HP. In other words, you need to sweep the laser across a target 2 or 3 times, or hold it on them for a short time, to destroy them.
The secondary weapon is rockets or torpedoes, which behave much like the player's current shot. However, the torpedoes only have a finite number of shots before they have to reload - in other words, after the player fires (say) 8 shots, they have to wait a second or two before they can fire again.

In this way you can make the boss fights more interesting by preventing the player from completely boxing the bosses in. The player can tackle regular enemies by using the laser sweep and well-timed torpedo salvoes. You could map the two weapons to the same button, or map (say) the torpedoes to the RMB.

- Difficulty and pacing are very poorly done.

First, let's talk pacing. The GOOD thing you did with pacing was to wipe out all onscreen bullets when the boss goes down. However, you probably need to do a bit more to modulate the tempo of the game. I would suggest that you also destroy all onscreen enemies when the boss dies, and start a timer for e.g. 2-3 seconds during which no enemies spawn. (During this time, it would be cool if you displayed a little placard in the centre of the screen saying "LEVEL 2 - GET READY!" or something.) This presents the player with a definite arc of tension in each level, starting with the small enemies and ending with the boss fight.

Now, difficulty. Skilled or semi-skilled players are going to be extremely bored with your game in levels 1-9, and may not stay long enough for it to get (somewhat) interesting. I faced the same issue when designing my own shooter "Uplift" (now defunct - I'm working on a new game!), and the solution was to implement a risk/reward system.

What do I mean? Well, to keep the skilled players interested, you have to make it so they'll do risky but optional things that require more skill in the early stages, so it'll be more difficult for them but not for the unskilled players. A very rudimentary version of this is present in your game, in the form of the power-up ships, but it's not extensive enough to be anywhere near sufficient.

Let me just describe what I did with Uplift. I had two avenues of risk/reward in the game.

1. Powerups. In Uplift, every enemy drops powerups. The player has to collect tons of these to power up his weapons (64 for maximum power, to be exact). However, when the player's gun power is above 32, it slowly decreases at a rate proportional to its current level. So to maintain your gun power at a high level, you need to keep on flying into danger to grab powerups. Furthermore, when the player's gun power is above the maximum level, all the score he earns is multiplied (>95 gives X2 score, >111 gives X4, >119 gives X8, with the power capped at 127). Maintaining your gun power is crucial to high scores in Uplift; an unskilled player could survive with a gun at level 70 or so, but would get a much poorer score than a skilled player who keeps on flying into areas of heavy enemy fire to grab powerups and maintain his gun power at 120+.

2. Point-blank bonus. Uplift awards the player bonus score multipliers depending on how close he is to the enemy when he destroys it (again, from X2-X8). Naturally, flying close to the enemy without crashing requires more skill, but gives greater rewards.

An analogous mechanic is the "chain" mechanic in Ikaruga, or the formation-destruction bonus in Galaxian.

One thing you could do for similar effect would be to give the player an increasing bonus for every enemy he destroys, with the caveat that the bonus resets or gets lower if an enemy manages to escape off the bottom of the screen.

In summary, please fix the weapon and movement controls, and give the player more interesting things to do at the low levels.
Also, it would be interesting if the bosses could fire diagonally once in awhile, to keep the player on their toes.

I hope that wasn't too harsh; I'm just trying to suggest ways to make your game better.
8  Java Game APIs & Engines / Xith3D Forums / Re: How can i apply a video stream on a surface using Xith3D ? on: 2005-11-23 06:44:46
Easiest way is probably to use a BufferedImage (I assume you can grab the current frame of your video as some paintable image), but expect your framerate to drop like a stone. I'd guesstimate it at 20 FPS or so with an average (i.e. cutting-edge about 2 years ago) PC setup, depending very much on the resolution of the video. If your stream is something like 240x180, then it might put out decent FPS.

How I implemented dynamic textures for my current project went something like this:

- Get a handle on a placeholder Texture2D. Be sure you load it with the dynamic-texture flag set.
- Use the texture's getImage() method to get an ImageComponent2D.
- Call getImage() on the ImageComponent2D to get a BufferedImage.
- Get a Graphics2D context from the BufferedImage.

- Apply the Texture2D to your geometry.
- Every frame, paint the video to the Graphics2D.
- Then call update() from the ImageComponent2D to update it.

There's probably a much faster and more efficient method, but this is the best I can offer. Good luck!
9  Java Game APIs & Engines / Xith3D Forums / Re: Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-11-23 06:34:06
Thanks. Have implemented that, but only for loading the MD2Model directly with load() - in other words the load() methods that return a Scene automatically default to loading the version with normal data. I believe that should - hopefully - be sufficient.

I've zipped up the new files, the original files (.old), and diff output (.diff). ( doesn't have .old or .diff info 'cause it wasn't in the previous version.) Since I don't have write-access to the TK filesharing page, I've uploaded it here:
10  Java Game APIs & Engines / Xith3D Forums / Re: Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-11-22 08:16:11
I am pleased to report that the new normal modification actually seems to work.

I'm afraid that my modification does raise the RAM load per model quite a bit (approx. 1 extra byte per vertex per frame, plus extra vector arrays to hold the normal data), and I'll have to go over the code and clean it up before submitting. Also, I didn't do a proper normal-interpolation for the frame interpolation as I couldn't figure a fast way to do it, so I just averaged the normals and threw in a quick and dirty hack to prevent it from crashing out if it encountered a zero normal. In the modifications I have attempted as much as possible to privilege speed over memory usage (memory's cheap).

Sorry - like I said, I'm an armchair coder and hence not that well-versed with the use of CVS, etc. Would it be acceptable to just compress up the changed files (5 changed, 1 completely new) and send them to somebody? If so, who? If not, what's the best format for submitting the changes? Is the output from a diff acceptable, and if so which switches should be used for ease of review?

Thanks for all the support and help.
11  Java Game APIs & Engines / Xith3D Forums / Re: Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-11-16 05:19:00
Thanks again! I'll give it a shot, but don't have CVS myself  Tongue

The best I can do is post the source here if/when I actually manage to make it work... I'll see about that.

Edit: Yes, I can see what needs to be done. A question about best practices, though: since I'm more or less an armchair coder, what's the best way to go about this?

- rebuild the original package, retaining the name org.newdawn.*,
- build a new package, with a different name, that depends on the original xith-md2 package (might be messy to do it this way),
- build a new package, borrowing from the existing code and giving appropriate credit, and call it something else,
- something completely different?

12  Java Game APIs & Engines / Xith3D Forums / Re: Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-11-15 06:04:08
Thanks. I'll see about dumping the tree out and fiddling with it. Smiley

Edit: Yes, it seems to work. Thank you!

Do you mind if I ask about something else? Now it seems like the surface normals on my model are completely borked. All of them seem to be set to (x=0,y=1,z=0) or something like that, because when the model is facing towards the light, the whole thing lights up, but when it's facing away, the whole thing goes dark. This behaviour occurs when I use the stock model (tris.md2) provided with the loader as well. Do I need to do something to make it recalculate the surface normals every frame, or something else?
13  Java Game APIs & Engines / Xith3D Forums / Newdawn MD2 loader: way to swap appearance of an MD2 on the fly? on: 2005-11-14 06:28:11
Does anyone have a hack/workaround which allows me to set the Appearance of an MD2Model (from the Newdawn MD2 loader) after the model has been loaded? It looks like that isn't possible with the stock version of the loader.
Also, is it possible to set the Appearance for individual MD2ModelInstances or only for the base model and, if the latter, will it affect all the Instances of that model?

Thanks in advance.

- 5parrow
14  Java Game APIs & Engines / Xith3D Forums / Re: Got a gamedev job! on: 2005-11-14 06:24:16

Good luck, and I hope it doesn't get too hectic around crunch time!
15  Java Game APIs & Engines / Xith3D Forums / Re: Can't get alpha blending to work properly on: 2005-10-13 06:23:24

(edit: deleted my stupid question ^^; - I somehow thought that tutorial was about multi-texturing on single geometry, until I took a closer look!)

Thanks! It works now - easiest fix ever. (4 lines of code!)

Uh, two questions:

- What's the functional difference between DecalGroup and OrderedGroup? They look the same in javadoc.

- Am I correct in assuming that both of these group types work by directly re-adjusting the order of stuff in the depth buffer? (Sorry, I'm not a 3D expert.)
16  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2005-10-11 08:11:16
Thanks for your help. It works now!
17  Java Game APIs & Engines / Xith3D Forums / Re: Can't get alpha blending to work properly on: 2005-10-11 08:05:11

(Edit: sorry to dig this old thread up, I didn't notice the date on it.)

I'm having a "windowing" transparency problem.

What happens is that I'm drawing 2 textured quads with alpha channels, one in front of the other, for a HUD. The quads are non-intersecting, perpendicular to the camera.

I've given both of them the following TransparencyAttributes:

TransparencyAttributes blendedTA = new TransparencyAttributes(TransparencyAttributes.BLENDED, 0.001f, TransparencyAttributes.BLEND_SRC_ALPHA, TransparencyAttributes.BLEND_ONE_MINUS_SRC_ALPHA);

Texture mode has been set to MODULATE.

However, when Xith draws the foreground texture, it does not blend with the background texture. Instead, it blends with the geometry behind the background quad. (So it appears to "cut a hole" in the background quad.)
I have attempted to use RenderingAttributes to fix this, but it seems to make the problem worse. Using a vanilla RenderingAttributes() with depth buffer writes enabled causes the background quad to disappear completely. Conversely, using RenderingAttributes(true,false,0.01f,RenderingAttributes.GREATER_OR_EQUAL) to disable depth buffer writes causes the foreground quad to disappear.

I'm at the end of my rope again. This is driving me crazy (and what's worse, it was working just this morning without any RenderingAttributes, and predictably I FORGOT TO BACK UP AGAIN.) Help!
18  Java Game APIs & Engines / Xith3D Forums / Re: Creating textures during runtime on: 2005-09-29 08:26:55
Sorry to bump; couldn't find a newer thread on the same topic.

I've been using Jeramie's method, with the new flag to make the new TextureLoader load by-ref.

The alpha channel is working properly.

However, my paint updates aren't being reflected to the scene. (I'm painting the texture before calling renderOnce().) I can confirm that it is using the correct texture, and that the paint method is being called. Also, it doesn't appear to be an alpha-related issue, because the opaque parts of the texture (currently red) aren't being painted over either.

Any help?

public XDForegroundOverlay(int width, int height, Texture2D startTex) {
    mainOvl = startTex;   //Texture2D
    mainOImg = (ImageComponent2D)(mainOvl.getImage(0)); //ImageComponent2D
    myBuf = mainOImg.getImage(); //BufferedImage
    myGfx = myBuf.createGraphics(); //Graphics2D

and later:

    myGfx.drawString("myon: "+System.currentTimeMillis(),512,256);

Thanks in advance for any help.
19  Java Game APIs & Engines / Xith3D Forums / Vertex/skeletal animations, Xith3D and Java3D? on: 2004-12-13 17:51:13

I'm still a semi-fledgling J3D coder, and I'm considering moving to Xith3D.

How is Xith's support for skeletal and/or vertex-animated meshes? I've tried to "fake" vertex animation in J3D using ALLOW_GEOMETRY_WRITE and manual vertex manipulation in code, but the results were extremely unsatisfactory in performance terms, and I haven't found any documents online detailing a good way to make it work.

Can anyone point me to good sample code for vertex/skeletal animation in Xith?

Thanks in advance.
20  Java Game APIs & Engines / JInput / USB keyboard oddities on: 2004-06-04 18:03:20

Have experienced strange results with a Memorex USB keyboard under DX9. I haven't installed the drivers for the additional silly buttons (never use them anyway).

I wrote up a little diagnostic prog to dump the name and type of all controllers to the console.

When I run it, my USB keyboard shows up as 3(!) separate devices of type STICK with the name "09292003".

Anyone else noticed this happening?

- 5parrow

EDIT - Am running WinXP (if that wasn't already implied). I checked Device Manager, and sure enough 3 "extra" devices show up on the same port as the keyboard - probably the silly buttons. I'm still a bit puzzled as to why JInput seems to think they're STICKs given that the system does not know what they are at all.

Oddly enough, the USB keyboard and my laptop keyboard do not register as separate controllers.
Pages: [1]

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

The first screenshot will be displayed as a thumbnail.

rwatson462 (36 views)
2014-12-15 09:26:44

Mr.CodeIt (29 views)
2014-12-14 19:50:38

BurntPizza (61 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (58 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (76 views)
2014-11-29 21:32:03

toopeicgaming1999 (137 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (37 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50 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‑
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!