Thief of Vallas -- [12/13 Now with Level Editor]

Muybridge's animations seem to be a good resource for help.

That looks like an amazing resource. Thanks for posting it

That looks like an amazing resource. Thanks for posting it

There's also http://www.muybridge.org, and a book--which I might go pick up. I think they'll certainly save me a lot of time.

I now have a working demo! You can check it out here:

http://www.stencyl.com/game/play/28644

The core mechanics are working (although not perfectly), and the first level is entirely playable. Check it out! -- and please let me know if there's anything that is frustrating, or just doesn't work. Feedback always appreciated 

Known issues:
- Some of the animations don't line up well. They're already scheduled to be re-drawn.
- I'm planning to include a map feature. The level in this version of the game will probably not be in the final version at all
- If you get stuck, press ESC to kill yourself. Please let me know if that happens -- it shouldn't be possible!

Some more hints:
- You start on level 2 of three levels, more or less in the center of the dungeon.
- There's a particularly tricky jump on the far right of level 1 (where the switch is). It's harder to leave the platform with the switch, since the ledge isn't long enough to get a good running start. This is a good spot to save your game.

In the final version, there won't be a time penalty for saving. You'll be able to save at specific, set points with no penalty. Nothing happens if you run out of time in this version -- you just get bragging rights if you finish with more than 30 minutes to spare

Hey!

i have one feedback which i think is crucial for the game:
It takes too much time when i press left or right till the player moves (especially in a game whihc is about pixel precise jumping).
The "start walking" animation makes the game very difficult without the need to.

Keep up the good work!

Hey!

i have one feedback which i think is crucial for the game:
It takes too much time when i press left or right till the player moves (especially in a game whihc is about pixel precise jumping).
The "start walking" animation makes the game very difficult without the need to.

Keep up the good work!

Thanks for the feedback! This was the sort of thing I was hoping to get smoothed out. In this version, the character doesn't start running until the start of frame 4 in the running start animation. The default frame rate is .125 sec, so there's an almost half-second delay between pressing an arrow key and the start of any motion. Changing the motion timer to start at the beginning of frame 2, instead of 4, seems to make a big difference. The change will be in the next demo.

Pixel-precision is something I'd rather avoid. With any of the ledges, if you jump too late, you'll trip and fall off, with no possibility of being able to grab onto a ledge.



It seems like too stiff of a penalty, since many of the ledges require jumping at, or near, the end to make it to the other side.

In the next update to the demo, I'm planning to roll out a fix to this issue... which should make jumping across wide ledges much easier.

Each ledge is identified by an actor, whose original purpose was to detect the player's hands. When the player contacts the ledge, and her hands are active, then the player will "stick" to the edge and the climbing animation begins.



Since these actors identify every edge, it wouldn't be too hard to delay the actual jump action until the player is at the very end. If she's close to the edge (colliding with the top of a ledge actor), she'll keep running until she actually gets there, then jump.

This should give the player at least a one-half to one second window to make a "perfect" jump.

I don't know if you have to do too much to fix it. You were going for Prince of Persia and this game totally reminds me of it with how the movement plays out.

I don't know if you have to do too much to fix it. You were going for Prince of Persia and this game totally reminds me of it with how the movement plays out.

I think most of it's there. I'm at the point where I'm making little tweaks. It's incredibly tedious, and it doesn't help that there are 246 "preps". I have a fairly high-end computer, and it still takes a while to compile + test.

At least it -is- coming together I've already found (and squashed) a few bugs and issues since putting the demo up:

- The jump key is now more responsive. I actually don't think delaying the jump is the right move (for now, anyway). Instead, I just cut the delay. Instead of the jump actually occurring on frame 4, it now occurs on frame 2. The way the collision bounds are set up, this means as long as you look like you're on a ledge, you won't trip. Also:

- Grabbing ledges is more reliable, now. It's now easier to recover from a missed jump

- Occasionally, it was possible to jump "into" the wall. It's easiest to make this happen in the demo if you move to the room 2 spaces to the right. It's a room with a "TT" structure that was pretty much only built to test ledge climbing. If you take a running start from the left end and jump from the right end while holding RIGHT, you'll probably slip into the wall.

I reached a lot of dead ends searching for a possible reason in the Stencyl forums, until I found the problem. Here's the fix, for the benefit of giving anyone with a similar problem something else to try: Between certain animation states, the size of the sprite changes. It just so happened the change from "running jump" to "landing" caused the collision box to shift -into- the wall! Making sure the collision boxes lined up for every animation fixed this quirk.

I haven't looked into it too much, but maybe have a pushback when a collision occurs like that. The tricky part would be not having the pushback also happen when jumping a pit and hitting a ledge on the other side.

I haven't looked into it too much, but maybe have a pushback when a collision occurs like that. The tricky part would be not having the pushback also happen when jumping a pit and hitting a ledge on the other side.

Lining up the collision boxes did the trick. One problem solved!


I think I've finally settled on a Metroidvania-style game... it seems better suited toward a game based one exploration. The trick will be to divide the entire map into regions with increasing difficulty. I have a rough layout, and started designing the first zone. There will be about 7 zones total, joined together by tunnels that form a sort of web.

To help the player navigate, I've created an auto-map. The map fills in as new rooms are explored. Since I'm primarily focused on the code right now, the interface isn't much to look at -- but it works! The auto-map also correctly indicates which rooms are connected to each other.

the interface isn't much to look at

I think it looks pretty cool how you have it. That is a standard look for that kind of genre. Any player who fiddled around with a metroidvania game would be able to look at it and understand what it means. Isn't that the point of the minimap?

the interface isn't much to look at

I think it looks pretty cool how you have it. That is a standard look for that kind of genre. Any player who fiddled around with a metroidvania game would be able to look at it and understand what it means. Isn't that the point of the minimap?

True   What I originally wanted was for the map to consist of an array of miniature versions of the actual rooms. The first time you enter a room, the game would save a mini-screenshot in a 2D array. In order for saving to work, though, I can't save the images themselves. I can think of a few other ways to make it work, but at some point I'd have to ask myself if I'm really spending my time wisely. There'll be more time for detail once the big picture is in place.

So I've hit a bit of a brick wall with no ideal work-around. It doesn't appear feasible to create a game both on the scale I've envisioned and within a reasonable file size.  I've already hit 19MB with compressed graphics and almost no soundtrack. I found a few easy MB I could remove, but there's also at least 200 more rooms needed, a few more tilesets, etc., which would probably fill that space back up. There's also time. I need to get this project done, so I can move on to something else.

That leaves me with a couple of options.

1~ I could just scale everything back.

2~ I've been playing with the idea of turning the game into a rogue-like.

This is the plan I'm leaning (slightly) toward. If the game play proves fun, I can more easily justify spending the time to create the original, larger game. I also already have working maze generation code (that I used for "Caverns of Io"). Coincidentally, as I was mapping the first level in "Thief of Vallas", I noticed how similar it looked to some of the levels in "Caverns of Io"




The game would be similar to that of "Rogue" itself -- descend deeper into the dungeon, seeking gold and facing increasingly tougher foes.

I'm still not completely sure. The levels in "Thief of Vallas" have numerous constraints. Most notably, falls from two or more floors penalize the player. It's also more difficult to go up. There's also shadow generation, which would have to be done procedurally--instead of with actors, as is done now. On the other hand,  "cinematic platformer roguelike" is a fun combination of words.

I would try out doing the full version of the game and release windows and mac standalone versions. You can always add lower res graphics and take out a few levels later on to port on other platforms.

I would try out doing the full version of the game and release windows and mac standalone versions. You can always add lower res graphics and take out a few levels later on to port on other platforms.

Since the game isn't divided into "levels", (rather, one large, connected world e.g. Metroid) I'm not sure how much I could take out without designing a whole new map. I thought about making a simpler flash version that's a whole different game, and serves, in part, to point people toward a downloadable full version. I'd really like to use shaders, for instance, so there are some advantages to this approach. The simpler version was essentially what I was describing above--although it would be easier to make a simpler game with a static map rather than a generated one.

I'm still not entirely sure on the direction. My primary goal was just to see if I could create the movement/animation behaviors. Now that I have a result I'm actually pretty pleased with, I'm giving more attention to the game itself--and what could be most fun to play (and for me to create)

Replacing the solid color backgrounds seems to be an improvement. Here's a room with a few lighting effects. Now, it just needs some contents so it doesn't look so empty.

I had to step away from this project for a bit, but I've recently had a chance to make progress--most notable of which, I've added a level editor!



The level generator still has a few bugs. The shadows, for instance, don't always draw properly. But the editor works! You can test it in the demo. One major caveat is that it's not very user friendly, yet. The tiles have little tooltips, but the editor does not catch any mistakes. For instance, the tile called "solid wall" does not define a walkable surface. To have a real floor, any tile with a black underscore _ must be placed.

Also, if you place a gate, there's no way to place and configure a switch. So, gates are just fancy walls for now. 

Commands:
Press "1" to load my level.
Press "C" to copy your level to the clipboard. You can then paste the data in a text file. (At the moment, there is no load functionality).
Use the arrow keys to scroll.

In the game, you can press shift+K to kill yourself. You can also press "3" to open all gates.

One chore I've been putting off for a while is redoing the character art. The existing sprites are mostly throw-aways from another project. I think it's about time to work out something more permanent, and not take so many shortcuts. There are about 300 frames total, but many (more so than I'd like) are duplicates.

Here's one draft that's based off of the original.


I also started making new terrain.