next »

[Amirai]

Shards is a 2D HD rpg that is about reaction as well as action. Using a real time with pause battle system, instead of just getting hit by incoming attacks, players can evade or use them to their advantage. They can also interact with the environment and use nearby traps as weapons. This enables players to be creative in combat.

All of this happens in a somewhat Zelda-like world, with traps and such that players use their abilities to make their way past.

High resolution expressive characters help tell a humorous tale of adventure and love. The graphics above are in-game sprites.

Shards is still very early in development, but I've already got basic exploration working and the beginnings of the battle system.

I don't want to reveal too much about it yet, but I wanted to start showing stuff. I should mention though that due to health problems, it's going to take quite a while to make (as if games and RPGs didn't already take a long time to make as it is).

[Uykered]

Cool, looking forward to see how it goes, I'm guessing this is Loot Pursuit evolved?

[Amirai]

Sort of yes and no. The battle system is totally different from loot pursuit's, but its presentation is sort of similar and it builds upon what I learned making LP and addresses areas that I thought were a little lacking in its design.

This seems like as good a time for an update as any:

I've decided that I'm going to release the game in stages. One of the things I did with loot pursuit was never show it to almost anyone - this time, I'm going to show it much earlier.

Stage 1: prototype/proof of concept version
Stage 2: first section of the game
Stage 3: first third as its own game
Stage 4: second third
Stage 5: third third

Having a prototype will help me to make sure people like it and it's at its best. The game also really is too big to make as one game (at least for me with how messed up my hands are). It has 3 separate main arcs anyway, and each will be long enough for a complete game (small for an rpg, not like a hundred hours or anything, but enough), so it seems appropriate to make it a trilogy rather than one big game.

As for the game itself, progress has continued, there are new abilities, a new enemy, the characters can leave/enter areas, implemented the start of the tutorial system, worked on the ui, fixed bugs, etc.

I've still got a bunch to do before the prototype is ready - the game is quite playable as it is, but there isn't enough yet to give a proper impression of what playing the game will be like. The prototype is still months away from being ready, but I'll update again sooner when I have something else to show.

[Amirai]

Seems like as good a time as any for an update.

The level editor is coming along great. Stuff made with it is looking super awesome.

However, I've recently discovered that the game is kinda CPU intensive. This is a problem for my game in particular because of how I want the level itself to be able to be used as a weapon, and I want the players to be able to be clever and lure a difficult enemy into a trap that was a bit earlier in the level to defeat it instead of tackling it head on. This means as the players move from one room to another, the game has to keep processing what's going on in other rooms so enemies can follow.

I've been optimizing and have managed to double the number of enemies in an area from 50 to 100, though that will probably be reduced some later when the rest of the code is in there. Some good news is that's on an about ten year old CPU that I want to be the minimum spec (AMD Athlon 64 x2 4400+), and top of the line modern processors' single threaded performance is about three times that, so on even a midrange modern computer that should be more like 150-200 enemies or more.

This is still less than I hoped for the minimum spec (100 enemies in an area not enough? You crazy, Amirai?), but I think I can make it work, though I'll likely have to design a dynamic level loading system that loads sections of a level that are close and saves and deletes sections that are far. I have to be careful when doing that though, or an enemy could wander into a section of the level that isn't there.

I was hoping to avoid having to implement anything like that for the prototype, but to get a good idea of what the game is like it'll probably have to be there, though I have an idea for a 'cheating' version that will be less effective, but hopefully effective enough and far easier to implement.

I'm also beginning to doubt a design decision. I've made each unit use physics for its base, which works great for sliding objects along obstacles and allows me to make cool swarms like this:

However, doing do ups the CPU use, especially since I discovered chrome/node webkit doesn't actually support asm.js for accelerated physics, and I'm not sure it's worth it. I'm going to have to debate it for a while. Perhaps if I'm clever, I can set it up to make it so I can turn on physics use when I want swarms and leave it off otherwise, but then players might wonder why enemies can move through each other sometimes and not others. I'm not sure it's a good idea to be inconsistent on that matter. Hmm, maybe I can dynamically turn it off or on depending if an object is overlapping another or not. Gonna have to play with it a bit to find out if that's effective or not, or even necessary with a dynamically loading level.

[alvarop]

Is Loot Pursuit cancelled or you're working on both projects at the same time?

[Amirai]

It's on hold. I still want to complete it at some point, but I really needed to take a break from it.

[Uykered]

That's cool, but if its easier you could always just go for less but more significant enemies.

[Amirai]

Shards update

So I wanted the player to have the ability to run from an incoming attack, and hide behind an enemy to have that enemy get hit instead. It seemed like a good idea at first, until I realized that when enemies are bunched up they can be significantly more dangerous to each other than the player is, especially when they're using area affect attacks. So dangerous that it's too significant of an advantage for the player as they blow themselves up.

To negate this, I'd have to at least implement line of sight for the enemies, which isn't a problem, but it would still be a pretty 'stupid' check because I'm not good enough of a coder to write an ai that'll check what units will be in the way by the time the attack gets there (especially since units change their minds about what they're doing frequently), so I'm thinking that's one feature the game is going to have to go without.

I've also managed to make a dynamic system that turns physics on and off depending on unit's distances to the next closest unit. I think it's the best compromise of having physics and performance I can get.

The combo mode is implemented!

You can now string attacks together, unpause the game and watch them play out. Alternately you can leave combo mode off and input them one at a time for one click command input and resuming of action (I've been trying to reduce the number of clicks needed to as few as possible to streamline the ui).

In a lot of RPGs, there are abilities you can select from a list which are essentially a string of attacks that play out exactly the same each time. That doesn't give the player any interesting choices other than the initial choice of using that combo rather than another.

There are games out there that let you make your own combos, but in the ones I've seen there isn't much difference between which attacks the player uses. A punch will do damage, and so will a kick.

In Shards, you get to make your own combos, and each move has its own advantages and disadvantages. Normal attacks are quick but weak. Spin slashing hits in 360 degrees, but uses more sp and has a higher recovery time, which isn't good if an opponent blocks it. Hitting harder causes more damage and knocks the enemy back, but isn't as quick to hit with, uses more sp and has a higher recovery time.

Advantages and disadvantages to each, and no one move is always superior. Interesting choices!

Next step

I think I'm getting close to the point where the game is ready for a first video, I just need to fix a few bugs and make some animations so the characters aren't performing all their actions in the same pose.

[Amirai]

Heroes ready for battle

[Amirai]

Small update - Shards wasn't playing as well as I wanted it to, so I'm reworking it. Like usual, all of my estimates for when it'll be ready for presentation are way off.

I understand now why so many game developers often don't innovate much. It's really hard to get right.

[alvarop]

Just out of curiosity, is this because of Construct 2 performance issues?