Mage Wars (Complete)

Contests 4K Game Competition - 2011
#1

I think this is now complete:

  • Fireball your opponents into oblivion to take all four castles
  • Up to 4 players (on same LAN segment) - so this is a signed applet and generates network traffic

You can test multiplayer using multiple tabs in Internet Explorer if you only have one machine. Dual CPU fast machine highly recommended as this is much more CPU intensive than my previous entries.

Controls:

  • Cursor Keys: Movement (or WASD)
  • Mouse: Targeting

http://www.java4k.com/index.php?action=games&method=view&gid=311

Update:

Final

Bugs

Minor bugfix uploaded to Java4k 22/02/11

#2

Hi Allan,

Compliments of getting this far with network and cool graphics!
I was experimenting / thinking of doing some network things too so I will
be watching this with great interest!

Best regards from

M.E.

#3

Looks really nice! It runs very smooth.

#4

Thanks for the kind comments.

Progress:

  • Improved framerate when there are lots of objects on screen by improving object culling.
  • Discovered that multiple instances of applets share static variables (which was causing side effects when running multiple instances on the same machine - seems to happen with Plugin 1)
    – This actually has some interesting applications
  • Started on fireball/wizard collision logic. I’m hoping it will all fit in within 4k.

Adding sideways movement (strafing) would be nice. Perhaps add WASD movement control and then put strafe left/right on Q and E. This would work for QWERTY and QWERTZ keyboard layouts (so the Germans will be Ok), but not for the AZERTY keyboard which I believe is used in France. Maybe leave cursor key control in as well if there is room, which would give easy access to movement (except strafing) in most countries. Views on the best keyboard controls are welcomed.

Progress will be a bit slower for the next few days as I’m going out quite a bit as my social calendar picks up as we head towards christmas.

#5

RDFG with strafe on E and T? I think that’s the same for QWERTY, QWERTZ and AZERTY.

#6

Updated - see first post.

However doing the multiplayer collision detection has taken up most of the remaining space. It still needs to be optimised but I think it’s not going to fit in 4k - It’s still missing enemy AI, Player damage display and logic to keep track of which castles have been taken. The plan now is to add the remaining bits to get a playable version and then look to see if anything can be taken out.

The collision detection is a little basic, and relies on interpolating player movement (which also smooths the screen movement of remote players).

#7

Things I’ll probably have to take out to gain some bytes back:

  1. There’s some debug code still in there for printing frame rate and creating initial object positions

Removing this will gain a dozen or two bytes. No pain.

  1. Removal of cursor key control

This just leaves ESDF keys plus WR for strafing. This is unlikely to save more than 10 bytes (if that), so will leave this until I get really desperate.

  1. Tagging of players with their login names during multiplayer

There’s several library calls that only apply in this code including System.getProperties(“user,name”) and a couple of string functions to convert strings back and forth between byte arrays of “UTF-8”. I probably can also lose graphics.drawString if I don’t use it on the overlay. There is also dedicated code to work out where to draw the names on the screen.

Players will still appear in white, so there is no real loss in 2-player. It’s a bit more annoying for 3-player.
I like this feature as it gives a real online multiplayer feel, but the reality is that most people will only try it as single player, so it will have to go. I think this could save 100 bytes, maybe even more.

  1. Removal of mouse targeting control

I really don’t want to do this. At the moment, the player can only fire one fireball at a time. If I allocated more slots in the network code, it wouldn’t be difficult to allow more than one at a time, which would give a better player feel. However that would generate more code, not less, so park that thought.

The space bar could be used to generate a forward firing fireball. However it’s hard to target accurately without reducing the player turn rate. There is also a problem with Y-targeting because the ground is variable height. I could make the fireballs follow the ground contour. This isn’t hard as the game already works out the ground height under the fireball to detect terrain collisions. This would need modifying to override fireball height. It would also need to override the height of other players fireballs as the game linearly interpolates remote object positions. It may no longer be required to synchronise object Y coordinates across the network at all, which is a wider reaching change, although it probably wouldn’t save many bytes as that code is mostly generic in the way it handles the 3 axes.

Definitely a retrograde step, but it might save 50 to 100 bytes.

#8

Almost there now. Had to remove the display of player names to fit within 4K.

Currently 100 bytes over, but the AI code is yet to be optimised and the overlay can be rewritten without library calls, so it looks likely to get there!

#9

looks good, but it’s really difficult to dodge the other mages fireballs (?) without strafing . Any chances of strafing ?

edit : ops, should have read the description :slight_smile:

#10

Actually, it’s a bit too easy with strafing. I can wipe out the enemies by strafing left and right firing continually as the enemies don’t compensate for your lateral movement when they are targeting. While the maths for targeting lead isn’t that hard, the need to reduce byte count may mean that strafing might have to come out again to preserve game balance. :-\

#11

Like 1 FPS on Mac, unfortunately. :frowning:

#12

Thanks for your comment. It’s slow on my Powerbook A4 - About 5fps. On my PC I get about 30fps. My Mac is old which accounts for some of it. Which Mac and Java version do you have?

I’ve just changed the overlay so it’s generated by bit-bashing rather than OS calls, which might help a bit.
Probably not much through. I’ll go and try my current version on the Powerbook.

I can fiddle with the depth granularity a bit, but overall, I this is just a very CPU intensive programme.

Edit: I tried making the screen quarter size and got about a factor of 3 speed increase. At this point the AI starts to make an appreciable dent in the timing. I was getting about 14fps on the powerbook and 100fps on the PC. I tried using createCompatible Image, but didn’t gain anything significant. The processor load goes up by a factor of two, when the screen gets busy. However I’m already using two stages of object culling.

Still 100 bytes over the limit - changing the overlay coding didn’t seem to help much. The code needs a tidy up, but getting those bytes back is looking increasingly difficult. At least the program is essentially all there now.

#13

I’m having no lag at all.

However, as I play, I can only see if im moving, and even then the screen is constantly flashing black, if I stop it just stays black until I move again.

#14

That’s because the app draws your own model, hence you are watching from within his head.

Just walk quickly to some point, turn around, see yourself catch up, and see the screen go black.

#15

That’s odd. That happened with my very early versions if you opened two windows for multiplayer on the same machine, due to a bug revolving around shared static variables. This resulted in both players being slaved to each other. It might be worth forcing a refresh and/or clearing the cache. If it’s still doing it, then let me know which browser, OS etc. and I’ll see if I can nail it.

Edit: Something just occurred to me. The game receives network packets from all the players (including yourself) but disgards any with the same IP address (& process ID) as the local machine. This might not work properly on machines with more than one IP address, or maybe there’s some translation issue between localhost IP address and the real IP address. I made some assumptions in this area :persecutioncomplex:

Edit2: I think the problem definitely relates to loopback. If I change my code to use InetAddress.isLoopBackAddress(), it exhibits the same problem you are seeing. It looks like there is some inconsistancy in java implementation in this area,.

#16

I have a workaround to the loopback problem. Currently using both IP address and a processID fabricated from applet start up time, to determine which incoming packets are loopbacks and should be ignored. Could just use the processID and rely on it being very unlikely that two are the same. Alternatively I could store the IP address in the body of the message. That would avoid issues with multi-homed machines. I’ll thing about it more tommorow. Probably just rely on the processID being different, even though it isn’t a robust solution

I have uploaded a version that ignores the loopback address and just uses processID. See if that works :slight_smile:

#17

Still laggy on the best Mac laptop you can buy right now with that latest Java version. :frowning: I think it’s safe to say Mac applets are borked right now.

#18

It works fine now. Thanks.

#19

I had hoped that performance would be better on the new intel macs (:sigh:). This game bit-bashes the entire scene and then drawImage()'s the result to the graphics context, which doesn’t play to the mac’s strengths. Doing more in Java2D tends to level the playing field as most macs have reasonable graphics cards. I’ll look at something a bit more mac friendly for my second entry.

Great stuff. I’ll go with just using processID. It’ll save a few bytes as well.

#20

Release Candidate posted. 4092 bytes

I have taken strafing out, but probably could put it back if I removed cursor control.
However I think it’s too easy with strafing, so I’ll see how the current version goes.