next »

[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.

[Relix]

Looking good, just one funny (or not funny) thing I noticed; modern cell phones don't look like phones at all, and the palette gives me sort of 80's feel, maybe a bit older looking phone would fit better?

I'd also like to know how did you make those clouds, circle tool..?

[antymattar]

Om nom nom nom!

[Ishi]

Looking good, just one funny (or not funny) thing I noticed; modern cell phones don't look like phones at all, and the palette gives me sort of 80's feel, maybe a bit older looking phone would fit better?

I'd also like to know how did you make those clouds, circle tool..?

The game's set in modern day, but a chunky satellite phone or something might suit it better, yeah. Suits the remote location / exploration theme. Ta

The clouds were just hand-drawn.

[Relix]

The clouds were just hand-drawn.

I was hoping that you had some neat cloud drawing trick to teach.

[Ishi]

I was hoping that you had some neat cloud drawing trick to teach.

Hmm well I think perfect circles would be too neat. I just draw some blobby shapes, and then add highlights where I imagine the light would hit them if they were 3D. I do it all pretty roughly first and then go over it all very close-up to smooth it all out.

[Ishi]

Update

Super-productive saturday!

Pretty much finished the cutscene thing I think - certainly I should probably avoid tweaking it any further.



Added brush size to the editor.

Added saving and loading to the editor.

Added the ability to switch from editor to game, and made the game collision work against the proper level data instead of the hard-coded tiles.



It's pretty awesome now I can easily test different scenery configurations and stuff. Now I can get back to player collision and movement, which needs a lot of work and anims.

[Ishi]

Update

I created a general system for defining where special collision points will be automatically placed. For example, the points on the edges of ledges that Trixie can hang from. (These were hardcoded before, but are now handled by this system)

Code:

<CollisionPoints>
	<CollisionPoint Name="Hang"
					Flag="1"
					>
		<Row Data="ooo"/>
		<Row Data="ooX"/>
		<Row Data="oo?"/>
		<Row Data="oo?"/>
	</CollisionPoint>

	<CollisionPoint Name="HangAndClimb"
					Flag="2"
					>
		<Row Data="ooo"/>
		<Row Data="ooo"/>
		<Row Data="ooX"/>
		<Row Data="oo?"/>
		<Row Data="oo?"/>
	</CollisionPoint>

	<CollisionPoint Name="LedgeFlip"
					Flag="4"
					>
		<Row Data="?ooo?"/>
		<Row Data="ooooo"/>
		<Row Data="ooooo"/>
		<Row Data="ooXxx"/>
		<Row Data="oo???"/>
	</CollisionPoint>
</CollisionPoints>

x is a solid tile, o is an empty tile, ? is any tile, and capital X is the tile that the collision point will be placed on. So, for example, Hang is the edge of any ledge that Trixie can hang from. HangAndClimb is more specific - it's a ledge that also has enough room to climb to a standing position. LedgeFlip defines the places where Trixie can do the somersault over the edge of the ledge - needs lots more space.

I also added some more actions today such as crawling off a ledge to hang from it.

[baconman]

Smells like level design mastermind in here.

[Ishi]

Update

Added some helper abilities, for example Trixie now crawls into a tunnel automatically if the player is pressing forwards.

Technical Fun
I'll add technical bits in my updates occasionally if I think it might be interesting.

Here's some of the XML that defines Trixie's animations.

Code:

<Strip name="Idle" filename="Idle.png"/>

<Strip name="Turn"
	   filename="Turn.png"
	   cels="3"
	   length="0.06">
</Strip>

<Strip name="Walk"
	   filename="Walk.png"
	   cels="6"
	   length="0.1"
	   dx="2"
	   initialCel="1">
	<Cel index="1" dx="1"/>
	<Cel index="4" dx="1"/>
</Strip>

Idle is a single frame so doesn't need any details.

Turn is a straightforward animation - 3 cels (frames), 0.06 seconds each.

The Walk animation also includes movement info (dx is change in X position). So Trixie moves forwards 2 pixels per animation cel, except on cels 1 and 4 where she moves only 1 pixel. This ensures movement of the sprite is exactly in sync with the animation, so her feet don't slide around on the floor.

In the same way that I've specified dx for specific cels, it's also possible to specify animation timings per cel, so if necessary I can tweak anims quite precisely (though I haven't needed it yet).

It looks a bit long-winded, but most animations don't use cel-specific details or have movement info, so it's quick enough to add new animations to the file.

[Ishi]

Update

Added a couple more animations to make things flow better.

I put a build of the game on my laptop ready to take to the Midlands Indies meetup tomorrow. I thought I'd get into the spirit of this open development and put together a video of a playthrough of that build! In the past I've been a bit reluctant to show too much of my games off, as personally I like to see as little as possible of any game I'd like to play.



It shows the majority of Trixie's abilities so far. The camera's just a quick placeholder one, so it's pretty shonky.

[MaloEspada]

this seems like such a pacifist game. maybe because you haven't drawn the enemies yet? though i like it the way it is now. reminds me a lot of knytt.

i take it these abilities are given to the player as default? it would be weird to get a "ledge grab" upgrade (hello, metroid zero mission!)