next »

[William Chyr]

I like the visuals that Idea 1 bring to my mind, especially having incomplete robots on the first level, and assembled robots higher up that fight you. It brings to mind the area in Portal 2 where you see turrets being assembled.

However, I think Idea 3 would be a more fun boss fight. I may not have the right idea from your description alone, but I'm imagining having to stay on your toes the whole time and bouncing around the room trying to fight the robot. From a gameplay standpoint, this seems very promising.

[Erichermit]

Congratulations on getting funded! :D

[Juan Raigada]

Thanks everybody for the feedback. Gameplay wise, the jury's still out, but thematically it seems idea 2 is getting a lot of support...

Oh, and if you wonder were the new influx of backers to the project came from, it's from an update the nice guys at Mighty No. 9 did!!!! They have been awesomely nice to us...

[Daniel Pellicer]

I like the idea number 2. It express more for me. This image also remind me to the arachnid first boss in Secret of Evermore for Snes (The Package of the game was showing a simmilar perspective )

Also, congratulations on funding the project!

[Juan Raigada]

I like the idea number 2. It express more for me. This image also remind me to the arachnid first boss in Secret of Evermore for Snes (The Package of the game was showing a simmilar perspective )

Also, congratulations on funding the project!

Yes, number 2 is the clear winner, at least in terms of how it will fit into the game. We are starting to brainstorm this more intensely now.

[Juan Raigada]

On other news: Now that the Kickstarter is wrapping, it's about time for me to get back into full-developer mode.

A couple of things are happening right now with the game code, and I will write about them below, but first I wanted to ask you guys what you would like me to talk about. There has been some questions about the player-enemy interaction (how the moment-to-moment gameplay is programmed), and some other people were asking vie email on the Kickstarter process. There might be some other stuff, though, but since I want to write a longish post per week on an specific subject (so I can also mirror it on my blog), I thought I'd rather ask here as to what you guys want.

And now, back into the game:

Weekly progress update(1 of ?):

Although I have been working on the Kickstarter, Kike, the new programmer (I have to get him to write here more often  ) has been working on some backend stuff. We have localization support (we might need more specific code later, but it works), a new 3D minimap, and most of the GUI ported to nGUI (we are finalizing this).

But other than that, two things have changed in the game.

The first one is how the weapon upgrade system works. Those of you who have played the alpha will remember weapons have 4 levels (the starting one and three other levels you unlock sequentially). This was workable, but had several drawbacks. The main of which is that it didn't give the player enough choice of what to upgrade. Actually, because the player could not choose the upgrade order, most upgrades had to do several things to keep things balanced (so every upgrade would increase speed and damage, for example, but at different values). This meant the player sometimes didn't have enough feedback as to notice what changed.

So we decided to have a new upgrade system. Now, weapons and parts can have any number of upgrades (from 0 to infinity, but most likely 3 will be the highest number implemented) and the player can select from those upgrades when leveling up. This opens possibilities a lot, although it broke a lot of code and balance already done, and I'm in the process of setting everything up so it's sensible again.

The other big change we have is how damage is dealt. In the alpha I was using a float to store damage, and the multiplying that float by the resistances of the character or monster to get the final damage amount. But this gave us monsters that took WAY too long to kill with certain weapons. So long that some players though they weren't even making damage.

Part of it is that we lack certain feedback for the combat system. Specifically, enemies need to "blink" on hit, and when hit by something they are weak to, extra particles need to give visual feedback of the weakness.

But the way damage worked was problematic, so we moved it from floats to int. That means we have much less granularity now, with the weakest attack doing at least 1 point of damage, and enemies (at this time, we might rebalance) having, at most, 10 health. Resistances work subtracting integers from the damage, and weakness adding those integers. Also, right now, every strike, regardless of resistances, deals at least 1 damage. This has made enemies very brittle, since even the hardest enemy doesn't take more than 10 hits now. No weapon is really weak, although some weapons can be VERY strong, specially if leveled up and used against a weak opponent (many of one hit kills in that case).

Of course, I can still balance the new numbers towards something closer to the alpha (making the integers high enough will give be more granularity) but for the time being I'm enjoying this new flow of combat.

There are three more code-intensive tasks to finish before we enter full content production, but things are looking up. These are:
-New unified shader to finalize the game's look (and allow enemy "flashing" on hit.
-Rewrite of the (too complex) combo system to allow for cleaner and more intuitive combos and canceling.
-Rewrite of the input system (probably using inControl) to nail down some of the outstanding bugs in that area.

I will write posts about those as we engage them. There are many other minor things (like improving the camera and the platforming) but overall we are close to have a fully working system.

[Juan Raigada]

Weekly Devlog Update (2 of ?):

It feels good to be writing these again.

In the morning I did some KS related tasks and had a meeting with our sound guys. We want to have a new alpha build ready for Indiecade submission, so we need to start organizing ourselves.

During the afternoon I finished rebalancing/bugfixing all weapons and enemies. Only bodyparts left, which I will do tomorrow (should be easier now that most new bugs are fixed).

So let me talk about what I'm doing next:

The modular nature of Heart&Slash means a lot of systems need to work with incomplete information of what's really happening. That is, we need very emergent systems, and not a behaviour that reads specific states.

As an example, when I was creating the player states, I differentiated into generic "type"of states (walk, run fall, hitstun, knockdown) so the the game can select the appropriate state to the behavior we want from all the states available on the equipped parts (that is, if the player has three parts with different "fall"states, it needs to choose one of those when another state calls for a "fall").

The generic state was called attack, and up until very recently, this was a good enough distinction.

However a couple of bugs have come up when coding more advanced enemy behavior. Specifically, SmallBots with a shield will try to block every time they detect the player is doing an "attack". However, since "attack" is too generic, that meant they also blocked (and stopped moving) when you were aiming a gun at them. Or even worse, when you were blocking yourself.

Another bug related to this distinction is the cancel system. Since attacks were too generic, each state has a list of other states it can cancel into. Which is a problem as it creates a lot of work as the game grows, and means configuring (for example) each attack to cancel on the 5 different kinds of evades we have implemented right now.

Obviously this needs fixing. But there's another thing that needs fixing, and it's very related to this issue.

It's the combo system. Not really the pure input system (the way we read the physical inputs. That has bugs, but they are localized). No, the problem is that I overdesigned the combo system to accept "input chains", like a 2D fighting game. While powerful, this approach is never used (the most complex input I have is two simultaneous button presses) and again it requires every attack input to be specifically assigned to every attack state.

Obviously, I need to create a generic framework that simplifies both these systems and allows us more control and easier debugging. What we have now is starting to feel unmaintainable, and needs to go...

This is the plan:

I will divide the standard attack type into
    BLOCK
    SOFT_ATTACK_GROUND_INITIAL
    SOFT_ATTACK_GROUND_MIDDLE
    SOFT_ATTACK_GROUND_END
    HARD_ATTACK_GROUND_INITIAL
    HARD_ATTACK_GROUND_MIDDLE
    HARD_ATTACK_GROUND_END
    EVADE
    SOFT_ATTACK_AIR_INITIAL
    SOFT_ATTACK_AIR_MIDDLE
    SOFT_ATTACK_AIR_END
    HARD_ATTACK_AIR_INITIAL
    HARD_ATTACK_AIR_MIDDLE
    HARD_ATTACK_AIR_END

Then I will give every state a simple input trigger (a button mask, really) and the cancelling will be solved using that list as a priority. Each state can cancel into states with the same or higher priority, following the order of the list. That way every ground attack can always be cancelled into an evade.

In the case of conflicting inputs, the higher priority state will trigger. If the priority is the same, the conflict will be solve by part priority (right now, from lower to higher priority: LEGS ARMS BODY HEAD WEAPON).

Finally, each state can have other specific states it can cancel into (for special combos) which will override regular priority and a SPECIAL attack type will be implemented but left out of the cancellation loop (so I can override this generic system if I need to do something like an attack that can ONLY trigger after another specific attack).

This means most weapon combos will be 3 attack long AND that you can do weapon-switch in the middle of a combo (which can bring more expression into the combat, I hope).

It's going to be quite the undertaking, but at the end we will have a more solid system behind the game, and we will be able to progress faster...

Let's hope tomorrow I can get started on this!

[Lucs]

Next scretch goal is possible!   
How many pledges via paypal are there ?

[Juan Raigada]

Not that many    it's at $55 right now.

But miracles can happen.  We are certainly trying!

No matter what, it's been an incredible campaign and we've been extremely lucky in getting the support of so  many backers!

[Juan Raigada]

Weekly Progress Update (3 of ?):

Spent the morning doing company management stuff. There's a lot of things that we need to change now that the Kickstarter is complete. Yesterday I cleaned up some GUI code. Almost all original GUI code is now replaced by nGUI, which will help us greatly with performance in lower end systems.

Today I will start coding the above change to the combo system.

Also, we need some Greenlight love. Although the KS was extremely successful, Greenlight is marching slowly, and we don't really know why (the mysterious ways of internet, I guess).

Any suggestions as to how to improve our visibility would be great.

[Fervir]

Just saw your greenlight trailer.
Looking great! Hope you guys get greenlit!

[Elideb]

Weekly Progress Update (4-9 of ?)

Wow! That took long enough.

It looks like we've been consumed by the project. In the last weeks we have been hard at work in, unfortunately, lots of things not directly related to developing the game. But the good news is AHeartfulOfGames exists as a company! We also got the KS funds in the account, so next week will be signing contracts, paying advancements and other not so interesting stuff.

All that has taken a lot of time out of Juan's hands, but we've still managed to make a lot of progress.

- The artists are now producing lots of great new art and animations (you'll get a glimpse in one of the next updates, but believe me: the game looks better than we could ever hope). Integrating all these is the most time consuming task we have, right now.

A small new room

- The sound team have a lot of new audio ready. We have to improve the audio pipeline a bit, so they have an easier time integrating stuff and iterate over it faster.

- The new combo system is working, and is easier to configure than ever. That's good, because the new animations are different for each weapon and many of the combos have to be reconfigured.

A preview of things to come...

- The whole interface is now done with nGUI. It took a lot of time, because every menu had to be rebuilt, as well as many of the textures. Also nGUI is not prepared for interfaces as dynamic as ours can be, apparently, so I had to add a considerable amount of functionality to it (I have to see how to release the game independent parts as open source/asset store without getting in trouble).

The new upgrade menu

- Juan has implemented a cool new trick: the weapons can now have their own bones and be animated. That means we can have whips, nunchaku or a daishô (duo of a katana and a shorter wakizashi). Maybe even something like Oddworld: Stranger's Wrath live ammo (but that would be a lot of work!).

- The input system has been completely overhauled. It is multiplatform (tested in Linux) and works properly even at very low framerates (15fps). We are using InControl to manage gamepads, and I have created an abstraction layer over it, so we can manage a single action through gamepads, keyboard or mouse. It is now a lot simpler and cleaner to use and modify than the old version, so we can test new control ideas with ease now. I'll probably contribute these as open source, too. I am also planning on improving support of unrecognized gamepads, so anyone can create a configuration file for obscure pads. I will send that to the InControl team as soon as I have it working, so everyone can benefit from it.

Click to see bigger versions

Our schedule for the IndieCade submission is tight, but it looks like we'll have a cool new build for them. We plan on releasing that publicly, too, so you can check how it all is coming together.

I'm probably missing something, but that's enough for now. I'll try to write a post about the InControl and nGUI integration process, and we'll create a new one showcasing the new art and weapon combos.

P.S.: By the way, the Greenlight is going slow, but keeps progressing. Dead Synchronicity, done by another team from Madrid, was greenlit in the last batch, and we hope to join them soon.

[Elideb]

Weekly update (10 of ??)

This week has been a little short, because most of the team used Worker's Day as an excuse to go out on trips. However, we managed to include some new stuff in the game.

- A whole set of the new rooms is now in the game's level generation system. They are still missing variations of architecture and decorations, monster spawners and such, but things are working and looking fine.

- We have implemented the Game Over screen (pretty placeholder-ish), with a quick replay button and tips.

- We are also testing a new feature: every run starts with as much experience as you had when you died on your previous run. We don't know how it will work out, but the idea is to help players fast forward through the initial parts of the game once they manage to get to later levels.

- The game now supports custom configurations of gamepads, so players can specify how a non-standard controller maps to a Dualshock 2-like layout. It is not of much use currently, but it opens the door to input presets, even for non-standard pads.

- Juan participated in Madrid's half marathon and completed it in 2:04. Quite impressive, considering how many hours he spends every day in front of the computer!

This week shall be content integration week. We'll get all clicky-clicky in Unity, draggin'n'droppin' prefabs and MonoBehaviours all around the place like crazy.

Have a great weekend!

[Juan Raigada]

WARNING: HEAVY IMAGE LOAD

Well, hello there:

It's been a while since I posted, but Kike kept the torch alive.

THESE PAST FEW WEEKS:

What has happened is that this project has gone from being a one man show to being a proper project, with extra levels of management needed, as well as some paperwork.

After the Kickstarter, the first few weeks were about setting up the company proper and finishing up on the codebase rewrite (that's now finished, thanks to Kike). After that, we needed to establish a working pipeline with the new collaborators/co-creators of the project, and I knew things would start slow.

Fortunately, the Indiecade deadline was looming, and that gave us the push we needed to get things figured out fast, and yesterday, we submitted Heart&Slash to Indiecade. Fingers crossed, it's gonna be tough to get noticed among all the high quality indie games out there.

OUR CREATIVE PHILOSOPHY:

But today I want to talk about our process and where Heart&Slash is going now. Thanks to the amazingly successful Kickstarter (oh, I learnt so many things while it was ongoing...) Heart&Slash has grown. Most of you who have been following the game from it's inception know that at the beginning (up until the Kickstarter, really) I was doing everything by myself. but the problem is that, even though I can code, I'm not a programmer, and even though I can model and animate, I'm not an artist.

But most importantly, if you are busy doing too much stuff, you have no time to think.

That meant that the fine grained design of the game was happening subconsciously, since I was working without a plan or a goal.

Of course, now this has changed, and we have a fully working process set up. But most importantly, it's not me designing alone anymore.

One of the things I have always believed is that authorship of a collaborative work needs to be shared. That even though there needs to be a guiding lead, so that things are kept consistent, creative works benefit from the creativity (not only the work) of as many individuals as possible.

Thus, once it was time for the artists to start delivering work, we decided they would be given freedom to design how certain things worked (of course, under supervision and discussion).

You already have seen (in Kike's post) some of the new art for the rooms, but today we are going to talk about something more fundamental, the weapon animations. This is where the most radical design change has occurred.

First, lets see how things were. As you remember, all five sword in the Kickstarter Alpha (the last version with my content on it) has exactly the same animations (just timed differently). This was the basic combo:

Now, artists being artists, they were unhappy with all the sword sharing the same animations, so they decided to spice things up a bit. The first thing they submitted were these two sketches for the Volt and Fire Slicer:

Which, of course, I thought they were really cool.

Then they did 3D versions of these so I could bring them in game:

And finally, this is how they look in-game now:

And the most amazing thing is that this has been done for every single weapon that we had in the game. All 35 of them!

Which means the game plays nothing like it used to.

COMING SOON:

So what's next, then? Well, right now we are in the process of re-integrating the new art and substituting all my work with the new one. Weapons are mostly done, as are rooms and scenery, but we still need to change the enemies. In fact, now that the weapons are faster and deadlier, enemies and completely out of balance (some are too hard, some are too easy). things like interruptibility thresholds for the attacks, and timing, need to be rebalanced against the final weapon behavior.

After that (we project 2-3 weeks) we'll release a public build that will serve as a comparison of what the Kickstarter did to the game. The previous buils was what the game would have been had I had to work on my own, while the new one will show what the game will become now.

And starting June, we'll begin with brand new content, namely, the design for level 2 and the simplest Kickstarter weapon designs!

Stay tuned, since I'll try to post here weekly (but forgive me if sometimes I cant't!!!).

EDIT: BTW, I'm bumpiing the completion rate to 30%, since that's where we're at now!

[William Chyr]

Love the new sword animations! You can really feel the weight of the weapon just from the movement.

Great to read this update. Sounds like the project has really gained much more momentum.

[Juan Raigada]

Love the new sword animations! You can really feel the weight of the weapon just from the movement.

Great to read this update. Sounds like the project has really gained much more momentum.

Not so much as gained momentum as pushed down a reaaaaally steep slope!!!! 

But yes, going from a one man project into a decent sized (if still really small team) does mean we can't just stop to contemplate things any longer. The team will only hold together for so long (as long as money and motivation allows) so the game now has a deadline it needs to be finished by!

[Juan Raigada]

Hello again.

NEW (OLD) ENEMIES:

I meant to write on Saturday, but I got a virus that left me mostly bed-ridden during the weekend. All is fine now.

Last week I wrote the same update here and on Kickstarter, but this time it will be slightly different.

See, the post today is about the new art. Since some of you who follow this are also developing a game, and some expressed interest in how I was migrating from being the sole "auteur" of this into being a collaborator into a wider team, I though it was worthwhile to explore.

But first let me show you some images:

-The first one is my enemy designs. This is the Big Grunt, and the green variant was the first enemy ever to be part of Heart&Slash. I did a small redesign,  before putting in other enemies, since I was not happy with the first iteration. This is the second iteration you are looking at.

-The next one is the new artist's reinterpretation of my designs. There where two main goals for this redesign, the first one was to give the enemies more personality (basically to make their appearance and behaviour more coherent) and secondly to establish a function for them in the Factory (the first level of the game).

-And the final image is a render of one of these concepts. It's not in-game, so it's still missing shader information:

Apart from some technical considerations (the new model has 10% the polygons of the old model, the old one being so heavy it was really unusable on release), there where two main considerations when facing the redesign:

-Coherency: the level art (walls and floors and stuff like that) had already been redesigns into something that placed more details into the textures while simplifying the geometry and maintaining a similar enough style. The enemies need to be taken into this new style, and, more importantly, made consistent between themselves (right now they're pretty indistinct).

-Personality and Story: when the game started, I didn't have a very good idea of what the first level was going to be (an underground something, but I didn't know what exactly). Now that having a team has given me time for conceptualization (so I'm not expending 11-% of the time just building the damn thing), we have decided on a more specific setting (a robot factory) and more specific enemies (both in appearance and function. Function of gameplay and fictional function within the factory). The big grunt thus became the heavy loader/worker.

I think the new design is much more interesting than my old one, and that the right step towards a much more interesting game.

But I'm aware some of you may think otherwise.

Because it IS a fundamentally different style and approach than the previous iteration. It's presence in the game DOES change the game, how it feels...

And if you have been following a game development for months (some of you close to a year now) you can feel this is not the same. And not the same to something you enjoyed is sometimes understood and a negative thing, when the reality is that this project needs to evolve, and I am very thankful we have been able to make it do so.

What's happening is that now there are more creative voices in the project. And this is not only the artists, there are at least 6 of us who are part of the design process now. And although this brings some noise into the process, it's ultimately what a project like this needs. So from now on, although I will keep directing the project and ultimately making the final decisions, I am giving total authorship of the art design and conceptualization to the art team. Not only are they much more talented that I am. I no longer have time to do it myself.

This is not my game anymore, and I couldn't be happier about it.

NEW (SECRETISH) BUILD

For those of you who want to check the game with last week's improvements done (basically, new animations for most weapons and new -if unfinished- locations), we have uploaded a new build to gamejolt.

However, I don't want this to go too public (since it's still missing the new enemies and the new levels structure we are implementing right now) so I'd be happy if you didn't share the link too much...

I'll come back this weekend to write some more updates...

[Daniel Pellicer]

I liked more the colors of the third reinterpretation... Are they going to have different colors or will all look like this later one? It's also ok, im just curious

[Juan Raigada]

I liked more the colors of the third reinterpretation... Are they going to have different colors or will all look like this later one? It's also ok, im just curious

Oh, there are four variations of each enemy (as per the first image). All four designs will be modelled!

[Juan Raigada]

Surprise Update!!!

I know I committed to one update a week, but that was the minimum.

Today was one of those "get many small things fixed" days. Very productive actually, but the reason I made this post is because I discovered a very simple camera trick that I wanted to share.

Some of the feedback we are getting from the new build is (as always) related to the camera. Basically, it is a little too static, forcing you to take control of it all the time.

So we decided we had to give the camera some "inertia". That is, to have the camera slowly face the direction you are moving to so that you don't need to use the camera stick all the time.

Initial thought were on the line of making the camera interpolate from it's position to the new desired position so that it would slowly correct, or stuff like that... basically, making the camera more of a physical entity.

the problem was that our camera code is slightly complex, since it accounts for many, many variables (including behaving exactly the same no mater the timescale of the game) and changes like those are a pain.

So I had a very stupid idea, so stupid that I thought it couldn't possibly work... What if I read the characters movement input on the x axis (always relative to the camera) as a secondary, less strong camera input? That is, when you push right to move the character is as if you had pushed left slightly on the camera stick.

The implementation was trivial (two lines of code) so I decided to try it even if it was going to be a mess. but it wasn't. It actually works quite well (I still need to find the perfect values, but it works.

This is a gif of me moving around without touching the camera stick:

I don't know if this is going to be super useful to people out there, but it's a nifty trick that I think works quite well for third person games, so I wanted to share it.