LÖVE

Last night I quickly drew up a prototype main character. I like how he looks but I think he's way too big. I shouldn't have used the full 32 pixel height. I'll try to shrink him to 24 pixels high like Link was.

I want to add more animation to him. I really like the leg animation. It's hilarious. But I might add more in-between frames. I want swaying arms and bouncing hair. Also I'll be putting in idle animations with the eyes and head. He already blinks randomly. And to keep things simple I went with a Paper Mario style of only having a front and back view and just flipping it. Even though that kind of limits how the character looks when he attacks. I dunno.

Also, the bullets aren't really part of any gameplay, they're just leftover from what this started out as. I want the actual game to be more Zelda-like and have melee weapons and other kinds of weapons than just a sort of plasma shooting invisible machine gun.

I might make the trees only breakable with an axe item. I don't even know what I want the game to be.

Earlier I had experimented with "crops" that worked like Minecraft in that certain ground tiles would support plants that would grow randomly when the "tick" system randomly selected them to randomly grow. But I don't know if I wanted to have that kind of thing in the game. I also played with a real-time clock for use in an Animal Crossing style game, but the two together would contradict themselves. AC would have the crops all grow at once on map load based on "time since last visit" whereas the MC method has crops grow at random only when the map is loaded. But I didn't know if the map would always be loaded so what if you go in a dungeon? I decided it wasn't the way to do it. Any Harvest Moon style gameplay would use the AC style crop management. So I dropped the whole thing. The "tick" system is still in place though. Entities and tiles can have both an update and a tick function. Update runs every frame, tick ever 1/30th of a second. (MC uses 1/20th second increments)

I also want to experiment with a "redstone" style wiring system for stuff like the buttons and doors and other stuff. Right now it's just a direct activation or script-based system. You notice right at the start of the video, an enemy stepped on the button and killed itself.

I'll draw up some blobby enemies or something to replace all Zelda-stuff with original resources.

Jasoco wrote:-a super great looking game prototype

Davidobot wrote:-another beautiful game

Wow, you guys rock!

@Davidobot

Looks nice! A lot like Sheepolution's game

Jasoco wrote:stuff

I love the walking animation! The programmed animations are cool too.

Davidobot wrote:stuff

This looks really artistic, I like it!

Here's a ridiculous animation I've made today:

Picked back up on this.

-

How do you handle automatic tiles? Been trying to figure out a proper way to code an algorithm and work out the layout of the sprite sheet for choosing which edge tile to use.

Whenever a new tile is placed (so it only checks it during level editing, not on level load), I more or less use the same method as described here, though with some minor alterations. For slopes though, it checks the number of slope tiles to the right and left of the new tile, determines its position in the slope and adjusts itself and the other tiles accordingly.

Each tile in a tile sheet can also be given a list of tiles it's connected to the in the same sheet (for instance in that gif the slope and solid block tiles are connected, so the end result doesn't look like this), otherwise it ignores unconnected tiles when it does the autotiling check.

The auto tiling functions are swappable on the fly, so I can set them on project-by-project basis.

Yeah, I'd been Googling for some tips but I need an algorithm that accounts for more variations than just 16. In other words, one that also checks the diagonal catty-corner tiles as well.

Thing is I'm doing it for water tiles that can have so many variations and connect a lot differently than simple rock tiles since it can connect in so many ways.

So I'm working on an algorithm that has some edge cases. Hopefully it works. Right now it works fine for the 1-16 tile selections, but I'll make it then check for diagonals if the tile is a certain one. For instance, a screenshot of what works right now:



You'll note certain tiles don't have any corner pieces because the original algorithm is made for "inner edge tiles" as opposed to "outer edge tiles" like my water uses. So I'll try to add edge cases for specific tiles that have potential possible corner pieces. Like the tile in the center of the PLUS shaped pool or the two H shaped ones and the corners of the O shaped pool. Hopefully then I'll cover all bases for water autotiling. Edit: Haha, I forgot some cases in the screenshot above.

Fortunately when I do auto tiles for wall tiles, if I do, I will just be able to use the algorithm I have now. lol

For reference, this is what my Water sheet looks like. Notice all the variations required for proper water coverage:



(Before you ask, I just use a lookup table to convert the 1-16 number into the proper tile value where tiles are numbered 1-64 and just wrap. So the "center" tile, which is the blue square in this image, is considered 8 * 4 + 1 or 33. I do this because it's just easier to manage and standardize since there's so many and too many to just put all in a straight unordered line.)