#project_z

Interactables are near completion: A tile position is used to define the interactable location, with up to 4 activation positions. I use this to make some interactables activables only from ‘down’ (below). Example: A computer, usable only when in front.

Later, I could be interested in various interactables utilisation, regarding the direction they’re accessed. Example: The same computer, usable from front, unscrew and open from back.

I used a provided rectangles intersection method to check for overlap between the player “interactable zone” and a given interactable hotzone. I also reduced the surface of the hotzones, because for 1 pixel worth, the overlapping was true, allowing to interact even when not really in front of the interactable.

As a topdown view, the rectangle representing the player bounds was centered, when it should be near the feet.

I still have to display a nice contextual bubble, for the player to know how to interact with the interactable (with which key).

Currently trying to implement a system for interactable object: The main idea is to declare interactable object and the mere position the player must be to interact with the object.

I’m not 100% sure right now if I only want interactables, triggerables, or if the activation hotzone must touch the object. May be later, I’ll prefer remote hotzone for a given object, but I don’t see why right now.

Anyway, an empty pixel serve gracefully as a debug sprite that is not ugly AF: You can stretch it and it’s white, so I can play with opacity (and may be color ?).

The overlap method doesn’t trigger anything yet (and that is strange), but I will implement a temporary overlap filler for the time being.

Once the interactable system is ok, I will have a nice contextual pop-up to indicate what action is possible, and perform said action. Mainly, display a dialogue box. 

And no, right now, dialogue boxes are not a thing, but next on my todo list.

After some further tests with the camera, it’s still buggy, so I will use a classic following camera.

So on, I tend to go further from the classic Zelda Link’s Awakening gameboy style, mainly because a colleague asked me if it was what I really wanted. And I wasn’t sure about it: Do I really want my game to be so close to Zelda gameboy ?

I will go my own way, I think, but still keep a simple and mostly cute look.

On another subject, code refactoring, a fully working script to transform font in retro font (soon to be a plugin for Phaser).

And again, this difficulty: Keep It Simple Stupid. Don’t reinvent the wheel, or moreso, don’t make a fully featured system for a game when you know what you need.

Do what you need, not all that can be done.

So I did fix the camera behaviour to be closer to the Zelda Link’s Awakening ones.

Really satisfying to see the camera quickly panning as you go through the edge of the screen.

Next : I dunno yet. Select menu ? Fonts ? HUD ? Triggers ? Teleporters ?

Still working on the “weird” camera, that is, when you walk on the edge of a screen, everything freeze while the camera pan in the direction you were going, and then, eveerything resume.

Using Phaser, it’s a bit hard to make, but I will work this out this week (I hope).

So far so good, is going well. In fact, I first got the worst idea starting a retro-zelda-gameboy like engine.

So I started a raw version, using Phaser, and it looks good. I’ve got a tileset, a tilemap, a movable sprite for the player.

All the graphics are placeholders shamelessly ripped from Zelda Link’s Awakening (obviously), but I will replaces those with original creations.

I do like the style though, being limited by the resolution, it goes straight to the point.

What’s with the title ?

Well, I don’t have any title yet. It’s quite strange for me, as I tend to have one pretty early on. It drive the thematic I want to use, the ambiance I want to show, and the universe the game’s in.

So it’s project Z, until I find something better.

What is it about ?

Small steps, good steps. Smooth player (placeholder) movement, grid layout for debug purpose, and gameplay specs on paper.

On paper ?

Yep, because sometimes, if you write it down, you somehow lock it, instead of keeping semi random concept roaming between your ears.

Will work on a placeholder tileset, characters sprites, props, etc, and gameplay flow. With a lot of placeholders.