Update 43
Happy new year y'all! 

This update will be shorter than usual. The demo was delayed because we decided to slightly increase its scope. This also mean that most placeholder sprites will be replaced when we release it.

Since we are beginner level designers, we will use the demo to experiment and learn. We have a dozen maps planned and designed, but we still need to build them. This will also help us test our level build work flow and identify bottle necks. Since we do not know how long this will take, I will not try to give a release date for the demo.

We also decided to add more features and content. Treasure chests, for example, were planned for the 6th iteration, but implementing them now allowed us to improve the level design by adding points of interest.

We hope you will enjoy what we are making!

Cheers! 

Loving the art style and general look of the game. Keep it up.

Thanks! We will keep doing our best!

Update 42
The rough animations are done! I have started cleaning some but it takes me forever because I am the slowest animator in the world. Here is a little preview of the run cycle:

I also spent a lot of time on the forest tileset, in particular the tree tiles. It is now much easier to use so once we come up with a couple layouts, we should be able to start creating maps for the demo.

Since Christmas is around the corner and given how slow I am, the demo will not be complete by the end of the month. Since the game is in a playable state, we can either release a demo with a partial graphic update and (hopefully) patch it in January or wait for the new graphics to be done to release it. We are currently leaning toward an early release followed by a patch because it will allow us to get feedback sooner.

This will be the last update before Christmas, so happy holidays!

Cheers 

[Bad news:]

Update 41
I have good news and bad news today.

Bad news:
I just found out a game named Action-Blade of Victory recently came out on the iTunes app store, so we will have to come up with a new name, after 5 years of development...

I also barely made any progress on the sprites this week, so no eye candy today.

Good news:
Despite a delayed batch of sprites, the demo is coming along nicely.

When I started testing the new animations, I found some nasty bugs that took several days to fix. I also fixed all known bugs, removed from the build all broken and/or incomplete features and created a itch.io page with a playable web demo on it. Since I would like to work a little longer on the game before showing it, the page is private at the moment.

Once the new sprites and a couple new maps are in, I will share the link to the demo and keep the game in a playable state until release. I plan on updating the game every once in a while, but I can't say how often for now.

In the mean time, Pierre and I have been rewriting some bits of the scenario to improve the pacing and make sure the player gets a full party as soon as possible. There is some more work to do on the second half of the story, but it is coming along pretty nicely.

Cheers! 

Update 40
The demo is still in the making but may take a little longer than expected. After years of programming, my pixel art skills got a bit rusty, and I would rather see the demo delayed than rushed. Since I am working on the graphics, I though now would be a good time to explain our content pipeline for characters.

First of all, Pierre, makes rough sketches of the character until we are both satisfied. The final sketch is then cleaned and colorized so I can use it as a reference for a sprite.

Before making a complete sprite sheet, I start with a single, fully-detailed frame of the character in a neutral pose. This reference frame then goes back and forth between Pierre and I until we are both satisfied. After that, I make the remaining reference frames. The sprites are 8-directional outside of combat, but since I am the only animator on the team, I am only animating the sprites in 5 directions, the remaining 3 are obtained by flipping horizontally the sprite in-game. This significantly reduces the workload with little consequences on the game's quality, so I think it is a good trade-off.

Once the reference frames are done, I start by sketching a rough silhouette animation of each of the main animations in one direction which allows a short iteration time. Once again, the animation goes back and forth between Pierre and I until we are satisfied before I can work on the other directions. Once this is done, I add the sprite to the game so I can test if it feels right.

After testing all the rough animations in-game, I add color blocks representing the main sprite elements then I polish until the sprite looks good enough.

I am currently working on the rough animations of Victoire's overworld sprite. I tried reducing the number of frames in the run animation from 8 (4 key frames and 4 in-between) to 6 (4 key frames and 2 in-between) but the reduced number of in-between made the sprite less readable, and reducing the delay between frames did not help, as shown below.

      

I am working hard on making an attack animation feel right at the moment. This will also be useful for the combat sprite, so I consider it time well spent. At first, I tried giving the slash animation from the previous sprite more impact, but it ended up looking like "she is decapitating a dragon", to quote Pierre.

Making the slash horizontal made things better, but at a cost. It was going to be harder to animate in all directions, and the sprite made the hit zone feel larger than it really was in-game, which was frustrating for the player. Since we liked this animation, I may end up using it for the combat sprite.

In the end, I settled for a sword thrust. I think it is a good compromise between readability of the hit zone and dynamism, and it is far easier to animate than the horizontal slash.

As you can see, there is still a lot of work to be done, but I think I am getting somewhere.

Cheers ! 

Update 39
Hey it's been a while! The last few months have been quite busy on my end, hence the lack of updates.

The game has been through a lot since the last time. After some testing, it turned the ATB system did not make the combat system more interesting than the traditional turn-based approach, while raising some technical and conceptual issues. I tried implementing a simple turn-based system and got some encouraging feedback so I think we will stick with it for now.

The implementation of the isometric perspective as 3D objects represented by 2D sprites also had many drawbacks and prevented us from using most external tools such as Tiled in our content creation pipeline. Furthermore, we were not satisfied with the way the game looked, so the game is now in 2D with 3/4 top-down view. It was not an easy decision, but it was critical to make it before putting together the game maps and we are confident it will save time in the long run.

As the 4th iteration on the game nears its end, we are focusing on releasing a demo. Most of the code is done and I am currently working on a complete graphic overhaul. The next steps are balancing the game, putting together some maps and cut all incomplete features from the build. The demo should be available in early December on itch.io.

Cheers! 

Looking really good! <'3

The second way for your help information seems like it could be vaguely annoying, maybe? If I were playing, it would feel somewhat awkward to have to exit out when it doesn't really seem to be all that separated from the main system, y'know?

Thanks, we are working on making the game look even better!

We have been discussing the help mode and we came to the conclusion that it would break the game flow, so we will probably go with the smaller, less intrusive window. Maybe we will have some longer description available in the menus, or have the text automatically scroll inside the window.

Update 38
The new controls are done for now, and the battle system now supports them. It feels much better, even if it could use a little polish, but that is not the top priority. We would like make a better battle UI before moving on to the menus, so I have some mockups to show today.

Of course, we are planning on making pixel-perfect assets and replace the portrait sketches with yummy colored pixels, but we're also try to make the UI less intrusive (and not hide enemies anymore) while adding some help messages and skill/item descriptions.

Look at all this additional space!

The icons indicates the skill/item type, and the number on the right the MP cost for a skill and the number of remaining use for an item. The ATB cost for each skill/item/enhancement will be indicated by a blinking cursor on the ATB.

We tried adding a small help window that the player can toggle on/off. It's not very large so descriptions would have to be very concise in this case. Alternatively, the window could appear beneath the ATB, in which case the ATB would simply move up or down as needed.

We also considered having a help mode, with a more intrusive window. We came up with two different ways of handling this
Once the help mode is activated, either:

• The player can still navigate the current set of options and selecting one would exit the help mode
• The player has to exit the help mode by pressing any key/button before selecting an option or resuming navigation

Less space, more information

We are not to sure about the whole help window thing, so any feedback/advice is welcome!
Cheers!

Update 37
It's been almost a month since the last update and we've been making some nice progress on the game.

Code-wise, I've been working on having a testable build, so I've been fixing and polishing a lot of things, but it turns out the game is hardly playable because the current UI controls are really bad. Right now, UI elements only work with the mouse, because it is simpler to implement with Unity. Since we are aiming for keyboard/gamepad controls for the demo, we decided to rewrite the whole thing from scratch rather than fixing the current controls. Once it is done, we'll test the battle system to make sure the game is fun to play.

We have also been working on the dialogues and we're pretty confident in what we have so far. It allowed us to improve the story with better character development and more interesting relations. I think we're going the right way with the whole dialogue thing, and it really makes me want to bring these character to life and tell you their story.

Regarding the graphics, I was not going anywhere with the poses for the new sprites, so I decided to take a break and go back to anatomy/perspective practice for a while. I really want to replace the five years old sprites, but at the same time I want to have some real improvements to show, so it will take a little longer before the graphic update.

One more thing before wrapping up this update: Pierre made some really nice concept art for the Ver Lanec village (that you will be able to explore in the demo), so we decided to share it with you!

Cheers! 

Cool pixel art style and nice classic gameplay!

Thanks! We're working on making both even better at the moment!

Update 36
I am still improving and refactoring the battle system. One of changes worth mentioning is the damage equation. Until last Friday, damages was computed as following:

Code:

// TODO (01/05/2015): Take defense into account
damages = skillPower * casterAttack * 0.02

with casterAttack being either the caster's strength or magic. A bit simplistic and not taking defense into account was problematic (don't even ask about 0.02, I don't remember). So after some thinking, we came up with a new equation:

Code:

damages = max(1, skillPower * (50 + casterAttack) / (50 + targetDefense))

We introduced constants so that things don't get too crazy at low level. This should be pretty useful for the demo, which takes place early in the game.

The guard system also receiving a lift. With the old system, if a character was defending, incoming damages would just be divided by 2. However, we decided to extend the system to give the player more options, such as covering an ally, triggering a counter when hit, restoring some HP or MP, etc. Ideally, this should make defending a bit more interesting than a convenient way to skip a turn.

Pierre had an artwork planned for this update, unfortunately for you and I, he was very busy preparing for the Stunfest, where he was demoing Lije, so no eye-candy today.

Cheers!

I'm having trouble describing the graphics... It reminds me of C64, but with more fidelity. Either way, it looks really cool. Will be watching this.

C64? As in Commodore 64 ? That was not really intentional but thanks!

Update 35
Programming-wise, I have been rewriting quite a chunk of the battle system the for the past two weeks. I am finished with the core mechanics, and now that we have discussed the features we want with Pierre, I just have to extend the system.

Speaking of the battle system and its features, I did not talk much about it up until now, so I guess it's time to fix that.

Until recently, the game was played like any other RPG, except you could play several time in a row, which sounded like a good idea at the time. The main issue with this idea was to find an interesting way to make acting once or several times different. That and Bravely Default doing basically the same, but better.

We tried several options, such as introducing a combo system, combining successive attacks into more powerful ones, giving defensive patterns to enemies, etc. Some of them were interesting, but each had its own problems and none felt quite right. this is the main reason behind the lack of communication on this aspect of the game.

Not too long ago, we had the idea of dividing skills into two categories: action, and action enhancement (any suggestion for a better name?).
Action is just a generic name for the things you can usually do in any other RPG: defend, attack, use an item, etc. Only one action can be executed during a single turn.
Action enhancements (still looking for a cool, flashy name) are a way to customize the previously chosen action and give the player more options. For example, you can either strengthen an attack for some extra MP and ATB or add a counter-attack to your guard. For now, only one action enhancement can be used each turn.

The new system with the new resolution but the same graphics and terrible UI.

It's not groundbreaking (actually there is a class in Bravely Second that does the same) but we're pretty confident that we can design some interesting fights with this system, and it's pretty easy to combine with other systems such as the skill tree.

Cheers 

The first map made with our custom map editor and a resolution test for Blade of Victory:

Update 34
I DID IT! I finished the new map editor! I had to make compromises, but I'm pretty happy with it. Making a simple map now takes less around two minutes, so it was really worth the time spent. I decided to postpone cliffs and slopes support, because we are focusing on the forest area at the moment.

First map made with the new editor

In other news, Pierre and I have settled for a resolution of 640*360 (see the previous screenshot). It feels neither too big or small and it scales perfectly to 720p and 1080p. We will not change the resolution for now because it would break most of the UI so we'll switch after replacing the assets.

Regarding the discussion on brutality I evoked last week, we reached the conclusion that fluids requires a lot of work to be animated properly and have the desired impact. Because I'm both the animator and the programmer, handling the extra work would be difficult and would slow development down, so we're closing this discussion for now.

Aside from some tool refactoring, the next big task is the battle system and the new assets that comes with it. I'm pretty confident with the new system, but I have to take some time and think of the implementation, because most of the battle system was written as a prototype and is has to be rewritten.

To conclude this update and celebrate the completion of the editor, feast you eyes on this sweet new artwork Pierre made!

Cheers! 

Update 33
After some more research, I decided going for a custom editor inside Unity. I got a first version working with only support for basic tiles and made a the first tile-based map for the game.

You know what would make this map look much better (and prevent the character from falling of the map)? Pine trees. Those things make everything more RPG-ish.

This first version, while fully functional, was not exactly an efficient tool so I decided to try something different and use autotiles. If you are not familiar with autotiles, it is a very convenient way to produce maps much faster with less errors. The idea is to indicate the terrain type (eg: grass, dirt, water...) for each tile and let an algorithm choose the right tiles. Here is a more in-depth introduction.

In order to support autotiles, the map is represented in a completely different way, because tiles are not manipulated directly, instead they are deduced from the vertices of the isometric grid. This additional abstraction will allow a lot of cool things such as easily updating the tile sprites if the tileset image is modified, or changing the tileset without placing a single tile. How cool is that?!

For the moment I only have a (resizable) painting tool that can set the terrain type of the vertice. I'm having trouble with the save/load system so it's not very useful right now...

The vertex painting tool in its current state.

However, progress is slow for personal reasons and it is starting to get to me, so I'm thinking of taking a break from the editor and working on the new battle system. It will probably take quite sometime because I wrote most of the code more than one year ago when I didn't know Unity at all and I never took the time to refactor it.

I think now would also be a good time to slow down on programming and spend some time on better assets. I'm working on rough animations for the characters and maybe throw in a new enemy.

In other news, I have playing Hyper Light Drifter recently and I was surprised by the visual brutality of the game at times. I have been thinking about it and we discussed it with Pierre, and we are considering shedding some red pixels on screen (there would be a warning at the start of a new game and an option to disable most violent animations). Any thoughts on the matter?

EDIT: Added a gif showing the current state of the editor

Update 32
Today's update will be more technical than usual, so brace yourself!

I am currently working on a better way to build maps for the game. As you have probably noticed in the gifs and screenshots, the maps currently consist of a dull flat colored 3D plane. We're trying to make things more interesting by creating more complex tile-based maps, but it turned out to be quite a pain with Unity.

While the Unity Editor is a great general purpose tool, it is not as powerful as other dedicated tools when it comes to tile-based maps. Since there will probably be more than a hundred maps in the game, having the right tool is important.

I found some interesting articles (I think this one is a good read for any Unity developer) about storing maps without using the Unity scene system, using XML for example. Some of the stated advantages include:

• Reduced loading times (not really a concern right now)
• Easier handling of persistent data (like the player's character, the main camera) across maps
• Easy to interface with third-party tools
• Other technical details

However it does not solve the editor problem, and it implies writing an import tool. Side note: I think Unity takes care of compressing the map into a binary bundle file when building the game so the player probably can't modify the maps shipped with the game, but I will have to check.

I have tried working with Tiled and Tiled2Unity, a Unity plug-in that can import maps, but I don't think it is the right tool for us. It is clear that it is a tool tailored for top-down and side-scrolling games, not isometric games, because it does not seem to support any form of 3D, and the imported maps are just 2D objects. Tudee, an other tile-based editor does not provide isometric support at all.

I have also experimented with custom editor windows in Unity, but it seems that it will require a large amount of work to get satisfying results. During this experiment, I have created a handy tool to handle the camera bounds and rewrote most of the camera code, so I guess it was not in vain. Here is what I have for now:

Also remember: don't drink and code, or your editor could go all modern art on you

Cheers! 

Update 31
Although it was delayed, Blade of Victory v0.3 has been completed! The major reason behind this delay is that I moved to Japan for an internship shortly after the last update. There has been some unexpected complications, but things seem to have settled down so I should be able to work more regularly, although at a slower pace.

I also spent some extra time working on a better sprite for the main character, but I'm not confident enough to show it. Some animations need to be re-worked, but I think it's much better. However, some frames are larger than other so it seems that I am going to have to manually place an anchor point on each frame. If I don't, the character looks like it's being pushed back and forth by some mysterious force when a bigger frame is played.

Regarding equipment, a lot of refactoring was needed because all the item-related code was written almost one year ago for a prototype. Adding equipment without refactoring was possible, but seemed to dangerous on the long run to be worth it.
To keep things simple, there are three different kind of equipment for now:

• Weapon
• Armor
• Accessory

Each character gets one weapon slot, one armor slot and two equipment slot. There are no restrictions on who can equip what right now, so if you absolutely want your foxman shaman to carry a two-handed sword, you can. I will add these later, when Pierre and I will have finished designing an other feature related to weapons.

Altough it is far from final (better looking menus are planned for v0.4) I can share this screen of the equipment menu:

I only realized how hard to read the red text was after taking this screen 

Before moving on to the 4th iteration on the game, I still have some refactoring to do in order to keep the code clean and maintainable. This is very important because there is a lot of important features to add so I don't want to be slowed down by past mistakes once I get started.

There are a lot of exciting things planned for Blade of Victory v0.4, because we are planning on releasing a playable demo soon after it's complete. New features include:

• Tile-based isometric maps
• A better battle system
• Merchants

And other things that will be revealed in due time...

In addition, many visual improvements are planned, such as new sprites, visual feedback during battles, better user interface and menus, an animated transition to the battle screen, etc. These feature were originally planned for later but we have decided to implement them as soon as possible in order to have more engaging visuals to share. I'll get into details in a later update.

This change of plan has one major drawback: the demo has to be delayed until further notice. There are many features that need some research before being implemented so we can't give a release date for now, but don't expect anything before October. We hope we can make something worth the wait!

Cheers! 

Update 30
The past two months have been quite a ride. Caught between finals and other projects, I didn't have time to work on Blade of Victory at all, hence the lack of update. Things have settled down now, and Pierre and I have resumed working on the game. We're
on schedule and we should reach the 30% milestone by the end of the month.

Since the last update, I focused on interacting with the world outside of battles. It is now possible to trigger dialogues or pick up items by pressing a button, or attack enemies and destructible elements.

Attacking enemies grant allows the player to have the initiative in a fight, while being caught off-guard will result in an empty ATB.

Destructible elements, such as plants or crates, will sometime block the player's path but breaking/cutting them might result in item drops. For example, in the forest, the player can acquire healing herbs by cutting down white flowered plants:

The cube is a debug tool that helps us visualize how collisions are tested:

• When the cube is gray, only collisions with interactive elements such as NPCs and pickups are detected
• When the cube is yellow, collisions are turned off
• When the cube is red, only collisions with hittable elements such as enemies and crates are detected

Of course, the cube will be replaced by an animation in due time, but that will be for a later update.

A few debug/refactoring/polish aside, the last big feature planned for Blade of Victory v0.3 is equipment, so I guess that's what the next update will be about.
Cheers!  

[Blade of Victory now has a composer]

Update 29
Today's update will be a bit longer than the last one because I have important things to say. Good things.

First, Blade of Victory now has a composer! His name is Luke and he will be in charge of the soundtrack and sound effects for the game. This is really a turning point for us, because this means we have every aspect of the game covered! Hurray!
Since we have just begun working with Luke, we don't have tracks to share with you yet, but you can find his demo reel here.

But wait, there's more: programming is going pretty smoothly and the save/load system is pretty much finished. We're even a bit ahead of the schedule! 
Since the game is linear, the save system is pretty straight-forward: each time you start a new game, a new save file is created and automatically updated upon reaching a save point or leaving the game. Of course, you'll be able to have as many save files as you want.

I also managed to get our very first fully colored artwork from Pierre (who is a very busy man) last week, so it's eye-candy time! (The design is not final, it's more a about mood and colors)

Aiguemont, capital of the Kingdom of Verdance

Regarding the story, we have decided to share some details. The story is divided into eight chapters, plus a prologue and epilogue. The chapters may vary in length and drama, but we tried to slice the story as logically and naturally as possible. You can read get a brief summary of the game (Warning: spoliers included) in PDF format here.

EDIT: I should REALLY update the front page

Cheers!

I'm really, /really/ liking the look of this so far! Excited to see more.

Thanks, I'm happy to oblige!

Update 28
What would be a good RPG without...



... dialogues*!
As usual, it's not very polished, and won't be until the next slice. Next is adding combat dialogues, for the sake of drama!

Cheers!

*Dumb joke not included in the final product

Ah! A turn-based rpg! My fav!

It's been a while, so I'm not sure if you still need (or would like) for people to test out the prototype. If you are, I'd love to take a stab at it.

Heck, I'll take a stab at in anyway, haha

We're not looking for testers for now, but don't worry! We're planning a demo around August, and you're all invited!   

Cheers!

Update 27
I have been working on a debug console for a few days and it's coming along nicely. Now I can type in commands and cheat codes to make testing and debugging easier. I should have done this sooner, having simple yet powerful tools saves a lot of time and effort.

For example, to test the 'Phoenix down' last week, I had to change its drop rate to 100%, then start the game, fight an enemy and manage to win while letting one of my characters die. THEN I could test whether it worked correctly. Oh and of course the drop rate had to be restored.

Now I can just type in 'set_health eric 0' and 'get_item phoenix_down' to kill a character and get the item.