next »

http://openwar.bartvanheukelom.nl/demo2/
http://openwarrts.svn.sourceforge.net/viewvc/*checkout*/openwarrts/demo2/export/
The game is now standalone, no longer an applet, so you can run it by downloading from SVN

I see (perhaps appropriately) a blank page with "top down RPG" one the top 

Anyways I'll fully admit that I haven't done nearly enough with this commitment.

yes, that was indeed the full applet at the time you visited

now you can move a ball with the WASD keys and the mouse
(click the applet to activate key input)

Ok, just so you're aware that applet isn't working in IE.  Compatability is a big issue for us, although fortunately it's pretty darned easy to download firefox (the "real solution", as my prof put it last semester when people with IE8 couldn't sign up for the mailing list )

May I presume the source code is in the Wiki?

I have applied for SVN hosting on Sourceforge, which should be approved in about 2 days

The applet not working might have to do something with the html code I used, or more likely that you don't have the newest Java plugin (6) or don't allow applets because of security

Can somebody explain me what's the WASD keys 

but I guess you have an AZERTY keyboard so you don't have them

Oh... yep I have an AZERTY
What can I do? Use ZQSD or WASD? Or nothing for the moment...

use WASD

i've update the applet. it now uses the very early beginnings of the engine. it also has the player as a rotated sprite

There I was just going to ask for an arrow :-P

How do you guys think the movement system feels?  I think that's a great, but underused, way to do top-down gameplay.

Oh... yep I have an AZERTY
What can I do? Use ZQSD or WASD? Or nothing for the moment...

We'll definitely need to support other types of keyboards.  It shouldn't be too hard to put in a toggle for AZERTY equivilent keys right now, but in the finished product we should definitely have a control menu to let players set them to whatever they want.

it feels ok, a bit weird when walking around. i suspect it will come quite in handy in battle though

We'll definitely need to support other types of keyboards.  It shouldn't be too hard to put in a toggle for AZERTY equivilent keys right now, but in the finished product we should definitely have a control menu to let players set them to whatever they want.

well of course

My one complaint with what's implemented right now is that you actually run faster if you move in a diagonal.  We need to control absolute speed, we cannot simply split it into the two axis and treat them independently.

As it is, we have five types of motion; forward, forward-diagonal, strafe, backwards-diagonal, backwards.  The code should be made so we only need to adjust a constant to change the absolute speeds of any of these five modes.

[Vector2]

I've uploaded an updated version, which now has a class Vector2 which helps with this kind of stuff, and has made fixing the movement speed a very easy thing

Update: it now has double buffering for drawing

Great work; not as choppy as before, either.


If you could add a quick fix so he stops moving when he gets very close to the cursor, that'd be great.

It had that before, but that became a bit more complicated with the new movement. I'll be sure to add it later though

In the final product, the map will probably scroll around the character, with the character always in the middle, so it won't be as important then.  However, we still don't want to see a joker turning his sprite into a windmill :-P

[long]

By the way, the frame number you see at the top-left is stored in a long. I did this so the game can run for a long time, but apparently it's a bit too much. With a game speed of 60 fps, the game would be able to run for....millions of years

So in the next version I'll turn it back into an int

Well, each bit you add doubles the maximum value it can hold.  A long has double the bits of an int (if I remember correctly), so that's equivalent squaring the number of frames it could run for.  If it ran for 60 frames (1 second...) before, it would now run for 3600 frames (... one minute!) after.  Now, this exponential growth, not linear, so if it ran for 3600 frames before (one minute), it now runs for 12960000 frames (sixty hours!).  That's explosive growth, huh?

wait...huh..what? no...the game runs at 60 fps, whatever type you store the current frame in 
the variable i'm talking about holds the number of frames that have passed

That's what I'm talking about; the maximum value it can hold doubles every time you add a bit; if you double the number of bits, you square the value it can hold.  Just remarking on exponential growth; you can get some obscene values very quickly from it.  That's actually very big in efficiency of algorithms.

I know that, but you said

If it ran for 60 frames (1 second...) before, it would now run for 3600 frames (... one minute!)

which implied that the type of variable you store in it would affect the game speed

I know that, but you said

If it ran for 60 frames (1 second...) before, it would now run for 3600 frames (... one minute!)

which implied that the type of variable you store in it would affect the game speed

The statement means that if the maximum number of frames it could remember was 60 (one second of time to reach the maximum) before you doubled the memory size of the variable, then the maximum number after the double would have been 3600 frames (it would take one minute to reach this at 60 fps).

oh, that "ran"

If you could add a quick fix so he stops moving when he gets very close to the cursor, that'd be great.

done.

the JAR file (http://openwar.bartvanheukelom.nl/demo2/topdownrpg.jar) now also contains the source code (open it with WinRAR)

and the Javadoc documentation can be found here.

I got around to reading through the code (UML diagram would have been nice, but I could roughly see how such a small program interacted, anyways).  It was very well commented, so good job.

[Sprite]

I've made lots of changes today:
- the game runs in window now
- i've added a Sprite class, which holds (surprise) a sprite, possibly with animation
- the Player is much simpler, a lot of functionality has been moved to Sprite and GameObject

And many changes again:
- a bouncing kirby in the screen
- managers to load sprites (including from a batch file) and tilesets
- more. check it out yourself to see

Some of the updates:
- new features to draw scaled and alpha images
- hardware accelerated graphics
- new class Box, which has a Vector2 size and Vector2 position, and helper methods
- a tile map for background

from now on i'll just enter comments in the SVN log which you can see here:
http://openwarrts.svn.sourceforge.net/viewvc/openwarrts/?view=log