next »

[ANtY]

Great animations, movement system and physics! 

[Relix]

It can get a bit glitchy on the inner corners of rooms.

...yeah, maybe.

I've always made my cameras act like that tho, hit level/room wall on x-axis, stop on x-axis and same deal for y-axis. The camera can still follow the player up/down/left/right. If both axis are blocked, it just stops until the player has moved far enough from the corner for the camera to start following again.

And say you've got a T-shaped room, and you drop down the centre bit, you don't want the camera to suddenly snap into the vertical section and change direction abruptly. You'd want to detect the junction, smoothly approach it, come to a complete stop, and then start travelling in the new direction.

This part I didn't understand. Why the camera would suddenly snap..?




Maybe I should stop posting <<

[SolarLune]

I think the camera would snap because the target, Trixie, would be far enough down where the camera would go down at, say, 15 pixels a frame, but the level border's in the way because it hasn't followed the target to the center area yet.

[Ishi]

You want to avoid this major snapping situation, which would happen if you just pick the closest 'legal' camera position to the player: (green area is the visible portion of the world, light blue is the room shape)



Also a snapping of the velocity, where it immediately changes direction, will be really disorienting:



So ideally you need to get the camera to smoothly change directions at the corners. Which is doable, but might get messy with rooms of any size.



And then if you overshoot at a t-junction, it starts getting silly. Handling this nicely would be a nightmare, unless you start partially locking the camera at the junction until you know for sure which way the player is going. (Black dot is the player)

Maybe I should stop posting <<

Never! All contributions are great. Now I've been inspired to clarify the problem situations.

 

[SolarLune]

@Ishi - The partial locking idea sounds good. That's how some games do it - they lock at designated 'single-screen rooms' until the Player edges toward one of the screen edges, at which point the view follows them.

[Ishi]

@Ishi - The partial locking idea sounds good. That's how some games do it - they lock at designated 'single-screen rooms' until the Player edges toward one of the screen edges, at which point the view follows them.

It almost may as well just be a separate room at that point, though. Although that depends how your room-to-room transition behaves - smooth movement, screen flip, pause + scroll. I can see myself going with a solution where the camera largely ignores the room layout. They'd still be useful for selecting music or whatever.

[Relix]

Also a snapping of the velocity, where it immediately changes direction, will be really disorienting:

Yeah this's the way my cameras usually act, but as only like 10 people have played/tested my games, nobody has yet complained about it.

Sometimes it goes like this

but that depends how slow the player is going.

And then if you overshoot at a t-junction, it starts getting silly. Handling this nicely would be a nightmare, unless you start partially locking the camera at the junction until you know for sure which way the player is going. (Black dot is the player)

Ah yeah. Iirc, Metroid Fusion had some places like that, maybe check there how the camera acts?

And camera locks aren't that good solution, closest example I can think is the Underside, and it was messy at some places.

[baconman]

I'm just curious as to why you'd need an L-shaped or T-shaped room that ISN'T strictly for the sake of level design (IE: could functionally be a rectangle with a blocked off section). Even if a cove of it were some secret area, that could be easily disguised by foreground effects and simply bordered to the outside of the room.

Also, a bit of level design could help you prevent that camera-snapping problem. Say there's a T-intersection like the one in that last quote there... you could only progress upwards from within the horizontal range where the camera wouldn't scroll past. Then if you wanted to add side-to-side action past that point (where the camera's blocked off), go right ahead.

[Ishi]

Well you can certainly design around it. It'd be nice to have a system that would cope with anything though. Like I say though, I've not given it much thought. Just drew some random rooms out. Got to get all the mechanics in place before I can decide what works best in terms of world layout.

[MaloEspada]

i'm actually sorta confused about all you guys are talking about

why not draw a room in a rectangle? wouldn't that solve... everything?

[Noel Berry]

Yeah, I'm somewhat confused as well. Why can't you just let it go into the dark blue areas slightly? Let the camera follow the player completely naturally, and allow it to overlap bits of the darker blue (outside the world bounds). Out there you could just render sky, or more walls, or whatever...

Then just make the Camera follow the played based on how far away it is, like

Code:

camera.x += ((player.x - screen.width / 2) - camera.x) / 10;

If you're in a hallway or something then, generally speaking, the camera should be contained reasonably well just based on the players movements.


Also, this project is looking really cool!

[Ishi]

i'm actually sorta confused about all you guys are talking about

why not draw a room in a rectangle? wouldn't that solve... everything?

The rooms I'm talking about are bigger than the screen, and not rectangular so you need to find a way for the camera to move around them smoothly, if you don't want the camera to show anything outside the room.

Yeah, I'm somewhat confused as well. Why can't you just let it go into the dark blue areas slightly? Let the camera follow the player completely naturally, and allow it to overlap bits of the darker blue (outside the world bounds). Out there you could just render sky, or more walls, or whatever...

Well that's an option too of course, and one I've mentioned briefly. It's a more interesting problem if you don't want the camera to go outside of the room, though It's just a technical discussion really, and one that probably shouldn't take up too much more of this thread. I'll get back to posting actual progress this week.

[Ishi]

Update

I did a tiny bit of coding on the editor.

Started tests in cutscene art. Not quite sure what that background is meant to be.



Edit - colours are pending, by the way. Haven't really edited them yet, they're just colours I picked from the muddy downscaled drawing.

[Ishi]

Update

Improved the cutscene art experiment:



Added really basic tile placement to the editor:



Along with a sort of minimap display in the room editor, so it'll be easier to find stuff.

[Ishi]

Update

Continued the cutscene art test.



Pretty happy with it now, apart from that the antialiasing is inconsistent currently (some is, some isn't). Will have to wait until I've got some more final in-game art done to see if the styles fit together well enough, as this uses a fair few colours. I think it should be ok though.

This image has taken a fair bit of work so far, but I don't think it's unrealistic to do a game's worth of them. I don't forsee the game having a *massive* number of cutscenes.

In coding news, I stole a Bresenham line algorithm from the internet and used it in the editor, so it still draws solid lines even if I move the mouse quickly.