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

0 favourites
From the Asset Store
Perfect, complete, easy to use to use, out-of-the-box inventory system
  • I've already started on it but my first attempt wasn't very clear. I'm redesigning it to be much more readable.

    I look forward to seeing how it will look like once it is finished

  • It's cool to see you're still working on this!

  • Update - here's some of what I've been working on.

    Magic bolt

    Ria's basic distance attack. Doesn't use much stamina, so it's useful for a quick shot to stop an enemy. Stronger enemies will need to be hit harder to knock them out of their attacks.

    Ria's explosion spell

    KABLOOEEYY

    3D collisions

    This gif shows how the units collide in 3D despite being a 2D game. They technically collided in 3D in the explosion gif too, but it was pretty inaccurate and I came up with a much improved method - enough so that I should probably redo the gif.

    Other new features this update: There's new arrows while paused showing what the object's movement is, I used some free textures to improve the graphics, there's text at the mouse location showing what a click will do and I shrunk the HP/SP bars because they were blocking the view of the units entirely when they were bunched together. One downside of improving the graphics though is that gifs of the game are way larger. Not that it matters much for those on broadband, but those on mobile can get slammed by them, which is a big part of the reason why I'm keeping the frame rates as low as possible while still conveying the action properly. It's frustrating that there's still no universally accepted successor to the gif. :/

    There's been a lot of other progress too, new abilities, items and enemies. It's still a ways off from being ready for people to play, but it's getting relatively close to being ready for me to make a video of a battle which will make it much clearer how the game mechanics work (if you ignore the lack of a level and other such missing content).

  • Combo mode

    In a lot of games you can select a combo attack from a list and watch it play out the same every time. In Loot Pursuit, you get to design your own combos from the moves you already have. This enables greater variety of gameplay as the players can utilize their moves however they want.

  • so cool, I really enjoy the animations and the mechanic of the game looks pretty awesome!!

    Congratulations :3

  • It's looking great! Really nice mechanics!

  • 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?

  • 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:

    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.

    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.

  • Ah, can't believe I missed that. I am mesmerized by your warp crystal animation, is that particles?

  • Paradox Thanks. They aren't particles, I used a bunch of normal sprites so I could have more control over how they behaved.

  • These 3d effects looks really cool. How was the approach? Instance variables to determine their state?

  • 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.

  • Arima Nice! I hope it's worth the effort of simulating this 3D effect. The combat looks really cool and different.

  • bump

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • is the development still on-going? Arima

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)