Protal

Pizza Time's picture

I have a semi-functional Portal-alike working but I have no idea on how to stop portals spawning too far into walls causing the player to get stuck and even clip directly through them. I think it's directly related to animation hot-spots and action points or some jazz. Actually, I'm pretty sure of it but a second opinion is always nice to have so I'm tossing it up for anyone to have a look at since I'd have a far easier time showing what I did rather than explaining. I was going to unveil it as a surprise project but noone likes surprises that don't work so it put an end to that plan. Buttons one and two fire different coloured portals and there's platform controls but no jumping and I haven't set up more than four directions so you can only fire portals in those directions. You might not want to fire a portal into another portal since it causes you to get stuck.

Hilariously, you can set up portals so that you fall into one and infinitely pop out the other if they are the correct distance apart and you keep walking in one direction. Just like in the game!

AttachmentSize
protal.zip4.02 KB

I'm no expert, but here's my

I'm no expert, but here's my two cents: white border objects just inside the walls that the player just passes over as if they're not there. Because they're white, they can't be seen. However, when shots hit them, they became portals as if they actually hit the walls instead. As I said, I'm no expert so I don't know how well it'd work.

captaincabinets's picture

One method is kind of brute

One method is kind of brute force but it would work (I think). Have a blue and orange emitter for each direction (so 8 emitters total for 4 directions). On each set of emitters (i would suggest labelling them nicely), put the action point on the edge of the emitter opposite to where it would hit, ie:

(e in the name stands for east).

This would hopefully make the portal spawn away from the wall every time.

then when you test for the fire buttons being pressed, also test the direction of the player and shoot out the corresponding emitter.

captaincabinets's picture

by the way, your game is a

by the way, your game is a totally cool idea. I mean, to implement it in KnP that is.

PS. I've always been a huge fan of your sprite work.
PPS. For some reason when I wrote that top sentence I wanted to write rhinoceros instead of cool, and I had sudden wild ideas about it being the new hip word that all the cool kids would start using instead of saying awesome and whizz-bang and whatever else they say. Just thought I'd share that true story with you.

Pizza Time's picture

I totally should have made this a blog post

Yeah it's pretty rhinoceros or it will be when I brute force it (hah!) as you suggested.

I managed to get the portals to actually change direction so now they don't stand upright all the time so it fits against the ceiling and floor better. I think actually I might try and get the portals to spawn into walls a bit so it looks as if it's opening directly against the wall. I'll have to put jumping in so I'll probably add mouse aiming which goes against the minimal four directions, two action buttons 8-bitness of it all unless I just have one of the buttons handle jumping and have two keys specifically set for portal creation. This is why I wish that KnP had support for 3 button joysticks. Oh well, let joy2key handle that.

Key to getting those portals to align correctly was having a portal object created rather than having the position for two existing portals jump to where the emitter hits the wall and used values to destroy existing portals so that there won't be more than one of each type on screen. But even then there are times (specifically if you have spawned into a wall) when you can spawn multiple portals of one type. But these can be cleared by shooting a fresh one after getting out of the wall.

I've attached a new version which needs hella tweaks but that's for the next release isn't it.

AttachmentSize
protal_2.zip4.62 KB
SpindleyQ's picture

(No subject)

captaincabinets's picture

Yes. Oh god yes. I love you.

Yes. Oh god yes. I love you.

kirkjerk's picture

They call me the

They call me the Rhyme-nocerous / 'cause my rhymes are bottomless / ... / ...

Aw crap, that's the Hiphopapotamus' line anyway.

I have no idea if it will make any kind of splash in the wider meme pool, but I can not think of a better superlative for a Glorious Trainwreck related effort that "Rhinoceros"

Except that it's a damn hard word to spell.

captaincabinets's picture

I just noticed this comment.

I just noticed this comment. The flight of the conchords are tops. Vouz le fa fa fa fa yeah

kirkjerk's picture

I can't set this up to see

I can't set this up to see 'til this evening, but I am so overcome with a sense of "damn it why didn't I think of that???" I can barely type. Bravo!

Pizza Time's picture

Breakthrough, I figured out

Breakthrough, I figured out what was causing my portals to spawn unevenly. It was down to how KnP handles collisions with background objects. I took away the emitters ability to spawn portals and found that sometimes they disappear when hitting the wall and sometimes they disappear whilst inside the wall. I think it's due to the speed of the objects when they are shot, they are moving faster than KnP can process collisions. Maybe it's also down to the emitters going into their disappearing animation when they are destroyed then going into a different, one frame animation before being destroyed but I needed that one frame animation since shot objects just don't seem to want to disappear when the "disappear" animation is over. KnP is really retarded at times with animations and it doesn't help how this version refuses to register me setting the animation speeds for any object I created to less than maximum speed on this PC. I can't even change the colour depth from 256 colours since I run my desktop in 32-bit colour instead of 24-bit colour. Frustrating.

I tried another idea of mine, changing the portal graphics to new ones in hope that that would fix things but due to the above problem regarding collisions no dice (I should point out now that I tried that after changing the graphics, which makes my post look out of order). So I took on BiggerJ's idea of having objects in the wall which turn into portals when shot but modified it so that portals are created from their action points instead. This well and truly solved the problem of portal spawning! I had to change around the action points because I had them wrong (solved the player clipping into walls in one or more of the earlier versions, most of which were private builds) and there was a little hiccup with the player jumping into a portal and then popping back out because gravity made him fall straight back into it, which setting it to bounce the player when colliding in the event editor. Now I am having problems with the player clipping into the ceiling when appearing from a ceiling portal, I think it's action point troubles again though it's probably related to bouncing, maybe I should add more events that specifically deal with separate directions though that's more convoluted than it should be. Anyone is welcome to try to fix this and upload the results.

The new version which is attached has three different rooms which have all my ideas covered in this post. The black bars in the third room are supposed to be invisible, I recommend that you imagine that they aren't there to increase immersion in the experiment. I'm really interested in people's solutions and ideas on how to get this from partially working to fully working so that things like energy globes and companion cubes can be added later. And then maybe after it's well and truly done I can start on something else that hasn't been attempted in KnP yet.

EDIT: I should probably point out that now Z and X shoot portal emitters and that button 1 is set to C since I went with one of my earlier comments about using 3 buttons instead of just two, which means that I can say no to mouse aiming and still make it feel like an 8-bit game.

EDIT #2: Okay, now the player doesn't get stuck in the ceiling, and I have no idea how I managed it. I was messing around with the various hot spots and action points for the objects on the screen and then I did something else and poof, it worked. Now let's see if I can't fix up the few times you can shoot an emitter between those black bars causing no portal to appear.

AttachmentSize
protal_3.zip8.05 KB
Pizza Time's picture

Font test

This is just to get an idea on what people would like to see for the lettering on the title screen. I can't really decide between the two following images so I'm tossing them out there for a second opinion.

kirkjerk's picture

The second, mostly because I

The second, mostly because I don't think the "r" in the first one works.

SpindleyQ's picture

The first one is way better;

The first one is way better; I don't like the gaps in the letters of the second one.

kirkjerk's picture

SO CLEVER AND YET SO WRONG

SO CLEVER AND YET SO WRONG

kirkjerk's picture

minimalist fonts

Actually, the jerk-ness of my previous comment, or maybe the point of your comment, reminded me of a font I made for the long lost and lament pixeltime website:

kirkjerk's picture

tried it

So I tried it, cheating the q and maybe something else a bit:

eh, maybe not what you're looking for, especially with my cheaty "e". Still kind of fun.

SpindleyQ's picture

I totally knew you were

I totally knew you were going to bust that font out.

kirkjerk's picture

I - It's - Uh - Err- I

I - It's - Uh - Err- I --
Damn it, am I that predictable? Or are you just a kirkjerk groupy?
Or a little from column A, a little from column B....
I think of my pixeltime page as languishing in obscurity, and lament
the loss of pixeltime itself, so that was a good prediction on your part...

Pizza Time's picture

I have started on making the

I have started on making the levels. Only one so far, which is a really easy one that introduces the portal device. I'm still getting instances where the emitter hits two collision boxes, spawning two portals next to each other. It's most notable when you jump and fire, shooting a portal diagonally which is something I've not been able to manage to get the player to do from a standing position.

For the title screen I am using the second font example I posted just until I get more opinions on it. I was thinking of getting rid of "training" since the entire game will end up training the player as they go along. It will make it look a tad bare though but I can just past that off as minimalism.

AttachmentSize
protal_4.zip17.6 KB
Pizza Time's picture

New version, for a while. I

New version, for a while. I want to get my other game that I am working on finished before I attempt to do any more. So I am tossing it up for discussion and practical application of ideas.

I redid the sprites for the emitters and added opening animations to the portals so it looks like the emitters open up into portals rather than them just disappearing and the portals popping out of thin air. Except it looks a bit jarring with how I have the collision detection set up, which really gets on my tits since if the first method I tried worked it would have made me really really happy since it's the best way for it to work but KnP likes to get in the way of that. Fie!

Maybe if instead of having the player shoot an emitter it could be set up to spawn one at the player's action point and then subtract from the x or y coordinate of the emitter itself so it looks like it's being shot. Then maybe things will sort themselves out. Or would that just be the same as using the shoot action? Someone try it and see if my theory works.

I used kirkjerk's super low resolution font, got rid of "training" and added an "about" option which will be used for some 386-tastic Apogee-style help screens and I added another room which has not been tested at all as well as another implemented idea in regards to collision detection (objects that are used as separators between the black bars). Have fun (you guys).

AttachmentSize
protal_5.zip26.45 KB
captaincabinets's picture

instead of spawning then

instead of spawning then subtracting from x/y could you not give the emitters all bouncy ball movement, and when spawning them from the player set the direction? I have always found the "shoot object" action problematic with collision detection, speed, ra ra ra, so maybe it could help things out. I will investigate this when I have the time and report back.