Just a few thoughts: Isn’t it funny that so many games which are set in a somehow-medieval setting have so many futuristic gadgets included? Just a little example: Go into a dungeon and have a look at the map. Of course, a map is needed. Otherwise the player can easily lose his or her orientation. But often the maps are atmosphere-breakers.  This is caused by the way they are used. Usually they just consist out of a screenshot from the whole dungeon from far above. Some markers here, some markers there. Ready is the map.

That’s the easy way. But in our eyes it doesn’t fit in such a setting. There is no system like GPS, there are no satellites in such a setting. Yet the maps of the dungeons usually give the player the impression there might be such things. That’s why we chose to go for hand-drawn maps for each dungeon. This fits better into the setting, doesn’t damage the atmosphere. The maps do display the dungeon but it doesn’t feel like you are using some superhighend-technology. Here’s a small comparison-shot of the Map from above and the drawn map for it (still WiP).

This picture shows how Dungeon-Maps are created






UPDATE: Due to your feedback, we changed the style for our Dungeon Maps to a more hand-drawn style. Thanks for your contribution!

2012 30 Oct

Combat System #4: The Grid

Categories: Game Design

Just a quick preview of the combat grid in Chaos Chronicles. You can see the path preview that indicates the range for move+action (green) and double move (yellow). Soon, we can show more than this – thanks for your patience so far.
















In an earlier post (Combat System #1, Sep 03) that discussed the combat system, we admitted that we originally aimed for making a turn-based game. However, we also mentioned that other variants (esp. the RtwP combat of Dragon Age) were worth discussing and we spent some time doing so. We are grown-ups that make games in an industry that still mostly focuses on kids as customers. Most of us were still teenagers when turn-based RPGs vanished and made place for the new era of realtime. And even if the pros and cons sometimes come down to personal taste, we think that no one would argue one point: turn-based games tend to be less “action-packed”. It can grow annoying (especially in a less tight combat) to wait until all those goblins, kobolds, what-so-ever-minions have finally made their turn. Especially watching enemies moving is kinda boring and that’s why some TB games have sped up movement (e.g. animations) to the brink of sheer ugliness.

Players are eager to see their characters’ turns and they are also excited to see whether the enemy boss will kill their tank in his next turn. And while we all enjoy wiping out 20 goblins with a fireball, no one wants to see them all move and attack one after the other. In fact, some of us got often tempted to reload and see whether their wizard has a higher initiative this time to get rid of those little annoyances in the beginning of the combat.

ToEE tried to tackle this problem with a menu option that, once activated, would allow enemies within the same initiative group to move simultaneously. That turned out to create cool packs of hobbling and wobbling goblins but (as mentioned above) was not always beneficial: In a fight with a small number of semi-bosses that happened to be in the same initiative group (say, a giant, a werewolf and a demon) we would not only want to anticipate their attacks separatly but it also does look kinda unepic when these individuals make their moves together.

So we wanted to take care of the boring minions on the one hand without randomly grouping more epic enemies on the other. We straightfowardly decided to let our level designers choose which enemies should be grouped and which shouldn’t. The ‘minion mobs’ were born and we found them to provide additional advantages:

Rather than rolling the gobs initiative individually and grouping them up accordingly, we group them up beforehand and roll their initiative only once. This implies that a group of minions can not be ‘spread out’ over the initiative list and act individually (a case that the ToEE approach didn’t prevent). Also, we are going to try and give them some additional ‘identity’ exceeding the simple fact that they act simultaneously, by also tweaking their AI to stay together and attack the same target whenever possible. We think that might add to the strategic depth of our combat (and even if it won’t, it will still be more atmospheric). As an additional consequence, the player will be able to predict the a mob’s behavior to some extent. As far as we’ve implemented this (grouping and movement already looks good, but AI is still very basic) our idea feels great and we hope we’re well on the way to make turn-based combat a little more appealing regarding the pace.

We hope you enjoy our super-size-goblin-minion-mobs screenshot (more will follow soon) and we are, as always, looking forward to your comments!



As mentioned in the previous post, we are currently working hard on the storytelling part of Chaos Chronicles. In this context, we discussed about stereotypes in High Fantasy settings, especially those about race and gender. Here are two examples how we planned to include those ‘racial’ habits in our game:

a) Your party enters a stinking place that is totally messed with old food. The elf in your party is disgusted about the smell; the halfing complains about the big waste of food and the male warrior asked one of your female party members to clean this place.

b) Your party discovered an old dwarven forge provided with firewood taken from surrounding woods. The dwarf in your party starts to praise the superior blacksmith skills of his people; the elf blames the dwarves for chopping down ‘holy’ trees. The halfing proposes to use the forge to create another tasty meal.

What do you think about the use of classical stereotypes with your own characters? Do you think that those characteristics are acceptable for a High Fantasy game or should the game leave those personalities to your own imagination?

Please contribute your opinion (if you have one) !

As you may remember we mentioned the subject before when we talked about our die rolling experiments with D&D 4th Edition: Six sides are better than four. Let’s elaborate.

 Actually this was one of the more heated discussions we had when designing the combat system. There are times when game development can lead to combat only it’s usually resolved with arguments and words instead of the use of force and weapons. If that doesn’t work out we have those handy swords around from our LARP player. We usually tell visitors they are for our animator to try out stuff. Let’s just say they can serve other purposes, too and not go into much more detail here. One strong argument for hexes was that they add more depth to combat. Six sides are just better than four.

Reason one: Movement costs are more obvious. The distance from any position on the hex grid to the center of the next position on the grid is same for each of the six adjacent hexagons. There is no diagonal movement to an adjacent square that only touches the field you are currently on in a single point instead of sharing a side with it. With squares you either have to make diagonal movement cheaper (and thus preferable and exploitable) as moving two squares to reach the same diagonal one or more expensive than moving a single square. With hexes you move one field and it can always be the same cost. If you have played D&D 4th Edition (which will let you move diagonally at the cost of one square) you will know the urge to exploit that apparent “extra ground” you can cover by moving diagonally. We felt that in a video game where you want to simply point at your target field and have the character move there it was easier to calculate the path to go.
Reason two: With hexes you can have a clear facing into the moving direction. With squares you either have to start implying that it is actually an octagon you stand on and you have eight directions you can have your character face in or make facing be irrelevant (as D&D 4th Edition did where it is only relevant that two enemies cover opposing squares adjacent to the one you are standing in). We wanted facing to be relevant for actions like backstabbing since trying to get into the back of another character (or trying to make sure the back of your own character is covered) adds more depth to the decisions made in combat.
Reason three: Outside of combat we have a world that is supposed to look natural or even organic. So we do not limit our level designers to build the levels on a grid since the grid will only be relevant in combat and combat is only a part of the game. Most parts of a level may never have the grid enabled since there will never be a combat encounter in them. And with a simple test we found out that the hex grid covered the ground of the existing scenes with ease while it would be more likely to have to readjust scenes around the square grid which seemed to have advantages inside buildings with straight walls and rectangular corners (at least if you new from the start that you were building them for the grid) but not so much on a path in the woods where some rocks lie around or fallen trees cover some of the ground.














Seems pretty clear that hexes are the way to go, so why the heated discussion mentioned above? Simple reason: For pen & paper it’s easier to prepare a map on a square grid, at least unless you have some experience working with hexes. Since we prototyped much of Chaos Chronicle’s combat system on paper some of us were reluctant to give up the squares at first. The argument had to be settled with LARP approved foam weapons. Just kidding. We did it like the pros: Building a software prototype with the hexgrid in it. It worked and everybody was happy.