next »

[JobLeonard]

I made this pushing animation rather quickly. The legs are poorly animated and the head isn't at all. But it works I guess.

I did it mostly because I'm starting to feel burned out from this project and didn't really know what to do next. Maybe I should give it a rest for a while, I already made some great progress lately. I even sketched out the whole plot of the game, which took a surprising three pages of text.

Yeah, a little break sounds nice. See you all in a couple of weeks! 

I made this pushing animation rather quickly. The legs are poorly animated and the head isn't at all. But it works I guess.

Ha, I love that flat face, though. Looks cool!

I second that! The squishy skinfold makes it perfect!

Thanks, guys :D

I feel like I'm ripping off Cloudface animation (a now dead project from these forums that was amazing and had amazing animation) but I couldn't find a way around, since apple has no arms. Maybe using the top of the head?

My only gripe with it is that it only looks good against flat walls. Pushing a small object or when the box rotates a little, breaks the animation.

"Inspired by", you're thinking of the expression "inspired by"

[oahda]

best animation ever

[nova++]

I can just hear the "spack" sound of the faceplant

[diegzumillo]

All rightie. Spent a few days away. Went through a whole midlife crisis, focused on some real life research work, created a new game! watched it grow and die a premature death. Now I feel refreshed.

So one of the obstacles that is really keeping me from making more levels and experimenting more is the current workflow. I really tried to make this work but it doesn't. I create the mesh completely separately from the level itself, in a 3d editing software. I don't need to explain why in any creative medium, such disconnected workflow isn't helpful. I tried to mitigate that by making levels entirely on paper first, then the process of creating the level and the mesh separately are slightly less painful. But still far, faaaaaar from ideal, even in the current philosophy of just finishing the game without thinking too much. So I am trying to improve things a little.

Which sounds less painful: programming the required functionality in Blender and adding some basic level editing there (just basic layout of platforms, like colored blocks, I can live doing the rest in unity) OR programming a tiny mesh editor in unity?

The blender route sounds painful for several reasons, but mainly because I have zero experience scripting with it.

Unity has never made my life easier when it comes to mesh generation. I have nightmares with warning messages saying "use sharedmesh! mesh will cause leaks" I WANT TO CREATE NEW MESHES YOU ASSHOLE LEAVE ME ALONE.. Ahem. Anyway, creating mesh in runtime is fine, but when you want to work in edit mode it freaks out and I never learned how to deal with leaking mesh problem. I have been trying to bend ProBuilder, unity's new official 3d editing tool, to do the things I want and it's somehow even harder. It has a million functions and features, yet you can't create a new mesh without creating a new object from script.

Whatever. After two days trying to bend probuilder to my will I went ahead and tried to make a mesh editor directly in Unity. The current state of this thing is that I create an object with the component in it, specify the number of polygons I want and the number of control points I want. The control points drive the mesh using a surface Bezier thing (recycled from old code).

Now I'm trying to write a function that patches planes together according to how the rooms are connected. Which I broke into a number of steps... more or less undefined, but I know that the first part needs to be a function that makes a number of points coplanar. However these planes will be stitched together they will certainly need to be aligned.

It.. um... sort of works. It does what it's meant to do, I just thought it would work better. After selecting a number of objects the function does a linear regression to find the best line, then I project all points to the closest point on the line. The problem is that a simple linear regression is shitty for what I want to do. Here's an illustration, showing the case, what I thought would happen, and what actually happens:


I can think of a few solutions but I would really like a simple one. Maybe a different type of regression? Maybe I could break this operation in two steps, first choose the points that define the line, then choose the ones to stick to it.

The following steps into making this usable seem even trickier. The bridges between rooms connect specific sections of the side to specific sections of the side of another room, and I would very much like to have that translated automatically here. I have no idea how to achieve that yet. Hopefully this whole coplanarator thing is a good first step.

Part of me really wants to just keep trying to make levels on paper and that's it. But the fact that so far I made ONE working level and a bunch of tests doesn't bode well.

EDIT: Defining a new entity of sorts to represent the edge/sides would facilitate things. I was kind of neglecting this approach because it seems to make things more complex, which is what I'm trying to avoid.

[nova++]

Just as a refresher, since I don't know how far into this you've dug: Using the "mesh" variable of a MeshFilter creates a new instance of the mesh you assign it, while "sharedMesh" treats it as a direct reference to a pre-existing instance (and yes, the decisions behind this behaviour have always confused me)

Obviously you don't want to be prodding at sharedMesh if you've got it using something out of the asset folder, but for all procedural mesh needs, sharedMesh is what you want to be using. And you of course always have to remember to call Destroy on the meshes you create when they're no longer needed... although, when exactly that's supposed to be called in the editor I am unclear on, as I haven't actually made anything that creates meshes in editor mode...

But either way, you CAN keep re-assigning the vertices and triangles and everything of one mesh and simply reuse the same instance, so your procedural mesh thingamajig could just create a working mesh that it continues to kick around until it's deleted. That's what probuilder is doing, I assume. So for your needs you'd create a vertex and triangle list, modify that as you edit the mesh, then just re-assign it every time a visual update is needed.

source: someone who has been working with far too many procedural meshes for far too long [thousand yard stare]

[diegzumillo]

It's really weird. I also think they changed this behavior a little in some update in the past years. I got it working seemingly fine now.

[RealScaniX]

I got lots of those warnings, too in an old project. Using new Mesh(oldSharedMesh) instead now, if I remember correctly.
You should also probably set the flags to HIDDEN | DONTSAVE, so they don't leak around that much in your scene.

[diegzumillo]

It's getting complex. Did I mention I was trying to avoid that?

Now each control point has its own class where, once created, holds an identifier flag for its position in the surface patch and a reference to its surface parent. So now any operation on these control points can be contextualized. For example, I select a group of points I want to connect, some points belong to one surface, the other group to another surface. Then I find the best line for each group separately, find the intermediary line and move all to it.



Despite wasting some time wondering why vertical arrangement of objects wouldn't work (duh) it was mostly painless.

The next step on this thing is to slide and scale one of the sides to match the portal relation. But now I have to make a decision. Should this drive the portal creation or the other way around? I was subconsciously doing this to follow the portal placement on the, um... euclidean room. The non mesh part of the level. I place the portals there, connecting rooms, and the meshes would automatically glue themselves accordingly. But it could be nicer to connect the meshes and that generates the portals.

But if making this bridge creates a portal then I would have to make this bridge an entity itself, in order to keep track of the created portal. Adjusting the bridge shouldn't create a new portal.

If the portal controls the bridge, I can just reference the control points on the already existing portal class. Oh, also hold a reference to the line instance (I made a line class to help with this crap and it has been surprisingly useful, it finds the coefficients, nearest points and all that stuff). Sounds simpler. I shall take the path that minimizes the action!

I suck at organizing code and it tends to become spaghettified. It's the main reason I avoid writing complex code. I can deal with the math and basic logic, but not the logistics of the code.

[nova++]

Every time I try to help I quickly realize I've underestimated the sheer madness of this project. You're a brave one.

[diegzumillo]

Every time I try to help I quickly realize I've underestimated the sheer madness of this project. You're a brave one.

I appreciate all the help I can get! 

Thing is, I am constantly under the impression the complexity is just poor organization. I can't prove it, but it feels like it.. and I'm afraid my rush to keep things simple might be making things worse!

Here's my current plan to make things simpler or possibly worse:

Currently, Portals, Rooms, MeshGen, are all independent creatures. The Room class is not aware of portals leading to/from it, or which mesh is representing it. And I kinda need a little bit of communication between these guys so I am considering creating an extra thing that keeps track of all the things! In theory this sounds better than connecting all these dudes willy nilly, like those boards we see in cops movies covered in pins and paper and red lines connecting everything. No, this new class (let's call it "level sector") keeps track of everything.



On the other hand, maybe I can reshape Room to be the brains of the operation. Right now it only has initialization stuff, like instantiating tiles, camera, and some helper functions. Wait.. I think Room already holds a reference to the mesh. Oh look, it does. OF course, I needed it to send the camera texture. All right, screw levelsector, I'll reshape Room.

This post was another case of changing my mind while writing it.

[RealScaniX]

That mesh stitching looks like a fun minigame. =P
 
And you have some cool technical aspects in your game. Every game (even if it looks stupid) has some technical challenges somewhere. In your case (from seeing the videos) everyone expects some hardcore magic behind the scenes.
Creating a good system for those is indeed challenging. In my simple taxi game I reduced the connection between parts to a minimum to be able to add new mechanics (magnets, lasers, etc.) to levels without having to change the main classes.
But for fundamental stuff that is always there, you can add direct references to make it all easier, I think.

[oahda]

 

[diegzumillo]

Felt the pixel itch today. So I made the sprites of 3 characters that were only in my head until now.



Just noticed I didn't draw their arms.

These are the water witch, air witch, and sand witch. Apple and Worm will help them out with something, I haven't thought the details yet. Sand witch always introduces herself as dune wizard, desert mage, and variations, but the others insist on her official title. She is always made fun of, obviously. Doesn't help that she looks like a meatball either.

Anyway, just wanted to give a quick taste of the kind of high brow humor I'm aiming for. I also wanted to get some kind of world with giant butts farting but Rick and Morty beat me to it.

Speaking of high art (lol), ever since my previous project (a mega drive game) I have been considering some kind of post effect filter. While I was making pixel art for the mega drive I was consciously making it for CRT displays, which requires some different pixel art techniques; clean and flat doesn't translate as well as dithering and pointillism. And I quite liked the results. Since pixel art in apple and worm is kind of a mess because of its complete disregard for a pixel grid, I thought this could benefit from some kind of blur, or stylized blur. I don't know yet, but something to keep in mind.

All right, back to boring classes communication and editor usability. (Actually, back to real life work until late afternoon)

[diegzumillo]

Continuing the editor extension to facilitate level creation. The idea to glue meshes together according to portals semi automatically is tricky to pull off. I defined a new object called meshconnection, that does exactly what it sounds. I realized, however, there would be a complicating factor: whenever a room mesh is connected to two other rooms, above and right, for example, these connections would have to be constrained together! Now, I completely forgot about that detail and just implemented the connection thing. Then remembered the complication.



I am not sure how to solve this because it's a chain of constraints, and I don't know how to define which is the boss of whom. Order of creation? And after deciding that, the math to actually find the proper constraint isn't trivial. I can't connect the ends because they have the sizes of the portals (equivalently) and might not cover the entire side of each room mesh.

This is the kind of complication I was trying to avoid. I'll give it a crack, if it looks like it will get even more complicated I guess it's time to give up and go back to external editors for mesh.

[diegzumillo]

I "solved" the chain of constraint. It only handles the most basic cases though. It's fine, I can do a lot by hand. The system is, at the same time, cleverly simple and a spaghetti mess. I pray to every divinity that it really does work and I never have to fix bugs on this.

Wehenver a connection shares a controlpoint, one becomes a slave. Whenever three connections share a vertex, well  That's fine, it can be avoided by having additional intermediary rooms. Solving this would be very  hard because there are cases that are mathematically impossible in a 3D space. Like the example below. (This assumes a connected side is straight! in an external editor I could make this setup possible)



So a real solution would have to detect all these cases.

But it seems like this is working well enough. I wanted to make a quick gif using the editor but it's not good enough to show it in a few seconds. Everything takes some setup. Maybe a video later.

Also, I don't know how feasible it is, but I want to finish the game in about 7 months. The weird timeline is because my real baby is coming and I want this game baby to come out first.

[JobLeonard]

You really live up to the "Patching Holes In Spacetime" tagline, don't you? :p

[diegzumillo]

You mean because the game is held together with spit and stubbornness? Absolutely.

[oahda]

Well, that, and the literal stitching together of different pieces of fabric of spacetime! Looking good this. Good luck on your deadline!

[diegzumillo]

Ah that haha I thought it was a reference to how I'm cobbling stuff together hastily.

So I've been thinking about how to start the game. And some people say you should never start writing a book from the first chapter, maybe that applies here. I have a general idea though. Maybe writing here will help me out.

I was aiming at a first level(s) with no curves. But I realized there isn't much to do yet. No enemies, no gimmicks, just jumping around isn't fun. It's fine, this is a problem even with the curves, which I encountered many times throughout this devlog. I just need to define which gimmicks will be introduced first.

To help me define that, maybe look at the story at this point. The game starts by showing a tree with an apple dangling against the background. Peaceful and calm. Then the apple drops and a giant smiley apple shows up and eats the apple, the camera steps back and you're controlling apple. "somethingsomething we need to collect apples to make apple pie. stop eating them" says the worm. Then you move around, jumping and collecting apples.

OK. This first level will take the obvious stab at Mario. I mean, videogames, like any other medium, has its own vocabulary. We make use of previous knowledge. Here I'll be saying "look. goombas. you know those. Jump on it" just to show you can't kill the things and the things can't kill you. In fact it speaks.

So all right, the pseudogoombas are in I guess. I mentioned before they act like springs if you're smaller than them. At this point I could sprinkle a variation of sizes for the player to explore what they do. Can't push the big ones but can ride on top.. stuff like that.

Maybe some basic physics objects. The good ole 'push box to win' thing. Even though there won't be curves yet there is nothing keeping me from introducing things with different gravities. I enjoyed playing around with that. Standing on top of a wall and jumping on a stack of crates with a perpendicular gravity, so they all fall and move left or something like that. It's fun.

Maybe that should be enough. pseudogoombas and weird physics.

[diegzumillo]

I came to the conclusion I really don't like making art. That's not true, I don't like making art when I'm not interested in the subject. And as much as I want to make this game, drawing tilesets is just so boring. "this one is 8x8 with grass. This is 16x16 rock. Now I will make 8x8 metal floor". God just kill me now.

So I'm taking a ride on this inktober thing with pixeltober variation and making something useful for the game every day. I will not spam this already abused devlog with daily updates like "look at this 32 pixels I made. It's a tiny apple", but I will update occasionally.







We'll see how this goes. I'm considering buying some assets if I can't get my ass to make these basic blocks and just work on the more important bits, like characters and such.

Edit: added today's pixeltober, with some houses for the glooberbools.