next »

[diegzumillo]

Thanks, exit!
I did some more work on it, and edited into a scene of the apple going through the wormhole to see how the different styles look together. The verdict is that I like it! Doesn't look out of place. Even though in this crude mockup the transition is way too sudden.

[Quicksand-T]

That works prettty well but I feel like maybe the colors are not consistent between the sprite and the cel-animated versions of the character?

[JobLeonard]

I thought I was already subbed to this thread?


Oh well, glad I found it again!

[exit]

i also agree with quicksand. i think changing the colour of the the wormhole could help in making the transition smoother. you could also try overlaying the wormhole on the level screen and then increase its alpha. the art style is coming together very nicely though.

[diegzumillo]

Thanks for the feedback! I'm actually ok with the colors. Might be a slightly different tone of red but the whole art style changes as well. The transition is definitely off. I made that mockup with a video editor, simply cutting one and putting the other at the end.

Ramblings on animation production

I have a new issue on my mind now. By choosing animated cutscenes I created the necessity for audio production as well. The game would have audio and music, sure, but these would be made in a batch to be used in the entire game, while animations need its own audio track. Sound effects and even voices are complications I had no intention of adding to this project. But oh well, let's see what I can do. Right now I don't have any cutscene sufficiently well defined to start working on it. Wish I had though, because I really want to get these doubts out of my mind.

Another problem is language. I wanted to make the game in portuguese and english. Which is simply enough with just text but now I need bilingual voice actors. And there's no way in hell I'm making two different animations with different lip syncs! (that awful speed racer animation style would really come in handy though)

I hope I'm not making a big deal out of nothing. Since I bought the animation software for 30 days, I'll set my next task to define a cutscene and work on it until it's done. That way I'll settle this whole mess under a deadline. By the end of it, the game will either be on its way for more animations with audio and whatnot OR it will have reverted back to simpler cutscenes. Either way something will be defined, and that's always good.

[Quicksand-T]

You could do it like Super Meat Boy and not have any dialogue at all.

[diegzumillo]

That's something to think about. But I have a few dialogues planned I'm quite fond of!

[diegzumillo]

Reinterpreting the pixel art



Started from the pixel art, made a couple of drawings as close as possible to the reference (one at the same pose, other doing something different). Then coloring at will. Then Animated version.

The animated version is kinda boring. Close to the source, yes, but still boring. I'll make some tweaks to give it more personality.

[diegzumillo]

Hah! Scary how tiny tweaks can make such a big difference.

[diegzumillo]

I was at EPXCon 2016 and it was great!

This convention was held here in Iowa City and had some awesome people from the industry come and share their experiences. People from Disney, Blizzard etc. And local developers, such as myself, were given a space to showcase our works.

I brought Apple and Worm with me and the reception was very good. It's a completely different deal seeing someone play rather than reading someone's feedback online. They don't have to say anything, I can just look at their faces while they are playing. And there's nothing more satisfying than watching the serious expression turn to laughter and smiles when they go through their first curved region at the first level. Then comes the curious expressions followed by frustrated expressions. Next time I do this I'll set up my laptop to record people's faces alongside with the gameplay to study later.

I met a lot of awesome people, and it was really great. But it really put a lot of stress on my 'autistic spectrum' brain. After the first day of basically sitting down and talking to people I felt like I just ran a marathon. I think the effort was worth it though, I think I did a decent job communicating more or less normally.

The whole experience made me excited about the game again. In fact, I might even update the demo one more time. I'm kind of tired of seeing the same problems that are already solved, and hearing the same (correct) criticism. Not to mention I even discovered some new bugs that might still be present in the new code.

Also, this game seems really big on kids. I think it's the colorful, cheerful look. Too bad the puzzles seem to be overwhelming them. Maybe the game could be a bonding experience between children and their parents? I'll consider allowing for simultaneous input from more than one controller or something like that.



More pictures here.

[diegzumillo]

Sup yall

It's your favorite vaporware devlog again! Even though my life has been extremely busy I really have no good excuses for not working on this game for so long. It's a mixture of being burnt out and overwhelmed by design issues. But here I am! still doing my best to keep this alive. Last time I worked on the game my immediate goal was to test additional game mechanics, in particular action elements, like enemies. I tried some scaling mechanic (which I mentioned and showed a couple of tests here) and discarded it, also tried a very interesting but overall confusing mechanic of spitting seeds that link the player orientation to the object hit by the seed. This seed spitting thing was really confusing and hard to design levels around it so I discarded as well. I haven't yet made any enemies but I'm actually looking forward to doing that! there are some novel things to try with enemies when you can approach them from different orientations. Like, maybe jumping on the head of a flying thing damages you but if you are upside down with respect to each other, landing on its belly hurts him. Or a goomba-like dude where you can kill by jumping on its head but his face (if you're rotated 90°) can be used as a platform. Things like that.

Anyway, I should try some enemy coding soon, right now I implemented a suggestion made by Zorg. I gotta say, I think this one will stay in the game! it feels really fun to grab things and swing around and it does seem to make the gameplay richer.

In order to make the game easier to absorb, this will not be available from the start. At some point the player will find an upgrade (a denture for the worm, probably )

Here are a few gifs showing the new mechanic:

[JobLeonard]

AWW. YISS.

[diegzumillo]

Wooow! TWO updates in the same month!

This one is short though. I sketched the entire first world on my notebook. It will be 10 short levels and the main purpose of them is to teach the player about how the curved space works. So it's basically example after example. It also introduces dynamic objects, how each thing has its own gravity etc. Like this level, super straight forward,



I'm trying to define better what the other worlds will be right now. The second world already has a theme and some art done
and now I'm considering using this world to introduce enemies. I'll explore what can be done by interacting with them from different orientations to see what could be done with it.

I don't know the order of anything that comes after that, but I want a world entirely inside the aliens ship, which will introduce mechanical puzzles, buttons and levers etc. There will also be an ice world. The gimmick of the ice world is sliding around. This may sound trivial but I realized this has many applications with the game mechanic! Until now the game will mostly use 180, 90 and 45 degrees curved regions, with sporadic exceptions, but in the ice world the player will have to deal with curved regions that only incline slightly, defining which surfaces you can stand on without sliding.

So far that's all the worlds I have in my mind. I'm not sure when the grapple worm mechanic will be introduced yet.

[JobLeonard]

Please let the cockroaches be antagonists, but not evil.

[diegzumillo]

Oh no, they are super cool with apple and worm. Enemies will be... other things. I don't know how to insert them in a way that makes sense in the context yet.

[JobLeonard]

Yay!

[Columbus007]

Event though you started this a while ago hadn't seen this DevLog til today. It looks really lovely! I'm also working on game that changes gravity and orientation in Unity. Good luck!

[diegzumillo]

Thanks, Columbus
I'll have to remember to check back your project once I get home! it looks neat.

[diegzumillo]

THE WALL OF TEXT OF DOOM

The moment has come, ladies and gentlemen. Not the good 'the game is almost done' kind of moment, but the 'I have to rethink my life' kind of moment. This project has been stagnated for a while and I have finally had enough of it. So I looked at it in the eye and asked myself "if I had to start over, what would I do differently?" then I answered the question and started over. Well, not completely over.

I'm rebooting the development of this game. There are too many small things that are not fitting. Individually they can be overlooked, but when I take a step back the whole project looks hammered together.

There is one thing unifying all my problems: the main mechanic implementation. It's a simplification of the idea behind, that everything happens in a curved space. It comes across as a rotation mechanic to some and gravity shifting to others. I'm ditching the simplified implementation in favor of a more complete representation, that will come with additional information. The whole level will be on a mesh and the player will immediately notice the stretching and squashing on space and go "aha! I see what this is" which this game so desperately needs. It also comes with the scaling mechanic I tried to hammer in a while ago, but back then it would be another thing hammered in, now it's a natural consequence of the basic rules.

So now comes the matter of implementation. I'm between two possibilities:

a) Have everything laid out on the normal coordinate space. A level mesh defining vertices and polygons then is used to define local coordinate systems. If a point is inside this deformed polygon, its up, down, left, right vectors are transformed accordingly. This means that every collider must have its defining points carefully laid out across several polygons in order to maintain proper volume (as measured in local space, not the usual coordinate system). The bulk of the problem boils down to solving inverse bilinear interpolation.

b) Have the level be defined by square tiles and a graph connecting them. Then each tile has its own camera rendering directly to texture, which is rendered on a mesh that properly connects these tiles. I have to keep instantiating copies of these cells around the player cell as he moves through them, some cells will be instantiated in a different orientation or scale, but the player will remain always always on the same direction. The player will never see this boring grid of cells being instantiated with the player never rotating, only the rendered textures on the deformed mesh.

Idea b has the advantage of allowing me to use traditional methods of player control and physics. No messing with deformable colliders, no rotating things in uncomfortable angles. This all points to a very robust, bug free movement. The challenge is making the tiles connect perfectly. Clearly, I'm going to need to create perfect instances of these tiles under different orientation, so what happens in one happens in the other. But I can see how this can break easily with visual effects like particles or any screen based shader. It also limits the creation of objects that can exist across several 'cells', or whatever I'll call them, including basic terrain, it would have to be constrained to a grid. Also, I am not sure how to deal with the case of having the player on two cells that should be active at the same time. It's limiting, to say the least.

Idea a avoids those seam issues. The challenge is the local geometry calculations and making a reliable controller. Deforming colliders in real time is a huge red flag. Controlling an object with its movement constrained to local frames, always rotating and with its collider always changing is screaming BUG. My current simplified implementation took a long time to run smoothly (the demo is still awful), just to give an idea.

So I have to make a choice now. But I like how method a is inverse bilinear interpolation and method b is bilinear interpolation (done by unity's internal renderer).

[Zorg]

Good to see you back on the project again.



You are right, your game is currently about gravitation rotation. I imagine you are currently creating level sections (using meshes?) which have a different center of gravity? I'm really interested in how you'll implement the stretching and squashing of space, especially the transition from normal to curved space (upper right). Looking forward to your vision of this mechanic. Sadly i cannot help you with the decision nor implementation of (a) or (b) because i suck at programming.