Ringfort Design Blog

Well, we just had our final presentation. It was originally supposed to be a practise this week, but things happened that caused it to be moved forward. Not the best reception we have had given the viability presentation, and some of the desk critiques, which I haven't mentioned a lot since actually being able to do programming work. Partially because the work was my focus and easier to post on, and partially that the desk critiques were generally the same, so to speak. The feedback was relevant to every week, but each week came down to various levels of “You have done well/good/not quite enough” combined with “You need to/haven't seemed to consider this aspect/design choice/etc.”.

About the presentation. Things went mostly well. Our video was too much trailer and not enough game play demonstration. Our presenter focused to much on his personal opinion on where our game would sit on the market and not enough on research and figures. And we didn't have much, if any, reference to where we were headed in the future with the game.

It is a little disappointing to do the final presentation and be getting some serious feedback, which are all things we could have worked on for it if this had been the practise and we had another week before the final. I think it almost goes without saying that I feel that our group could have nailed the final presentation 100% if that were the case. Unfortunately not, but fortunately the marker is taking that fact into consideration when marking them.

That said, I still think we did well. I am proud to be on this team, working on this game. When I was looking at the groups that were presenting their ideas in first week and say that the first one up was called Ringfort I thought “this could either be a really cliché game idea, or a cool and original one”. Then when I saw that it was already a group of three I thought “I probably don't want to join up with these guys anyway, because they probably already have a rapport and integrating into the group might be difficult”. Very fortunately I found the game idea cool and original enough to get me to at least email Daniel straight after the presentation, and all three of them were easy to get along with guys who were happy to welcome another programmer on board. And I haven't regretted the decision once. Sure, there have been other game ideas that looked cool and I thought “I would play that” or “that might be interesting to work on” but none of them resonated with me like Ringfort did, and I only hope that as we continue this game into the next semester that I can do it justice.

This will be my last post of this semester, but I hope to be able to continue it into next semester (assume that isn't a requirement) provided that I am not so busy making the game that I can't share it with whoever actually reads these posts.

So we are very rapidly approaching the end of the semester and there are still things that haven't been implemented, even in a rudimentary way. By things I am referring to the morale system and beastfolk interactions (not sure if I mentioned in an earlier post or not, but we decided to call the units in the game beastfolk rather than beastmen. Beastmen just made me think of Gurren Lagann, where as beastfolk has a much more fantasy feel to it in my opinion). So while we do not have these we now have everything else to a greater or lesser extent. We have buildings, units, resources, and even quests. Yes, we now have questing in the game, even if it is a very basic form.

Initially, there was one quest that appeared on the second day (so the player had to end day once) and then completed automatically on the day after that, giving the player some wood as a reward. This was mostly to test that we could successfully create quests, a notification button for them, and have them dispense rewards when done. Then we went a step further and added unit assignment to the quest (this was thanks to Patrick and Michael as they had already done something similar with assigning units to buildings). The quest was then altered to only finish the turn after it had at least one unit assigned to it. This is were I left questing for the time being as there is other assessment to work on, but Daniel and Mitchell are working on small number of better fleshed out quests with proper descriptive text and all, that we are hoping to have present in the final prototype.

In an earlier blog post, I mentioned that the building preview turned red in places that it wasn't allowed to be placed. This worked fine for showing that you couldn't place a building on a tiles that already has a building or some terrain. But there are other restrictions on buildings, such as lumber yards needing to built built adjacent to at least one tile with trees, or a rabbit house needing to be adjacent to a shrine. So to do this I had to do further research into hex grids and their coordinates. This website was really helpful (http://www.redblobgames.com/grids/hexagons/implementation.html). It describes different coordinate systems as well as pseudo-code for each system on how to do many things, most importantly to us, finding a range of tiles within a given radius of a given tile. However, it is only pseudo-code and it only finds within range of the centre tile in the grid. I needed to write a C# implementation of this but also generalise it for any given tile, not just the central one. Below are images of all the math work trying to debug the original implementation before I realised that I would need to mathematically work out some limits for the alogrithm to work as intended

As we head forward with the prototype, it became very quickly apparent that placing buildings was difficult without some sort of preview as to which tile you were building on. So I made it my job to make a transparent building preview that appeared on the tile a building would be placed, which would also highlight red when hovering the mouse over a tile that was an invalid place to build.

Sometime after we also wanted a tool tip next to the building buttons to tell the player what the building is, what is cost to build, and a (very) brief description of what it does. This is because we wanted to move to buttons that Weren't just words, but images of the building, which I think is a choice that really fits the style we are going for in the game's art.

Here is a video one of the other group members made which demonstrates the building preview and tooltip:

So we have reached a stage of development where loading up the game with a blank grid each time you start isn't going to cut it any more. To solve this issue, I wrote a simple pair of save / load functions. The save function works by looking at each tile individually and writing a specific character to a text file. The load function then reverses this, by adding the appropriate terrain / building to the tile based on the relevant character in the file.

Personally I kind of dislike this approach. It feels cheap and hacky to me, and I am sure there is a better way to do it. Needless to say this will have me looking into better ways of saving and loading for the full game. For the prototype however, it is functional.

Then I spent some time “hand drawing” a map. Placing terrain and initial buildings (i.e. the walls of the ringfort) so that we had something to load.

At the end of my previous post, there were obvious alignment issues with buildings/terrain being placed onto the grid. So after some thought, the following is what I came up with:

What you see here is basically a way guaranteeing that the centre of a given object is in the centre of the tile it is on. This works only when the artist draws the sprite for the object with enough “padding” (transparent pixels) to put the centre of the object in the centre of the image. So if you have a very tall building where the ground floor room is at the centre of the tile, the sprite needs to have as much transparent space under the room as it has space above the room.

Here are some images of objects of various sizes lining up to the grid:

So it was my job to implement the hex grid for our game. Given that I have never made any type of grid based game, let alone one with a hex grid, I had to do some research. By far the most useful resource that I looked at was this one: https://tbswithunity3d.wordpress.com/2012/02/21/hexagonal-grid-generating-the-grid/

This was most helpful as it gave example code for making a hex grid in unity. However, it is designed for hexagons with even length sides and a corner at the top of the hexagon. So some modification had to be done as we use hexagons with a flat top and longer sides on the top and bottom than the edges. It gives it a somewhat squashed look, which is what we want for the isometric view that we are going for.

After figuring out how to make the hex grid, it was time to take it a step further. and utilise the object placement code that Patrick had already written (to familiarise himself with raycasting in Unity) and apply it to the hex grid. Unfortunately, due to the way I was creating objects on the grid, and the dimensions of the original placeholder art, it ended up looking like this:

This part will cover the quest system. Players can receive different types of quests, from building a specific building assigning units to the quest to act as guards/escorts/diplomats/etc. Different units will have different combinations of statistics for completing assignment quests, e.g. the warrior like Bears have a strength primary stat. Currently, the group is decided upon three stats: Brawn, Wits, and Agility.

To succeed in a quest that involves assigning units, a player will need to beat a threshold number in a specific stat with the combined values of units assigned to the quest. As an example, let us say that you get a diplomacy quest to which you can assign three units. While you have no idea what the threshold number is that you need to overcome to guarantee success, you can increase the odds of successful diplomacy by assigning three units with high Wits scores.

If we continue the previous example for a moment, let us say that the quest’s description was given with veiled threats. Now it could be a diplomatic quest given begrudgingly given by a not quite hostile entity/organisation, or it could be a combat mission where the veiled threats are there to let you know that you men will be ambushed as soon as they make it to the meeting grounds. The third option is that it is a composite quest, where you can win either by diplomacy (Wits) or combat (Brawn) as long as you meet or exceed at least one of the thresholds.

So after drafting this blog post, I realised that it was huge because of two reasons: One, I have a number of things to cover, and two, huge wordy examples. To remedy this I am splitting the post into two. This one will contain the smaller bits I wanted to cover, while the next post will contain everything pertaining to quests, as that was where all the long winded examples were and I need to rewrite it to make the word count look less like the Silmarillion's.

The general concept of the game has not changed since the last update. This update is about where the prototype is headed at this point in time (no use worrying about the full game when we need to make the prototype first). Some ideas have been fleshed out and some have been appropriately capped in scope to make the prototype more viable.

The first thing to cover: Beastmen Races. It will not be feasible to implement a large number of beastmen races with varying levels of interaction in the prototype. To make the prototype more viable, we are only having three races: rabbits, foxes, and bears. Each one will have a focus on one of three statistics (Brawn, Wits, and Agility) that have an impact on certain types of quests. More about that in the next post. They will also have inteactions based on simple ideas such as "Rabbits dislike Foxes", "Rabbits like farming", or "Bears dislike mining".

The second thing to cover is: Resource Gathering. While not all the resources for either the full game or the prototype have been decided upon yet, there have been some decisions about resource gathering that affects resources as a whole. Firstly, resources will compound, i.e. you can continually build up your resources if you do not spend them.

The other option we had considered was a static economy, where each turn you start with a number of resources based on the structures you have to gather them, but decided against it as an economy where you can save resources means that the player can choose if they want to play frugally by spending time saving some resources for a metaphorical rainy day.

Well, I guess we kinda flubbeded this presentation. We ended up making it all about the theory, because none of use thought that reitterating the core game concept/mechanics for a third time was essential. None of us took into account that apparently these presentations were not like a three part series but more of a second and third try at doing the first attempt "right". Because of that we didn't get a lot of feedback to walk away with. The worst part is that we had other things to talk about planned, but Daniel forgot to mention them, and while he'll try and take the blame for that, none of the rest of us (and we were all there for this presentation) jumped in, we just left it to Daniel.

So if we consider the feedback from all three weeks as a whole and what we presented each week, then the biggest thing we are missing is the scope of our prototype. In hindsight, this is something that is quite important at this stage as the next few weeks are all about viability and we cannot know if our game is viable without knowing what we want to put into it. So in these future weeks, one of the things we are definitely going to have to do is work out the scope, or at least a very good idea of what the complete scope might be.

One last thing, here is some early concept art that Brandan has done to give us a demonstration of his style.

This week's presentation was fairly similar to last week's, in that it was mostly Daniel presenting the core mechanics of the game. The main differences were that Daniel added elements that we had talked about in a meeting that occured in the week between presentations. However, it seems that we may have slightly been "putting the cart before the horse" as Laz put it, as these elements were all core features that needed deciding upon very early into development, but didn't need doing as early as we did. We also failed to include a slide about the theory behind our game, i.e. what types of play it involves, and the types of players that it would attract. I was not a direct part of creating the presentation for this week, and because no one had booked a timeslot earlier than ours, the presentation was pulled forward and I was only there for the feedback. So, what we definitely need to have for next week is something on the theory.

Since the blog has been prettied up a little, time for a break down of the game concept as it stands.

In Ringfort you take on the role of a small number of humans who are living in the protection of a ringfort against some kind of hostile force. Previous talks referred to them as the dholes, a vicious, more-animalistic variety of beast-men that were based on these guys. This aspect may no longer be part of the game however as there was talk about making the game more of a city builder and its reward being the joy of creation. Moving on.

As the small numbers you are, you can/will not survive long (especially if the dhole-men are still a thing) and so you need to ally yourself with nearby tribes of beast-men to start getting their populace to move into and around the area near your ringfort to build up your numbers. Each race of beast-men have different requirements to get them to start moving to your fort. For example, the rabbit-men only want security so you need to build their shelters behind walls, where as the lion-men might have three or four individual conditions that need to be met because they are proud and think of themselves as better than other races.

Once you have gotten some beast-men to move to your growing settlement, you can assign them to different roles. Each different race has different tasks that they excel at, and different preferences towards the different tasks. Take the bear-men, their large stature and great strength makes them good fighters, but also makes them great farmers. However, the bears are more aggressive than some of the other races and would prefer fighting to farming, so assigning them farming jobs lowers the morale of the internal bear populace.

Speaking of morale, each race is supposed to have its own gauge of what their morale is like as a whole. Their morale is affected by factors such as: what jobs they are performing and if they like that job or not. what other races are living in/around the ringfort and what their morale is like, et cetera.

One last thing to talk about. Above, when talking about morale, I mentioned “other races and their morale”. This is because some races are natural enemies. As the above image demonstrates, rabbits and foxes are not friendly toward each other. So when one is “happier” (has higher morale) then the other is going to take a morale hit because they don’t like their enemies being better off than themselves.

The first entry my design blog for the group project I am working on, Ringfort (actual title undecided, though this might stick).

Last Friday were the presentations and Ringfort was the first one on the block. The group was already comprised of Daniel Docherty, Patrick Freeman, and Mitchell Holloway, who were looking for an additional programmer, an additional artist, and a sound designer. I was taken enough by their game idea that I sent an email asking to fill the position of second programmer.

Speaking of the game idea taking me, I should probably talk about what the game is, as best as I can recall from the initial pitch. Unfortunately I am short on time at the moment and can only make this short (and undrafted) post.