Loot Pursuit (Zelda/Grandia/Mario hybrid RPG) 9/29 update

Show us your works in progress and request feedback

Post » Thu Sep 29, 2016 11:27 pm

It's looking great! Really nice mechanics!
B
103
S
38
G
19
Posts: 962
Reputation: 17,996

Post » Sat Nov 05, 2016 7:49 pm

Any playable demos in the works? it's gorgeous.
you may consider slight floor texture, not enough to muddy screens full of action, but enough to prevent the illusion that characters are drifting on camera movements. (that may just be the GIFs, playing it may be clearer.)
Maybe more immovable objects, or holes/grates in the floor with some parallax would be cool. But I imagine you are still planning that, with the traps and such.
Will there be parties with more than two characters?
B
240
S
62
G
33
Posts: 903
Reputation: 40,589

Post » Fri Nov 11, 2016 9:53 am

@Paradox

Thanks! I'm going to make the proof of concept demo public. It's quite playable already, but the main issue is a lack of content - it doesn't give a good idea how anything past a single battle would play, and the game is supposed to be much more than that. Still, it might be a good idea to get incremental feedback so I might change my mind, but at bare minimum I need enough of a basic level to have a tutorial explaining how to play.

As for the floor, I did add the checkerboard texture in the most recent gifs on page 2, I'm not sure if you saw them. In retrospect, I should have added it before making those first gifs.

There is going to be lots more stuff in the levels, but I've actually already got holes in the floor implemented:
Image
Hitting an enemy into a pit instantly defeats them, but enemies can hit player characters into them too, and if I can figure out how to code it, the more intelligent ones will try to do so intentionally. This gif also shows how aim is important, or you can blast an enemy straight over the pit entirely.

Player characters and some bosses have warp crystals to protect against threats like these. Warp crystals can be used once and automatically teleport the unit back to the spot they last executed a command, make them invincible for short time and might restore a little HP and SP, as shown here with a new enemy: the wizard slime, which shoots magic bolts and explosion spells.
Image
Some enemies can't be hit into pits, mainly the ones that fly.

As for party size, most of the game is designed for two characters with an occasional third joining in. The reason for that is because of how all the action happens simultaneously - it would just be too much to keep track of at once with any more.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Sun Nov 13, 2016 5:33 am

Ah, can't believe I missed that. I am mesmerized by your warp crystal animation, is that particles?
B
240
S
62
G
33
Posts: 903
Reputation: 40,589

Post » Sun Nov 13, 2016 9:41 am

@Paradox Thanks. :) They aren't particles, I used a bunch of normal sprites so I could have more control over how they behaved.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Mon Nov 14, 2016 2:29 am

These 3d effects looks really cool. How was the approach? Instance variables to determine their state?
B
56
S
21
G
3
Posts: 602
Reputation: 6,612

Post » Mon Nov 14, 2016 8:29 am

@kossglobal To get the 3D effect and collisions I use the three objects - the first is an invisible base that represents the ground location. I put it into a family with only itself, and all variables and behaviors given to the base have to be given through the family. That makes for easier picking when comparing one base vs another. It has the variables z and zmodifier, which controls the elevation and speed on the fake z axis. There is an action to subtract the same amount from zmodifier every tick that simulates gravity.

The second is the object itself. It's placed at base.x, base.y-base.z. Likewise, all variables and behaviors should be applied to this object through a family.

Third is a shadow sprite placed at base.BBoxLeft, base.y and the width is set to object.width. If you don't care about the shadow being accurate you can make the base be the shadow instead.

All the objects have the UIDs of the objects they're paired with stored as variables (base.objectUID, object.baseUID, etc). This is necessary for the collision check.

To check for collisions in 3D space, check if base is overlapping basefamily. If so, then as a subevent, for each base check again for collisions with basefamily. That will pick the specific bases that are colliding. Then pick the objects the bases are paired to via the stored UIDs and check if they are overlapping each other. If they are, that's a collision in faked 3D space.

The method isn't perfect alone because it's faking 3D. For example, if I have a laser beam that's one long sprite aiming from high to low elevation, but visually is shooting up or down, it'll register a hit in places where the laser should have missed. To rectify that problem, all that's required is breaking up the object into multiple smaller pieces to check collisions with.

I hope that's clear -- it is some complex picking and collisions, but it works great.
Moderator
B
95
S
34
G
33
Posts: 3,007
Reputation: 27,876

Post » Thu Nov 17, 2016 1:47 am

@Arima Nice! I hope it's worth the effort of simulating this 3D effect. The combat looks really cool and different.
B
56
S
21
G
3
Posts: 602
Reputation: 6,612

Post » Thu Dec 29, 2016 2:37 am

bump
B
5
Posts: 1
Reputation: 229

Post » Fri Oct 20, 2017 9:22 pm

is the development still on-going? @Arima
B
34
S
6
G
2
Posts: 242
Reputation: 3,038

PreviousNext

Return to Works in Progress/Feedback Requests

Who is online

Users browsing this forum: No registered users and 4 guests