2013 09 Jan

Combat System #5: One world, two systems

Categories: General

First of all, a happy new year to all our fellow readers!

This blog post will explain one of the most important features in Chaos Chronicles: a game engine that includes both systems, turn-based as well as real-time.

There used to be a time when pretty much every role-playing and strategy game out there was turn-based. That was partially due to technological restrictions but also due to the fact that these games were derived from pen & paper rpgs and board games which are both usually ‘turn-based’.

In the early nineties, Dune 2 (by Westwood) created the RTS genre (at least on the PC, because Herzog Zwei was Sega exklusive) or, as some would say, changed strategy games to be real-time instead of turn-based. At the same time games like Ultima Underworld did the same for the RPG genre. In both genres the change usually implied the change from boards to analogous movement. And interestingly, in the RPG genre, it also implied a change from character parties towards single character games.

Yes, Dungeon Master and its imitators, i.e. ‘the subgenre of dungeon crawlers’ (revived by the great Grimrock) had a little headstart compared to the rest of the RPG genre and, yes, real-time-with-pause-RPGs revived character parties, but that didn’t change what happened next: With real time combat being new and exciting and turn-based being (or being said to be) old and boring developers ceased to make turn-based games. Not because all devs were morons but rather simply because no one – including gamers – was interested in turn-based games any more at that time. But even if we (and hopefully you RPG vets out there) are eager to see turn-based combat revived, we have also gotten used to the amenities of real-time, regarding, e.g., the exploration of the game world. For us that meant that we would have to feature both real-time and grid movement.

Marketing experts probably couldn’t resist using pretentious terms like ‘hybrid’ at this point, but we’ll restrain ourselves to saying that our levels have to feature *both*.

As already implied in this blog post’s introduction, (real-time) analogous movement is much harder to achieve than (turn-based) field movement.

Luckily, our editor already featured automatic navmesh generation from our last project. And it was obvious that we could make use of that navigation mesh to automatically compute a game board for combats. To do this we basically just have to lay a 2d grid of potential board fields on the navmesh polygons, and use navmesh raycasts to test in which directions they should be connected to their neighbours.

We had a prototype up and running rather quickly and from there it was a long way of improving data structures and implementing algorithms to make use of the board data, i.e. path search, flooding with weighing of fields, etc. and to get the board (including combat animations and stuff) neatly visualized (neither being overly prominent, nor to technical, nor too hard to see and so on). Also there’s always a list of problems that you don’t expect in the first place and it took time to handle those. Especially party movement in real-time mode and immeersive examination of objects in the game world were tasks on their own which we will probably cover in blog posts to come.

 

 

 

 

 

 

 

 

 

 

 

 

 

By now, the logical stuff is mostly solved and we (even our level-designers) are pretty content with our auto-generated combat boards. Hexagons were definitely the right choice for this, as you can just build levels looking as naturally as you expect them to, and the hexes will mostly fit themselves into it like a charm.

As far as gameplay is concerned, there are still some open questions. E.g. a player moving his party around in exploration mode has little control over the dynamic movement of the party following him. However when a combat starts the characters’ positions suddenly become relevant as characters are simply placed on the closest board field. The resulting lack of influence you have in your party’s initial positioning is cool for surprise combats but might be annoying for a combat you already expect. We considered manual placing of the chars but found it too immersion-breaking. Depending on our polishing prioritization we might leave this as it is, but as always we appreciate your opinion or suggestions.


Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 82 bytes) in /var/www/mpress/public/wp-includes/cache.php on line 506