next »

[JobLeonard]

You know what's not dead? APPLE AND WORM!

As embarrassing as this old topic is I will still update it because I'm stubborn. I finished my studies and now I'm just unemployed. I almost gave up on this game on several occasions but every now and then a new spark reignites this project and I don't let it go. At least now I work on this without the guilt that I should be working on something else.

My last implementation is on hold for a while. I decided to test the other alternative I mentioned before. The one where I create rooms separately, connected by portals, and render them to texture to a continuous mesh. It seemed a lot harder at the time but now I think I may have made a mistake. So I'm trying it out. If that doesn't work I can always resume the previous implementation, which had good physics and collisions already working and everything.

Anyway, I also decided to revisit my pixel art. I like the characters! those will remain. But I think everything else looks too complex. Too many levels. Muddy pixel work. This is what I'm going for now:



Work in progress. Let me know what you think

You're back! Excellent! I was hoping he hadn't heard the last of this project.

Yaaaaay!

Anyway, go for whatever gives the least workload and the highest likelihood you'll finish the project man

EDIT: pagination.

[diegzumillo]

Thanks for the warm welcome (back) yall! 

By the looks of it, I really did take a wrong turn when I didn't choose this method before. I considered it and it seemed so much harder at the time. I don't have anything interesting to show yet, but hopefully soon there will.

[Superb Joe]

cool, in my opinion

[snackycactus]

wow your warping tech is super cool!!! If you have time, you should make a unity-asset plugin out of it. It really is awesome!

[diegzumillo]

Part of the new system's basic idea seems to be working.



So as you can see, the actual game happens in 'normal' euclidean space. So I can use Unity's sprite system, sprite, animation, physics, tileset and everything else. Each room will have a portal connecting each other and its own camera rendering to texture that is applied to a mesh continuously connecting all rooms. The gif above is showing a room rendered on a deformed mesh.

I'm trying to come up with a way to create the mesh inside unity. For this test I'm using a 3D modeling software (let's call it Blender, for legal reasons) to test the thing.

Now onto the portal system.

[diegzumillo]

Remember when I said I could use Unity's native physics system? (box2d)

So I can use Unity's sprite system, sprite, animation, physics, tileset and everything else.

Ah... Good times. Feels like it was yesterday.

Well, turns out physics is out of the question. Maybe. I'm starting to remember why the other method seemed more attractive than this one. It was still a mistake to go the other way! because both methods seem to require my own physics implementation anyway. This time the problem is the connection between rooms. Every object that stands in the intersection exists in both rooms at the same time and that's... tricky.

I'll continue poking around and seeing if I can find a way to use the physics system. If that turns out to be impossible I'll move on with the new development philosophy: f*** it. I don't need no fancy physics! I'll just scrap together the simplest possible character controller and that's it.

[diegzumillo]

Devlog entry #... who's counting anyway

Under the new banner of "done is better than perfect", doing my own physics solution is not exactly advisable. But I did it anyway, for two reasons: I've done it before and adapting it would be quick, and because if it's stable and reliable enough it could double as a character controller, thus saving time!

I made a quick stress test with a much larger number of physics bodies interacting than I'll ever need to see if it had any significant impact on performance and it doesn't. So performance won't be an issue.



I still need to finish implementing this so it moves seamlessly between rooms. This should be tricky. Moving between rooms works like in Portal (I think), where the object needs to exist in two locations at once while it's in the intersection, so synchronized simulation, with boolean addition of collisions, if that makes sense.


Edit: I'm having dejavu. It's not the first time I said "all I have to do now is work out the intersection" as if that's the easy part. I'll give myself a week to get this working flawlessly, after that I'll start working on a simplified character controller that checks for tiles and that's it.

[diegzumillo]

Made some progress! My physics system was already working but my simplistic and amateur implementation was starting to show its limitations. An user by the name of SparrowsNest at the Unity forums has shown me the ways of the delegates! The Apple & Worm team shall now chant his/her name during its weekly midnight feast of apples and ground worms.

The changes I made have allowed my physicsbody class to be a monobehavior extension. Now it feels like a real physics system! I add physicsbody component just like you would a rigidbody component, in a gameobject. I was doing the whole physics simulation inside a single c# script with normal classes, like a goddamn peasant. Delegates also allowed me to let any other scripts and components to listen to collisions and events like triggers from the physics system in a much more convenient way. Which was the whole reason I asked for help there in the first place. The script registers its function in the list of functions that get called when thing happens. It's super magical and convenient and I shall use that everywhere now.



So things are looking good. Last time I posted I mentioned the priority was to get the basics of portals working and they kind of are. The core of portals is a feature I'm calling "ghost" (I wanted to call it double but that could create confusion with Double type). Because at the intersection between two rooms the physicsbody needs to exist in both rooms at the same time, responding to collisions from both sides, so I came up with the term ghost for this functionality. When the physicsbody enters the portal trigger, the portal activates its ghost in the other end of the portal. This is the ghost with no portal yet:



This right here is the whole reason I had to make my own physics solution. I tried to hammer it into Unity's physics and never got it working. So it's nice to see it in action, finally. Gives me hope for this project.

Next on the list:

• Make portals. Triggers with two regions and transformation properties (translation, rotation, and scale)
• Replace current physics main loop with delegates on the physicsobjects. This will make it easier to add and remove physicsbodies from the simulation by having each physicsbody add and remove its own PhysicsUpdate() from the list.
• Add sleep mode to physics to keep objects from jiggling forever
• Make it usable as character controller. I don't know what else will be necessary to achieve this besides the previous points.
  

That's it for now 

[oahda]

Exciting!!

[JobLeonard]

Cool solution to your problem! Looking forward to seeing where you'll take it!

[diegzumillo]

Portals are getting there. Transformation operations are done. Both the ghost thing and the final teleport part. At least for physics objects, so now physics objects can go back and forth between rooms with portals, colliding and interacting properly with every other object.

It's a small win but it's a nice one. Here's a boring box moving from one room to another. This particular portal changes scale only. It can also rotate and flip. The ghost has no sprite representation yet, so on the left you only see the sprite on the right room when it fully crosses the portal.



A nice accidental feature that I am not sure if I'll make use of, is the possibility of "non-orientable level design", i.e. it might be possible to have Möbius strip-like topology in levels.



Whether that will be used or not is uncertain. I don't really know what challenges comes with it and what the game gains with this. But it's a neat prospect nonetheless.

Next on the list:

• Organize and clean the portal code now that it's almost finished
• Continue improving the physics and start making it usable as character controller
• Start working on a sprite 'manager'. A local manager just to enable/disable and position the ghost copy

[JobLeonard]

I mean, Endgame already ruined Möbius strips, nothing you can do to make it worse now

[diegzumillo]

There's Mobius strip in endgame? I still didn't watch this. I missed my opportunity in the shitty local movie theater.

[ProgramGamer]

There's a brief reference to them when Tony is figuring out a mcguffin for the plot.

[diegzumillo]

OK, got the sprite stuff working too now. Here's a gif (now with a forum-friendly vertical aspect ratio).



Top: smooth transition as will be seen in the game. Bottom: What is actually happening.

The code is reaching that stage where it's starting to feel unmanageable and hard to find bugs. I wonder if this is a good moment to organize things again, or push to make things work first.

Like, physicsBody informs the main transform of its position and rotation. Transformation properties are calculated inside portal. physicsbody constantly asks portal for coordinates on the other side. Mastersprite, the thing that creates the duplicate sprite in the ghost part, is currently asking portal directly for transformation coordinates. 

[oahda]

I can barely wrap my head around this just watching the working product, so it must very tricky to program indeed!

[JobLeonard]

What Prinsessa said, and I'm a physics drop-out who actually made art specifically about space-time distortions :p

[diegzumillo]

A fellow physics enthusiast! Yeah, the whole curved space thing is not easily absorbed on a first sight. I discovered that by watching people play the original demo. It's easy for the dev to know things because it's been in our heads for a long time. This is why I'm putting so much effort in remaking the entire project from scratch! it might seem like just cosmetic but visual communication is pretty darn important here.

I'll just uh... write down another list of next things to do here (the reason I've been doing this lately is because I lost my notebook I was using to keep track of this project)

• Add portal 'margins'. Otherwise objects may teleport inside others when crossing the portal.
• Constraints. This is a first step to make physics usable as character controller. A rotation constraint, more specifically.

[diegzumillo]

To my surprise it was not difficult implementing rotation constraint and it works nicely. I also fixed the portal completely now.

Rant mode ON.

Anyway, I decided to write a simple script to create colliders for the tiles in the tilemap. It's not working. Good lord, Unity is still struggling with 2D stuff. How hard is it to get a grid of stuff working? Absolutely every step of the way it's like the engine is fighting me! The simplest thing one can think of: putting a prefab in the palette to position prefabs on the grid. Doesn't work. The workaround is to make it a brush, which defeats the purpose of having a palette to select tiles. I thought "well there's got to be some function that gets all tiles" and indeed it has, it gets all tilebase, which is a class that does not contain information like its position in the map, so you have to sweep the entire space (thankfully you get access to bounds) and inspect each position, and you get position for free.

I was hoping to use Unity's tilemap system to save some time but it's starting to look like their implementation is just not usable yet. Maybe for something simpler, but not for my current project. Which means... I have to make my own tilemap system  

Unity sometimes baffles me. I will even quote Tom Francis trying to learn Unity coming from Game Maker because, even though his issue is quite different from mine, he articulates my feelings better than I can.

I still don't know why Unity makes it so hard to have code refer to assets, though.
In Game Maker you just... type its name.
In Unity it feels like you have to attach it to a weather balloon, program a satellite to shoot it down, then design a net to catch it when it falls from space.

Rant mode OFF

All right, so what do I really need? not much! I can probably use Unity's Grid class, then I need an editor script to act as a tile palette. I click on tile in the inspector and I click the grid to instantiate a new tile there. By tile I mean a gameobject with a sprite. It would also be really nice to have an autotile system that look for neighbors and inserts the proper tile there. I did this for the previous implementation (it was a pain in the arse) but it's too different from this implementation to be useful, probably.

ON THE OTHER HAND, what if instead of tilemaps I went back to this project's first incarnation? It didn't use tilemaps, it used polygons. It was full of flaws but it worked. I will look into that too.

Sorry for the gifless and rantful update, but I'm sure no one wants to see boxes falling without rotation.



EDIT: Don't mind me again. Little note to self for next time I work on this:

• Initial positioning and rotation of sprites is a shameful mess and I should fix that before doing anything else.
• No, you have to do the previous item first.
• Anything else.

[oahda]

What a mess. ): Good thing at least Unity’s so open to extensions like custom editors. How come you decided to go from polygons to tiles the first time?