Condorra – Game Update #408/12/2016
It’s been a few weeks since the last update. So here is what has changed since Update 3.
A Brand New Battle System
Yes, the counter-based battle system was completely scrapped. The counter idea just didn’t work out the way we thought it would. In it’s place there is now a system where the direction you enter battle from plays a major role (enemies walk on the map):
- Most enemies will have strong & weak sides
e.g. If you attack an enemy on his weak side it could deal double damage.
- Also weapons, skills & items are affected by the direction of battle.
- Turn Order is now similar to Final Fantasy X.
This allows you to see who’s turn it is next and plan ahead (based on your actions)
The Search For A Graphical Style
Sebastian has been busy finding a graphical style that fits our vision of Condorra. Our inspirations range from the old Final Fantasies, A Link to The Past to Evoland and even older NES games. We haven’t yet been able to find a consistent style that fits enemies, heroes and the environment.
Here are 4 different styles of characters Sebastian has made:
So before we had an implementation of Autotiles that was kind of OK. I knew I wasn’t totally satisfied with it so I looked for a way to make them look better. Another goal was that they couldn’t be too time consuming to make. In the first version we needed 16 Tiles for every Autotile. Now we only need 6 and they look way better.
If you look closely you can see that the first version has no corners at the intersections. This makes a pretty big difference in perceived quality. For anyone interested to program this themselves, here is an article on the inner workings of autotiles in RPG Maker (which my implementation is based on).
About The Difficulty Of Unification
We have also been thinking a lot about the setting, theme, characters, story and how that all relates to the battle system, the finding of items and exploring. This is one of reasons we have difficulties finding a graphical style as all parts are interconnected. We think it’s important that a game fits together as a cohesive unit. It should be as if this world you are creating could actually exist on it’s own.
- Most enemies will have strong & weak sides
Condorra – Game Update 306/25/2016
So here is a short progress update of the last 2 weeks:
- Reworked Battle mechanics
- Enemy now decide their action based on their script: basically this lays the foundation of interesting enemies as each can have their own behavior and created quickly
- The Map-Editor has been greatly improved, lots of things have been automated. E.g. before there were extra layers below the hero, and on top. This meant you had to manually place the parts you wanted drawn on top the hero on an extra layer. Now when you place a tree for example, the editor automatically figures out which tiles go on the layers on top of the hero. This is a huge time/sanity saver.
- Tiles can now block access from certain directions instead of binary passable/non-passable
- Added scripting functions to allow for teleporting the hero to different maps. You can specify transition parameters as well.
- Started creating maps: the worldmap, a town and a dungeon
I spent a lot of time on internal technical stuff as well, so hopefully I can now create more on the content side of things. If you want to stay up to date you can subscribe via RSS or follow @frameland on twitter.
Condorra – Game Update 206/10/2016
In spent the last 2 weeks creating the battle-system for Condorra from scratch. It’s a turn-based system that gives players as much time as they need to decide on their action.
Here is a list of things that are already working + details:
- Turn Order
Because the system is turn-based, you have to somehow determine a way who’s turn it will be next. At first I implemented a modified version of Final Fantasy X’s CTB system. I won’t go into detail here, but it’s a system that allows the player to plan ahead his actions.
It turned out though this system was not a good fit. Condorra’s system put’s counters at center stage. Having a mixed turn-order (hero1 -> monster2 -> hero2 -> hero3 -> monster1) with counters thrown in just seemed random and confusing. So now the system is round based: first the heroes will take their action, then the enemies, then the heroes, etc.
- Selecting an Action
I just put all available actions for a character into a menu panel. They then select what they want to do.
- Selecting a Target
For now you can select everyone with every action. That might change in the future.
- Executing the Action
I would say this took the most time to get done. Players can counter all actions, enemies on the other hand only counter them under certain conditions. There is also what I call the “sweetspot” system: whenever a hero attacks an enemy, you have the chance to hit the sweetspot for extra damage. When an enemy attacks the player, you again get the chance to hit the sweetspot: If successful you can counter the enemy action. Hitting the sweetspot is as simple as hitting a key at the right time.
- Damage Calculation
I will admit that I
stoleborrowed most of my ideas from this FFX stat guide on gamefaqs (thanks). Once you execute an action, damage is based on your stats (attack, defense, magic, magic-defense), weaknesses against elements (fire, water, wind, earth) and the power of the action itself.
The state of this system is still very much in flux right now, but I think it’s a good foundation.
Condorra will have lots of content: Monsters, Actions, Battles, Maps, Animations, … So it’s important to create a structure that supports easily adding new content. Ideally without touching the code.
The answer to this is to make your content data-driven. Instead of hardcoding how things work and how they look, you allow a bit of room for customization. This is the folder structure in Condorra:
It’s a reoccurring theme: Each “thing” has it’s own folder.
Let’s take the attack action as example: It has it’s own folder in actions/. In there are 2 files: config.ini and script.mc. The config.ini contains details about attack, such as power, element, info. The script.mc is a script file. The game will call the script to know if the animation has finished, if a sweetspot was hit or simply to update it’s animation. So when I want to add that awesome screenshake effect (and I will) this is the file to write it in.
Interestingly this way of structuring works very well for a lot of things. The maps are structured this way as well. The config has the map-data, the script the behavior. Monsters will decide which action to take by calling it’s script. The Battles config.ini stores monsters, their position and the background image.
- Turn Order