next »

[diegzumillo]

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?

Good question. Decided to go back a few pages to read my explanation. Turns out "I didn't like how I was dealing with visual elements". Christ, am I always this poor with words? Is this how you guys are reading this devlog? When I'm writing it all sounds so much clearer!

ANYHOW, my old polygon system was indeed poorly made. It wasn't a smart system, so I had to create the polygon for the platform and then create the strip surrounding it with grass or whatever. It didn't properly connect around the loop so there was always a seam somewhere.

My current thinking is that tiles lend itself better for puzzles. If you know the character jump is 1 unit high, you don't have to playtest a level to know which areas are reachable, it's all instantaneous.

[oahda]

Makes sense!

[diegzumillo]

I'm totally spamming this devlog, I know. But it's actually a better way of keeping track of what I want to do next than my notebook I keep losing, and it helps me organize my ideas. Maybe I should do video logs and allow myself to ramble for 20 minutes nonstop instead. Since I made some good progress and I have real work accumulating and waiting to be done this is a pretty good moment to take a few days break from the project. So here is a giant block of text:

Portals need fixing.

I made a quick test level and discovered the rumors about the portals working perfectly were largely exaggerated. I have to work on that as my number one priority.

Then player controller needs to be started, at least.

After portals there are many things I need to work on but I believe the next on the list would be a decent player controller. There are two ways of going about this: forces on a physicsbody and directly moving a physicsbody as trigger (equivalent to kinematic in unity's rigidbody). Each comes with their own share of challenges and there is no way of knowing which will work better. A hybrid system is not out of the question either. In the first incarnation of the game I was already playing around with different modes, like swinging, grabbing, which works great with simulated dynamics, and I'm planning to have a "ball mode" where apple turns on its side and rolls and bounces.

Next on the list.

After that, and only after that, I will consider whether platforms should be made out of polygons or tiles. Again, each comes with its own challenges.

I started working with a basic tile implementation but the main issue is collision. Naively making each tile a box collider won't behave like a smooth surface, because an object with any penetration inside a tile might hit the sides of the neighboring tile. This is how you get the typical jagged movement, getting stuck on invisible steps. The advantage of tiles are on ease of creating levels. Just quickly brush volumes and immediately understand the level spatially, because they all have the same dimensions.

OK, what follows next is a borderline schizophrenic dialog between me and myself about polygons vs tiles.

Polygons might be easier to implement! which is a huge point in its favor. Since I already have some experience with it I remember what were the problems. In fact once I started writing this post I had a few points about what makes polygons not ideal, and as I wrote them I immediately started counter arguing myself!
It's hard to make it look nice, for once.
Yes, it is. But the new mentality demands disregarding such a weak point. So it's ugly! it just has to be beautiful on the inside.
Designing levels with it is finicky.
That's because I was dumb and didn't use a grid. There is nothing keeping me from sticking to a grid with a polygon system.
How would I align these polygons between rooms?
When I thought of this question I think I meant between rooms of different scales which, sure, is a thing, but tiles have the exact same problem, stupid.
Does not play well with pixel art
Even though this is a subset of the first item it does deserve its own explanation. I think pixel art is the wrong choice of art style for the game to begin with. With all this rotation and scaling I believe worrying about keeping pixel art consistency is a lost battle. So... the new mentality demands disregarding such a weak point^TM. I am keeping pixel art because I can spit out assets faster this way and I am way too attached to this guy:




It's starting to look like polygonal platforms are going to win.

Cheers yall  

[oahda]

I have those dialogues with myself all the time too, in the text editor on my computer! They’re very helpful.

FWIW, I thought the polygons and the rotated pixel art in that old version you dug up looked great!

Swinging and rolling sound like really cool mechanics.

[diegzumillo]

I have those dialogues with myself all the time too, in the text editor on my computer! They’re very helpful.

See? This is how one maintains a clean and organized devlog!

Meanwhile, in the apple and worm devlog: I mADe a COOL GIF YALL loool 



Someone get me Valve on the phone because I know how to spruce up their Portal mechanic and its boring scale invariance. In all seriousness though, maybe I should be using this with portals put by the player, you know. Or maybe these things aren't mutually exclusive. hmm.

[diegzumillo]

Been away from this project for almost a month now, doing other things of life. Now I came back to it and it's not feeling promising. Maybe I'm just on a pessimistic mood.


WARNING GIANT WALL OF RANT INCOMING


I love Unity! One of the things I like the most about it is that, even though it's not open source, I am given the freedom to do everything I want from scratch. But I would really, really, really, like to be able to use some of its systems at least! Otherwise what advantage do I have with it, as opposed to using my own engine? Seems like every step I take I'm forced to ditch some of its systems because it refuses to cooperate with me. It takes time to try and bend the system, and then more time to code my own.

I already mentioned the physics system but now another example: changing the sprite pivot from code is tricky. It's not designed to be done that way, but from the sprite editor window. That does not help me because I need to move the pivot during the gameplay. Workaround: add sprite as child of another transform. Fine, I'm doing that. So now I'm juggling four gameobjects simultaneously for each object, the original gameobject, a child with a sprite, another pair of gameobjects to hold the ghost and a child sprite. All need to be transformed as it moves through the portals. All this because I need to move the sprite pivot a bit, which to me should be as easy as sprite.pivot += displ;

Is this doable? In theory, sure! But the code is just so terribly ugly and unmanageable. I keep running into bugs and debugging is a nightmare. Why is this ghost misaligned when the object comes from this angle? at which step did I fudge it? which of the 4 gameobjects? If it were only the sprite system, maybe I could manage, but I'm doing this to everything. Another example: Animator component, the thing that handles animation, also suffers from this and also comes with equally unmaintainable workaround solutions. I am adding new event functions to run after/before the Update just so I can synchronize frames of animation, because I can't control two sprites with the same animator. It's absolutely ridiculous.

Given the project's current philosophy of done>perfect this is a real problem. I am not willing to spend months getting basic stuff like this functioning on a basic level. In months the entire engine needs to be up and running flawlessly! So I find myself once again in that position of arguing which is less time consuming: hammering something until it works with me or ditch it and code my own solution yet again. Neither solution seems aligned with my philosophy at the moment.

To add an extra element of danger to this project, I spent a week at my parents' home playing around with Godot engine. The thing is in its infancy, full of bugs and problems, but it's open source! How amazing is that. I made a simple platformer using premade functions from its physics engine, like moveandslide(). A perfect 2d platformer controller that doesn't fight the physics engine, done in matter of minutes. It already has this weird (and I really mean WEIRD) system of scenes where you can render stuff in one and use as node in another... it sounds exactly like what I'm doing here. But I say it's dangerous because changing engines at this stage is depressing. Besides, it will come with its own share of challenges and who knows if overall the project will be simpler or even more complicated?

I don't know what to do right now. Maybe tomorrow I will find a simpler solution that works and is manageable. Or just be more optimistic and keep pushing.

[oahda]

Tricky one. Maybe you can work around the animator problem by rendering the same sprite twice instead by manually invoking it. I did that when working on a portal system in Unity so long ago where I also needed to show the exact same object in two places at the same time. But I get that this isn't the only issue.

[diegzumillo]

The thought crossed my mind too. I'm already rendering to texture each room, I could have additional cameras rendering the corners and layering the textures, hypothetically. But it sounds contrived so I didn't pursue the idea. I am also not a good programmer  so if it sounds contrived in theory my implementation will only amplify that!

Anyway, today the crisis feels under control. I took a few steps back and I'm rewriting a big chunk of the code. Simplifying things here and there. Hopefully, by the end of the day I'll have something that works just the same but is more manageable and easier to debug.

Today I'm more optimistic! I even had some cool ideas for the story of the game, which never really had a lot going for. 

[oahda]

Woohoo!!

[diegzumillo]

After rewriting a bunch of code things became clearer. I even had the whole thing working perfectly at one point. But I didn't know why it was working! it actually shouldn't be working. As tempting as it may be, I cannot accept a thing that works without knowing why, so I will continue to mess with it until it works and I understand why it does.

Is there a tool to organize code? Not automatically, just a way to schematize an algorithm. Right now I have a white board filled with crap and my ugly code. Feels like there should exist a tool that let's you create some boxes with arrows and all that.

[oahda]

They’re not for code specifically (but maybe that exists too) but there are mind map programs like XMind if that helps!

[diegzumillo]

Things work now. I almost understand why! But not quite. I accidentally made it work in a way that shouldn't and that drives me mad. I really need a win in this project lol so I'm leaving it like this with the real solution as an exercise for the reader. My code is full of comments with exercises for the reader. Obviously worded like I know what I'm doing "this transformation needs to be applied before for obvious reasons left as an exercise for the reader to prove"


And thanks for the XMind recommendation! I'll check it out.

[diegzumillo]

Hallegoddamnlujah. My test level mesh is finally able to run! It looks like crap but kinda works. There is a serious misalignment in the mesh there that I don't know why is there. Everything looks properly measured and aligned in the editor, and the portals are working now I CHECKED A MILLION TIMES. Edit: found the misalignment and updated the animation.

I'm gonna have to come up with a better workflow to make the level mesh. Or maybe I'll just keep doing it in Blender, but I still would like at least a quick way to generate and rotate the UVs in Unity, because I find myself constantly tweaking it. Ideally I wouldn't need a 3D editing software just to deform planes but whatever works is fine by me...

Behold!



It's so ugly, with the weird artifacts in the render texture and the misaligned UVs, and yet this gif makes me very happy   It means the end of a scary struggle, when I thought the project had hit the bedrock of my programming skills. From here things seem like they can proceed.

I made sure to position two identical objects at the beginning so the change in scale is more noticeable after it goes around the loop.

This is what the mesh looks like and how the level is laid out in the editor:



I guess I'll finally get to do another bullet point list of things to do next:

• Any improvement in how to create the level mesh would be great. At the very least in engine UV editing, if possible.
• I remember debating between tiles and polygons for platforms. Make up my mind and do something about it.
• Character controller! this is important. Maybe I should start with this one? Depending on how it goes it might even direct the choice of tiles or polygons

[diegzumillo]

Look at them goooo! they all start falling down meet halfway and return to the same place with different sizes and falling upwards now. This game makes sense.

I will absolutely spam the forums with inane gifs of boxes falling now.

[oahda]

That’s amazing!! Great job!

[JobLeonard]

Dude, you are solving some seriously complex problems here, very impressive!

[Superb Joe]

please make a figure 8 loop and replace the box texture with a go kart, this is extremely good shit

[diegzumillo]

Thanks for the support, yall If this game ever releases you're all getting a steam key (or whatever) and a fruit basket, for reading through this drivel of devlog and encouraging me.

Dude, you are solving some seriously complex problems here, very impressive!

I suspect they are only complex relative to my own questionable skills I always laugh at myself when I remember the reason I started this project was because I wanted something simple to work on.

[JobLeonard]

So you started with a platform game mechanic based on Lorentz-Fitzgerald contractions? ROFLMAO

[diegzumillo]

So you started with a platform game mechanic based on Lorentz-Fitzgerald contractions? ROFLMAO

well I wanted it to have some gimmick to set it apart!