next »

[diegzumillo]

You're all too kind

I love this tech so much. I really want to try my hand at making levels with it someday... not to add pressure on you to make end-user editor tools 

I can't even make decent developer editor tools!

Given how burnt out I am with this game, a level editor might actually be a good investment of time. You know, to make up for the inevitably short campaign. "It's not just a super short game, you can also make levels and share them."

[JobLeonard]

This looks so siiiiick!

Also, I've been binging the Ridiculously Huge Numbers playlist and learned a thing or two about the Fast-Growing Hierarchy and suddenly I'm like "hmm, I wonder if you could do messed up stuff in terms of growing/shrinking with recursion there"

Although you probably don't want the actual functions discussed in the Fast-Growing Hierarchy, since you can't even write those numbers down, hahaha

[Zorg]

Thank you for the updates! Great stuff.



I was asking myself:
- Do you have a strategy to disguise the connections of the different level parts?
- Are you sticking with the jump height of 3.x blocks? I my opinion that is not much, 4.x would offer more options/variety, the question is if more jump height is needed? I don't know.

[diegzumillo]

Not a lot I can do but I can certainly do a better job of hiding the seam than that, but I'm leaving cosmetics for later.

The jump height is now at 3.6 units. It's a tricky number, because too low and it's annoying to design stairs and climb them. Too high and it's hard to design unreachable areas that are still within sight of the player. Maybe 4 is a good number.

[Schrompf]

Don't make that number a round number. 4 units of jump height would require perfect movement to reach a place 4 units above, or always deny such a jump while looking like it's doable if you just get it right. Three and a bit units of jump height, on the other hand, gives a bit of safety margin on 3-unit-jumps but makes it obvious that 4 units are unreachable

[Daid]

I did notice there is nothing that dictates the mesh needs to be on a 2D plane.

So you are saying that we will see a "mobius strip" level?

[diegzumillo]

Don't make that number a round number. 4 units of jump height would require perfect movement to reach a place 4 units above, or always deny such a jump while looking like it's doable if you just get it right. Three and a bit units of jump height, on the other hand, gives a bit of safety margin on 3-unit-jumps but makes it obvious that 4 units are unreachable

yep! that's why it's 3.5 at the moment. I took his suggestion as "make it clear 4 tiles easily".

EDIT: Didn't see the other reply before
It might be possible to have a mobius strip! lol I don't know if there will be one. But it would make a hell of a sequel to have an asymmetric character, like L-shaped, and have non-orientable surfaces for levels. Right now the levels transform the player with rotation, translation and scale, this would add mirror too. The L-shaped character would need to navigate itself into, I don't know, fitting inside an inverted L shaped hole. For apple it it would be mostly aesthetic.

[linebyline]

This looks cool. I have to admit I wasn't a fan of the shrinking/growing mechanic when you first posted it, but it's grown on me. That pun was completely accidental but I'm keeping it.

Here's my thought on the one-way platform/hinge situation:


Bow before my MS Paint skills.

For those who can't see the image: I'm keeping the hinge/trap door idea, but instead of having it split in two, it goes off to the side. The hinges are basically screen door closers. This way, you aren't limited to making one-way gaps the size of the two swinging panels (or making them enormous to cover wide gaps).

[JobLeonard]

Just be careful that people won't think you're ripping off Superliminal

[oahda]

not even remotely the same imo

[diegzumillo]

I think he's just being cheeky about the 'ripping off' part That is one crazy mechanic though! I never heard of that game before.

Did I mention I love seeing other people's drawings of apple?

Since I'm replying here: I haven't made much progress on the game. I am currently trying to debug the build version. Because everything works fine in editor, but in the build some collisions don't work. I don't know what could be causing this. My best guess is that my code has some dependency on order of scripts and functions running that I am not diligently enforcing, and just happens to be the right order in editor. Debugging build is so much harder! I just found out you can redirect the console output to read from the build, so that helps a lot, now I see all the debug calls being made from the build too. But I still can't pause the game and inspect the game objects to see their state etc.

[JobLeonard]

I am (and also just a bit cynical about how internet people are - I fully expect some people to sincerely be dismissive just because they spot a growing/shrinking mechanic)

> I am currently trying to debug the build version

I don't know the platform you are using, but it's not like they switch to "fast" floating point math in the release version or something stupid like that?

[nova++]

I think he's just being cheeky about the 'ripping off' part That is one crazy mechanic though! I never heard of that game before.

Did I mention I love seeing other people's drawings of apple?

Since I'm replying here: I haven't made much progress on the game. I am currently trying to debug the build version. Because everything works fine in editor, but in the build some collisions don't work. I don't know what could be causing this. My best guess is that my code has some dependency on order of scripts and functions running that I am not diligently enforcing, and just happens to be the right order in editor. Debugging build is so much harder! I just found out you can redirect the console output to read from the build, so that helps a lot, now I see all the debug calls being made from the build too. But I still can't pause the game and inspect the game objects to see their state etc.

Unity builds, by default, try to optimize meshes and can cause some problems if it's removing things it thinks aren't in use. Before you tear any more hair out, go to Project Settings->Player->Other Settings and set these two as shown:



edit: And possibly "Managed Stripping Level" to None as well, I think. Can't remember for sure.

[diegzumillo]

It was worth a shot but didn't work.
Later today I am going to write a whole bunch of log tests to check every script is logging when they should.

(edit) Narrator: He did not. Later that day he mostly just ate pizza and played videogames.

[linebyline]

Later that day he mostly just ate pizza and played videogames.

Better than the other way around.

[diegzumillo]

Tiny progress today. After one million Debug.Log calls and five hundred thousand build and runs I finally found the general location of the bug. Now I am able to reproduce the bug inside the editor as well, which makes this infinitely easier to handle.

As I suspected, it has to do with order of things. Specifically, when the two objects colliding and one is ghost, the ghost needs to be earlier in the list for it to work. The list in question is the list of all physicsbodies on the physics engine, which are registered on Awake() function, meaning the order is random. Obviously the order should not matter and I must have messed some flag setting somewhere. That will be a problem for tomorrow's diegzumillo. I think the hardest part of this is behind me.

[JobLeonard]

I think the hardest part of this is behind me.

You fool! This is asking, nay, begging the programming gods to jinx it!

[RealScaniX]

That will be a problem for tomorrow's diegzumillo.

Tomorrow's Diegzumillo will hate today's Diegzumillo.

[diegzumillo]

You guys made me worried for a second there. It went all right! the bug seems fixed now. I am not incredibly secure about it but if there's more to come I'm sure it will show its face eventually.

For those interested in the technical details here is a rundown of the bug:

The physics engine iterates the physics a number of times (I keep messing with this number and 3 seems good). Each iteration adjusts the edges to keep the object's original shape and then adjusts the vertices according to collisions, so the more iterations the more solid the simulation is. Once I had this working I essentially treated it as a black box; physics works, I'll just continue coding the game like it's that simple.

Portals work like this: they have a physicsbody, like all other objects, but it's a special "trigger" thing. Basically that means it doesn't respond to collisions, just fires up its event function whenever something overlaps it. In the case of the portal this triggers the whole ghost thing. A flag gets set on the body that's inside the portal that tells the physics engine to check this body for collisions twice; once normally, and another with it transformed according to the portal's specifications.

I didn't think much about this, but the fact I have to iterate over all bodies is extremely important. What happens if the portal is the last on the list? it might flag an object as ghost, but it that happened at the last iteration only the object's ghost flag will be reset before it is properly processed as a ghost.

The safest solution would be to process ghosts on the next frame. But the flag system to do that looks confusing to code and I'm sure processing ghosts with a delay would cause wonkiness to the simulation.

My solution, which isn't bug proof, is to make portals be processed first. It might seem like potato, potato, running first or last, but it's not. At the first iteration the flags are all reset but if there is overlap they will get re-flagged first thing. And portals will never check for intersection unnecessarily (when they are last they might flag intersection but it will get reset before anything happens).

Finally, to get the priority system in place as quickly and easily as possible I just switched from arrays to list. When a body registers itself in the physics it also comes with a priority flag, if it's true it goes at the beginning of the list if not it goes at the end.

[diegzumillo]

I was going to make some more levels but, for a tech demo that I just want to see if it runs on other pcs, I decided to upload the first version of the tech demo. TECH DEMOOOOOO!

It's on Gamejolt. let me know what you guys think! Let me know if it opens, if it runs. Hopefully you can get to the end without getting stuck on walls or stuff like that. A friend of mine already tried and he experienced bugs I've never even seen on my end.

https://gamejolt.com/games/appleandworm/24761