Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Levelgeneration

0 (0%)

World richness

0 (0%)

World Interaction

0 (0%)

Game-Story

0 (0%)

Animation

0 (0%)

Sound

0 (0%)

Game-Mechanics

0 (0%)

Total Members Voted: 0

Voting closed: September 17, 2011, 12:37:34 pm

[Siquo]

New updatey: http://nam.siquo.net/webgames/lets-dev/

As you can see the placement-of-the-person isn't yet according to where it should be, but basic movement (just WESD now) and "thou shalt not walk here"-collision works for walls.
I ran into another problem: It's very hard to make "layers" in java applets. This means that drawing first the terrain and then the objects will always drap the object (eg: character) on top of the terrain, even though it should be obscured due to the nature of isometric terrain. Damn.


Next step: mouse aiming and a lasersword/pick/something.

[mr. macduggan]

Does it play well on WASD? My hands find the WESD format really cramped, and I personally think that WASD would be ok, as long as it had the same diagonal movement. You could get used to it pretty quick. (of course, that's just my opinion)

[Siquo]

Yeah, I'm gonna make a WASD as well, but that one will "follow the mouse", so pushing A will move you forward in the direction of the mouse, etc.

For that I first need to get that mouse-aim working.

[mr. macduggan]

Cool. Sounds wonderful Siquo! 

[Rose]

you draw the tiles and everything on them row by row.

then you will not worry about layering.

[Siquo]

you draw the tiles and everything on them row by row.

then you will not worry about layering.

Correct, but that means either registering all objects with the current tile (superflous administration, yech, although come to think of it that would make collision detection of object vs object a lot faster... hmm), or looping over all objects when drawing a tile to see which is on that one (which is VERY inefficient).

This morning in the shower I realised that writing my own layering.... layer... shouldn't be that hard. So that's what I'm gonna do. That's also going to come in handy when I'm going to implement more GUI-stuff.

[Rose]

registering object by tile isn't actually that bad. since tiles can be accessed directly by coordinates, you just have vector in the tile that holds pointers to actors, and whenever you move an actor, you change what tile it's in.

[Siquo]

registering object by tile isn't actually that bad. since tiles can be accessed directly by coordinates, you just have vector in the tile that holds pointers to actors, and whenever you move an actor, you change what tile it's in.

True, but still that's going to happen pretty often. The tiles are small and the characters move a lot, so there'll be a lot of registering/deregistering. Perhaps I can do both, as this will greatly improve collision-detection, and I need the layered layout anyway (and it's good practice).

[Rose]

eh, changing a single variable on a tile is an operation that takes nearly no time at all. You just have to make sure the guys are also stored properly in a dedicated list, so you don't have to look through the tiles when you want to do something to all of them.

[Biag]

My current project registers the actors to the tile they're standing on, and I can run at least fifty actors at the same time without significant slowdown. Probably more. This is on Python, btw, which is muuuuuch slower than Java IIRC.

[Siquo]

eh, changing a single variable on a tile is an operation that takes nearly no time at all. You just have to make sure the guys are also stored properly in a dedicated list, so you don't have to look through the tiles when you want to do something to all of them.

Yeah, it's less bad than I thought. For every crossing I need to deleteFromPreviousTile and addToNextTile, both a fairly small list operation. I was just worried about things like LAZ0RZ that move quickly-but-not-instantly. I think it'll be okay, this isn't going to be a bullethell game anyway.

I'll take your advice and thanks

[Soadreqm]

FR: Make it a bullet hell game. Every now and then, break the mining with a SURPRISING GENRE SHIFT to some laser dodging. Dance to the hitbox tango!

[Virex]

eh, changing a single variable on a tile is an operation that takes nearly no time at all. You just have to make sure the guys are also stored properly in a dedicated list, so you don't have to look through the tiles when you want to do something to all of them.

Yeah, it's less bad than I thought. For every crossing I need to deleteFromPreviousTile and addToNextTile, both a fairly small list operation. I was just worried about things like LAZ0RZ that move quickly-but-not-instantly. I think it'll be okay, this isn't going to be a bullethell game anyway.

I'll take your advice and thanks

You're working with Java anyway, it's desinged for fast memory operations. Besides, collision checking in other ways is O(m log n) if you're using a quadtree (m the amount of objects that move, n the total amount of objects), using an array is only O(n), which is a big gain if you've got a lot of objects.

[Siquo]

FR: Make it a bullet hell game. Every now and then, break the mining with a SURPRISING GENRE SHIFT to some laser dodging. Dance to the hitbox tango!

.... ARGH!

[Soadreqm]

.... ARGH!

Oh, right, you had that blood oath about implementing everything, no matter how ridiculous. Sorry. I kinda forgot for a moment there.

Well, you'd effectively be making TWO games with completely different gameplay and bundling them into one, which is certainly an extra programming challenge, which is kind of what you were looking for here. I am so very helpful.