next »

[tchassin]

Update 12
Still some time before a demo or anything, but I have something to show today!.


Also, since I said there would be a gif, have a confusing fatass 8Mb one

[Tom Felshmoon]

Tchassin, wow, looks like Final Fantasyю I love FF very much and now I'm following your game.
I watched this gif and I want to point out some things:
- I think it would be better if the using unit had some kind of the sign of their turn (like FF, when heroes step up)
- Work with animation of the 'team'. It's imperceptible, I think.

[tchassin]

@Tom Felshmoon:Thanks! You are right about the character not standing out. I simply forgot about it, but I fixed it now. Regarding animation, all the assets currently used are placeholders, the problem will be fixed when I change the sprites.

Update 13
Almost two months since last update... We've been quite busy but we managed to get things done!
First, we finally settled the story! Now we can start working more specifically on characters, places, enemies, etc.
I've also got a lot done in the game engine! I decided to go for the good old physical/magical attack/defense system and damage are divided into 5 elements:

• Normal
• Fire
• Thunder
• Enchanted
• Sacred

(Yes, Dark Souls strongly inspired me)

Since I added a couple new skills in the game, characters can now have up to 8 skills instead of 4. I'm currently working on a scrollable menu (arrrh, more UI-related stuff), which somehow led me to extend the gauge class so it can be filled either from left to right (for enemies and ...loading bars?) or from right to left (for heroes). I think it looks better this way.

I also found and fixed many balance-breaking bugs, even though the game is still very unbalanced since all stats and attacks are still placeholders, but things are getting better. I still need to add gear for the heroes before I can work on a balanced playable demo...

Eventually, since the currently playing character didn't stand out, I added a cursor above him/her. I think it should be okay for now, maybe characters will step up or change stance (probably not,since it would mean more animation work)in a distant future.

Even though I still have papers to write and other things to do for school, I'll try to post an update soon, because once school starts I probably won't have any time to work on this 

[tchassin]

Update 14
I'm not sure it's even relevant to update this topic at this point, but in case anyone is still interested in this, I'll give some news.

First of all, this project is not dead, I've been slowly but steadily working on the scenario with Pierre, and I hope to complete a first draft by the end of the month.
The complete lack of update since September is due to an insane amount of work I was clearly not ready for, leaving me no time for game development.

I've also decided to use Polycode instead of SFML, which does not provide satisfying solutions for aliased text, z-sorting and other things.

I'll be working on a smaller project for a few month to learn to use Polycode, while also polishing the scenario and harassing Pierre for artworks.

[Farage]

Does this rotating character actually has a use in game?
Because otherwise, i think you're wasting a lot of time with something that isn't going to make that much of a diference in the game.
~edit~
Wait, is it 3D? o.o

[tchassin]

Wait, is it 3D? o.o

Nope, 100% 2D sprite. I have given up on making the game 3D.

Does this rotating character actually has a use in game?
Because otherwise, i think you're wasting a lot of time with something that isn't going to make that much of a diference in the game.

Since I haven't made any asset yet, I think tinkering with this sprite is a good way to estimate how much time will be spent on each sprite and try different art styles.

Update 15
I just finished laying out the game story. I just need to find each character and place a name, and also define each character's gender (I tried to write without any gender bias).
Right now I have something like:

Victoria and ALLY_1 leave FOREST and arrive in TOWN_1.

When it's done, I'll probably translate it to English in case someone is interested in reading it.

[LightEnt]

follow follow follow

This game immediately reminds me of Breath of Fire, then you mentioned Breath of Fire, then my heart got all bubbly. I'd gladly read the script if you'd like feedback on it here.


About the sprite issue...how are you handling the world and combat? Will the fights be instanced with 1 combat direction for all enemies/characters, or are you going a 8-directional route with no instanced fights?

 

[tchassin]

follow follow follow

This game immediately reminds me of Breath of Fire, then you mentioned Breath of Fire, then my heart got all bubbly. I'd gladly read the script if you'd like feedback on it here.


About the sprite issue...how are you handling the world and combat? Will the fights be instanced with 1 combat direction for all enemies/characters, or are you going a 8-directional route with no instanced fights?

Thanks!  

About the sprite thing, I think I'll go the old-school way: instanced fights with fixed directions for everyone so I have more control on the action (and less animations to do ) and also because I like it better that way.

Update 15.5 (?)

I've been away for a few days without my computer, so I haven't done anything since last update. I got some feedback thought, so I'm going to tweak the scenario a bit before posting it.

I also got names for characters, but most of them are French because I work in French and didn't want names like Zarkor the Dark (not that there's anything wrong with that, it just does not fit in the game). Should I keep them in French in the English version, should I translate them, or just change them a bit?

For example, I would like to name a town Verbois, which is a composite of the French words vert (green) and bois (wood). Should I keep the name or change it to Greenwoods?

Since I have Norse and Gaelic names that I do not plan to translate, it might be better to just keep them in French?

EDIT: Also after a couple of beers, I managed to have Pierre give me some concept arts, I'll post some after scanning them. Cheer!

[ndke]

I think it's better to keep the names in French.
There's no need to translate it to English and the name doesn't sound "strange" in English.

[LightEnt]

Personally think you should keep it french, if it doesn't take any vital information away from the game.

[jgrams]

Yeah, keep them in French. Names is names.

If you have cases where the meaning of the name is essential to the gameplay you could provide a translation in parentheses...

Or if they're really unpronounceable, e.g. many Chinese people adopt english names when coming to the U.S. rather than have to be constantly correcting people's pronunciation...

[tchassin]

Well sounds like French names are a go then.

Update 16
Started porting everything from SFML to Polycode and cleaning large bits of code


I'll just say translating the scenario didn't progress that much today...

[tchassin]

Update 17
Today's update will be a bit different, since I'll try to explain a little more how the game is made for once.

Up until now, characters were positioned in the fight by reading from left to right an array a predefined positions, which was one ugly looking solution.
I tried to read the array from the middle, but it was pretty much inefficient and the characters were too spaced out when there were two of them.

I came up with a set of additional positions for even-numbered parties and increased the maximum number of enemies to 4 while at it, which gave me the following:

(positions are subject to change)

The red dots correspond to positions for even-numbered groups and blue dots to odd-numbered. By creating two sets of positions, one for the top, and one for the bottom, placing characters on the screen becomes easy: all I need is too read every other position in the array.

The algorithm is pretty straight-forward from there:

Code:

unsigned int offset = (positions.size() / 2) + 1 - characters.size();
for (int i = 0; i < characters.size(); ++i)
    character[i].position_set(positions[2 * i + offset]);

And voilà! Characters are now elegantly placed on the screen and the algorithm is completely scalable! 

[tchassin]

I've been very busy being on holidays the last two weeks so I have'nt made any progress since last time.

However, I've been busy jamming for the Ludum Dare 30 this weekend with some friends, and I might start working on another project in parallel.

You can check our entry out here.
I only worked on the graphics, which I'm pretty happy with. I might just go for something similar for Blade of Victory since this is the style I'm the most comfortable with. I'm just a bit worried that all my games end up looking the same...

In other news Pierre and I have been tweaking the scenario lately and I'll post it when we get something satisfying, so stay tuned!

[tchassin]

Warning: lengthy post incoming!

It's been a while since I posted anything in this thread... If some of you follow me on twitter, you may know that this project is not dead, but I thought it would be interesting to explain in detail what the hell is going on with this project. Maybe somebody will find it useful, who knows?

Blade of Victory started as a Microsoft C#/XNA school project in a team of 4. We worked on the game 6 months then after the end of the first year of school, I decided to continue working on the game. Since Microsoft had announced the end of XNA support, I decided to start the game from scratch using C++ and SFML.

However, neither C++ nor SFML provided the high level function I was accustomed to when using C#. I knew nothing of memory management or error handling and had never heard of design patterns. As a result, my code was a mess that was impossible to scale. I managed to make a prototype but adding features was increasingly difficult.

So I decided to write my own game engine with all the feature I would need to make a game. My short term goal shifted from making a game to making an engine. I stopped posting updatse since most of my work was technical and seemed unworthy of an update. As I built the engine, the gameplay started to disappear from my code. Moreover, having a lot of school-related work to do, I spent less time working on the project. Sometime I would not write a single line of code for months.

I then turned to Polycode, a promising C++ multimedia library. Playing around with Polycode was fun, but in the end the lack of support and some missing features made me go back to SFML. Of course I had to convert large chunk of code to make everything work once more and got sidetracked while doing so.

In the mean time, I have been writing a more complex and interesting scenario for the game. I know many people prefer gameplay-focused games but I wanted to tell a story with my game. However, I had not imagined the amount of work writing a simple scenario represented. We started seriously thinking of a good story around last April but it's still unfinished. Every time it seems to be over, Pierre or myself find a mistake or an incoherence and the story changes a bit. However, I think the latest versions are starting to look pretty good.

I have made a lot of mistakes or strange choices making this game. First of all, I started making games with this huge project. Even if we are a team of three now, I started making this game with very little knowledge in game development or programming. I did not use game making tools like Game Make or Unity and started with C++, which was probably not the best choice for a newbie and led me to making my own engine.

I have also been a terrible project manager. Until a couple month ago, I had no planning whatsoever, not even a todo list. I think this is the main reason this project has been running circles for so long. I have started everything over several times and wrote the same lines of code over and over again.

I have also done a terrible job at communicating around this game. Updates were VERY rares and often uninteresting. We don't have a website or a blog, not even a dedicated Twitter account. There is a Facebook page but I never posted anything, and I'm not even sure it ever reached half a dozen likes.

However I do not regret making these mistakes: it helped me understanding my strength and weaknesses, discovering the many different aspects of game making and I have gotten a lot better at writting a game engine.

With this in mind, I decided to take a fresh start on Blade of Victory.
[tldr: We're back in business!]

I'll also try to update this thread more regularly (this shouldn't be too hard) and I'd love to hear what you guys and gals would like to read in the upcoming updates. Would you like to know how the game is made? Are you interested in technical details (I have lots of those!)? Should I harass Pierre for eye-candies?

Well let's get started anyway:

Update 18
How about a little preview of the game on the second day (I was hungover the first) of 2015?

Believe me or not, the game now is fully isometric, and use a custom isometric engine I wrote but as you can see, it was still just an engine at that point, so the next thing I did was adding some test code.

There, maybe this isometric engine thing is more apparent now. This screenshot was taken on the 7th, at that point, two AI were wedging a merciless war but due to a lack of skills to use they kept defending. I made the first minimalist pacific RPG. Yeay!

I eventually got rid of the minimalist part. Hurray for sprites! I reached the first milestone on January 9th, after adding back simple UI elements and texture loading to the game. Even if it is still simple at this point, it is a game, and not an engine anymore!

So what's next?

Well I thought it would be cool if the player could control something in the game. Maybe those folks on the right? All the input handling is ready, I just need some menus... Also I'd like to give the player a bit more choice so I'll probably add some skills too. Oh, and animations. People just love those!

More seriously, I'm also working with Pierre on making the gameplay more unique and interesting so I'll start adding new features to test the ideas we come up with, and also visual feedback to make the action more readable (screen shakes anyone?).

Graphics-wise, the game is probably not going to change much for now since it's not our current focus and we have fully animated sprites we can use. However a new batch of sprites is planned for later this year, and I made a little preview of the heroin:

Hope you'll like it!

Cheers, and see you soon for more updates!

[James Edward Smith]

Graphics-wise, the game is probably not going to change much for now since it's not our current focus and we have fully animated sprites we can use. However a new batch of sprites is planned for later this year, and I made a little preview of the heroin:

She looks pretty great. I'll be neat to eventually see her doing some good battle poses and fighting animations.

[tchassin]

She looks pretty great. I'll be neat to eventually see her doing some good battle poses and fighting animations.

Thanks!

Update 19
I went throught the first post when I dug up this topic and found out I never updated it, so most of its content is outdated and do not represent the current state of the game. I should do something about it soon.

We spent most of the week refactoring the current gameplay code and improving resource loading time, in addition to other minor improvements. Progress on the UI is slow but steady.

The pace has slowed down a bit because we're at the point where we need to carefully plan the combat system before moving on, and our current schedules make it a bit difficult to gather for a brainstorming.

As of today, the basic fight loop is up and running. Each fighter is updated and fills its ATB, and notifies the game when it is full. Fighters that notifies the game during the same loop are queued and sorted according to their speed stat.

While the queue is not empty, the fight is paused and the first fighter of the queue plays. We use an abstract entity that can either represent the player or the computer to issue commands that are then executed by the fighters. This way, it is possible to switch control from player to AI or from AI to player during the fight (e.g: if one of your fighters is confused and plays on his own).

Once the command is executed, the fighter is removed from the queue and the game resumes if the queue is empty. For now the fight ends once one side has lost all its fighters, but using our event system, it will soon be possible to add specific win/lose conditions.

[tchassin]

Update 20
We spent a little more time than we though on fixing game data loading in order to make it more robust than it previously was. Now that it is fixed, characters and skills can be loaded and linked together. Animations are also loaded from a bunch of data files and dynamically played when character do thigs.

Since character now have skills to execute, the game got a little more interesting, however since visual feedback is still lacking, it's pretty hard to read what's going on, so all you get is a screenshot:

Yeay, violence! Because that's what video games are about, amaright? But don't worry, once one party lose it's all about defending until the end of time again!

It probably doesn't seem like much but things are starting to come along now that we started working more regularly on the game. Who knew working actually worked? 

[tchassin]

Update 21
We thought we'd have more to share with you this week, but it turns out a couple of things were more complicated than it seemed. As mentioned before, the game is pretty hard to read at the moment, mainly because many things happen at once.

When a character uses a skill an animation is played, but since the effect were instantly applied, any target hit by the skill would also play a damage or death animation, resulting in things happening on both sides of the screen at once. Furthermore, adding visual effect to the game would have worsen this phenomenon, so we had to find a workaround.

We're currently working on adding a dummy entity that cast the skill with a delay then apply its effect after another delay, so that when a skill is used:

• The caster plays an animation
• When the animation is almost over, a global visual effect (eg: an explosion) is added to the scene if necessary
• After a couple frame, indidual visual effect are displayed over hit targets and damage are applied, leading to a damage/death animation playing

Of course this will need a bit of fine-tuning but we hope to have results by next week. We also hope to add menus back by then.

In the mean time, we got some nice artwork from Pierre, so expect some eye-candy soon!

[tchassin]

First animated preview of the game!



What do you guys and gals think? Is it readable?