Uh-oh, now that we have passed the half mark of the challenge, stress is slowly but surely building up…

Yesterday, I was able to accomplish 2 of the 4 items I set out to complete. The ones that made the cut were :

Time management and forbidden zones!

Time, as shown by the clock on the right side of the screen.

Time came first, because it was a prerequisite for the forbidden zones. I had outlined the code on a piece of paper during lunch, so it all went without much problems. It was also the occasion for me to solve a bug that is present in libtcod where 2 keyboard events would be sent each time a key was pressed.

From a design standpoint, I do not know yet if I want the time to be so precisely displayed for the user. I may try to only display day, hours and minutes while omitting the seconds. That would add a level of uncertainty to the game. I want to have some of it, but I also need to be very careful not to make the game feel cheap.

When time was working, I went on to work on one of the big features of the game : the forbidden zones.

A tragic death… He could not escape the forbidden zone on time…

I think that there a three things that make the ‘Battle Royale’ program a particularly interesting setting, and by consequence could make for a different and interesting game.

• The survivalist aspect. Granted, it is not really this characteristic that sets Battle Royale apart from many other stories, but it still is something that is very compelling. Having to explore an environment and depend on what it can provide you with is really a strong driving force to use in a game.
• The gradually increasing tension. By combining a time limit, the fact that contestants are becoming increasingly fragile yet better equipped (because they collect the weapons and tools of their victims), and finally the ever-shrinking battlefield, you get a natural crescendo in the game intensity.
• The social component. A last capital aspect of Battle Royale is that the teenagers forced to kill each other know each other pretty well, as they are all from the same class (barring a couple of extra ‘transfer’ students joining for the occasion). Because of that, cliques try to stay together, couples try to hide from others, grudges resurfaces and some are running around looking for friends while other hunt everyone they can find. It is much more complex than a simple deathmatch where everyone is at each other’s throat right from the start.

The first and second aspect will be included in the game given what I have been able to implement right now. I would love to get a rudimentary system in place for the third one, but I fear I need to get into ‘feature cutting’ mode right this instant. There is not that much time left, and still a lot of things to do… Wish me luck!

The third day was dedicated to a very important aspect of BattleRL : the combat. I had other commitments yesterday, so I could not devote as much time as I had hoped to the game, but I managed to get the melee combat mostly working.

The beginning of the combat system.

Working on the combat made it necessary to work on a bunch of other systems as well. First, the message log. As with most roguelikes, BattleRL will feature a region of the screen where descriptions of what is happening are displayed. Currently it writes the latest message in bright white, while the two previous ones are written in a darker gray so as not to be confusing.

Later on, and by later on I mean today, I want to hook the log to the timing system. A message would then only stay white for, say, 5 or 10 minutes in-game, before becoming grayed out. This will be a way to provide situational informartion to the player. For example, if a firearm is fired somewhat close, the player should know the rough direction the sound comes from so that he or she can plan their strategy accordingly.  Knowing that a white message is habitually still relevant will be, I think, a good thing.

Apart from the message log, I also needed to but another actual character into the game so the player could fight it. I used the opportunity to craft a fairly general ‘character’ class which is now used both by the player and the other characters. At that point, depicted on the picture above, I could bludgeon the poor guy to death without him being able to do anything about it. That was because the melee combat works in the same way it does in most roguelikes : you need to ‘bump’ into your opponent to strike him. As said opponent was not moving, he could not retaliate.

So I had to change that, and added the first ‘artificial intelligence’ to the game. It was not very smart though : the enemy now moved randomly around the map. Still, that meant he dealt blows, albeit randomly.

Managing to kill a randomly moving opponent is more difficult than you might think…

Tonight will be a very important night for the game, as I will be adding other crucial features (to be fair, they are all kinda essential…) to it. In no particular order :

• Time will be introduced. The way I want to make it work is that each action will have a cost in time. I will be going with a base cost of 15 seconds for a basic action (moving between tiles, attacking in melee, firing a simple firearm), with some action taking more or less time, for example running will let you move faster, but probably will cost you something, like making noise or tiring you more quickly. The game will maintain a queue ordered by time, and step through that to determine who will act when. And each time any entity do something, it will be reinserted in the appropriate place in the queue. In a way, it will be similar to Final Fantasy X or most tactical RPGs.
• Along with time, I want to put in the ‘forbidden zone’ mechanic. At each hour, a new zone of the island will be declared ‘forbidden’, and any character in it will have to get out of it before the announced time or be killed. This will hopefully make for some tension when the player realize he really is in a bad position, maybe pinned down by an enemy, and need to get moving fast. It will also serve the purpose of bringing the remaining survivors ever closer so that opportunities for fights continue to happen. Maybe your stategy will be to let the others kill each other while gathering supplies in order to pick off the last ones when they cannot hide anywhere?
• There will be ranged weapons in the game. Since BattleRL will only let you move in 4 directions instead of 8, their range will have to be computed accordingly. It will seem a bit counter-intuitive, but I think that it will not be that big of a deal, and will preserve the balance of the game.
• Finally, I want to make the AI less dumb by adding a new behaviour  to the enemy. For today, I simply want to make the characters move randomly, except if they see another character, in which case they will either shoot, or go towards him/her and try to use melee, depending on the weapon they have.

So as you see, that is quite the big plans for a single evening, but much of it seems pretty simple to me programming-wise. So hopefully tomorrow I can write about how it all is coming together. If that is the case, I can add win/lose conditions, and from that point on, everything will be extra polish! The rest of the week is looking bright 🙂

Day two was also productive thanks to libtcod’s included algorithms. It still needs some tweaking, but I was able to get the field of view computed and running in a very short time. That meant also adding the traditional ‘@’ character to depict the player character, and making him move around correctly.

Field of view rendering.

I still need to adjust a couple of things for the field of view:

• I do not want it to be coputed on a square, but on a circle around the player.
• I need to have three states for the tiles : undiscovered, invisible and visible.
• I want to experiment with limiting the angle for the field of view computation.

But again, for day 3 I would rather move on to combat, so that when I come back to that to refine and balance all the previous systems, it will be in relation to the other systems, to assess the ‘fun’ of said tweaks.

So, how did day 1 of coding for the challenge go?

For most parts, it went well. I managed to get most of the map generation out of the way, and while I am not completely happy with it as of right now, I think that it is a good start that should enable me to get some idea of how the gameplay works once I have it in there.

Water, trees and building with no entrance.

I decided to go with a map of 500 by 500 tiles, wich makes for quite a big map, but one that you should still be able to explore if not completely, at least well enough. I will have to determine the relationship between the size of the map and time – after all, you only have three days to emerge victorious – but that will happen when I can actually playtest the game. It may be that the map is too big for creating interesting gameplay too, so everything at this point is up for change.

From the technical part, I based myself on this article but simplified : The perlin noise I generated was not fractal, so the level of detail was way lower. That is one of the things I want to revisit in the world generation, given I have enough time. Right now, the islands are really blocky, their shape is as uninteresting as can be. While I do not want to take height into account, having a ‘strange’ shape should make for more interesting subsequent games.

I am also not sure on the look I want the game to have. I really want to differentiate between nighttime and daytime, but how exactly… I do not want to spend too much time on graphics though, I would much rather devote more time to the actual map generation or to the polishing of the gameplay. Yesterday I tried both using only characters (as above), or background colors (as below).

The map with background colors for the tiles.

The main ‘issue’ with the current map generation is that it takes a whole lot of time to create the island. I would like to adress that.

But apart from working on the map generation, I think I managed to do a good amount of things ‘in the backend’ : the map scrolls inside a limited viewport leaving space for the message log and the rest of the UI, for instance. How these will pay off remains to be seen, but as of now I feel I have a good grip on things.

My next step is to throw the player into the world. That means field of view, checking for passable/unpassable terrain, and maybe adding the various bars in the right sidebar.

If possible, I would also want to take an hour to use a file-based description of terrain tiles and objects in preparation for day 3, which should be devoted to combat mechanics. Stay tuned!

It has been a while, how are you doing?

This month is a good one : the sun starts to come out more often again, the temperature increases, and, most importantly, the 7DRLC is just around the corner!

What is that gibberish you ask? Well, 7DRLC stands for ‘Seven Days Roguelike Challenge’, a week long game jam where the goal is to write a roguelike. Simple enough. And this year will see me participate for the first time. The jam starts when you decide on saturday or sunday, and will go on until next weekend, same time as when you started.

Choosing an idea was the easiest part. For the longest time, I have wanted to start working on a roguelike based on the book/movie/manga ‘Battle Royale’. So that is what I am going to attempt next week.

May the ASCII serve me well…

My battle plan is to keep the game as simple as possible while evoking some of the key aspects of the Battle Royale ‘atmosphere’. I will be using libtcod and Python to be as comfortable as possible with the coding part and be capable of debugging efficiently.

I have yet to make a day-to-day schedule, but I have broken down the functionality I want to add along the way, it goes like this :

• Map generation : generating a flat (no height shenanigans) island-shaped map, with some simple features such as lakes, rocks, and trees or the odd building here and there;
• Movement and field of view : I will probably end up using something quite different for the handling of the field of view, but I will need to see if it is actually fun or not;
• Other students and combat : Surely limited to bump-to-melee and ranged attacks. Though depending on how the field of view thing works out, things could be a little more involved.
• Time and forbidden zones : A key element of Battle Royale is the fact that the students have only 3 days to kill one another, so time should, and will, play a role;
• Ressources : I hope to add some kind of food/water/other ressource management to increase the ‘survivalist’ part of the equation, but this will depend on the time;
• Other ‘flavor’ things : I have a list of other features that would reinforce the theme, but I will neither spoil them here nor implement them if time is short;

So there is my plan in vague terms, I do like that it is a 6-item plans, because if I can manage one of them each day, I will be left with a full day to polish/debug. And that seems like a pretty good idea.

I will be around during the challenge, either posting more updates, on the #rgrd channel, or on various social networks. See you around!

My January game is coming along nicely (I think so, at least), and that is an awesome feeling.

It is now the tenth, and while I had divided the work into four ‘phases’, so roughly one per week, I completed phase II this morning. So I am ahead of schedule, even if I realise I am doing the easiest part right now. The final polishing rounds are what is going to eat up all my time. But still, the game is starting to feel like one, and I will be able to start working on the next big feature.

So, before I give you the link to the new build, what have I done since last time ?

Looks

I have made some progress in the overall look of the game. I am still not completely satisfied, but for now the textures look fine most of the time, and the camera movements are working.

The goal is now visible, and when you reach it, the camera will orbit around it.

Interface

I have shared a picture of it already, but I have the basic functions of the game menu working, with two screens (one for the main menu, one for the level selection). I am happy with the overall look, but the layout needs some tweaking as was pointed to me by @Dastyni. I also have disabled the arrows and by default set the input to a dual WASD/ZQSD to have standard FPS controls both on azerty and qwerty keyboards. You can now also restart the current level by pressing ‘r’ or exit to the menu with ‘esc’. The transitions are a bit brutal though, and I still need to find a way to hide the mouse cursor, but there are still more than 20 days left!

The main menu, with 2 buttons working.

This is the level selection screen. I hope I will be able to include all 4 of them!

Level design

In addition to the toy level (which is now level 1), I added a more large-scale level to get some feedback. In the next build, there should be checkpoints mid-level and a death mechanism so that it does not feel so frustrating when you fall from way up high. I can beat the level pretty consistently now, so I am no longer a good judge for its difficulty, that is why I am sharing this build. Do not hesitate to give me some criticism in the comments!

The new level. How fast will you reach the top?

So now on to the links, but before a quick warning/question : on the Windows (and maybe Linux) standalone build, I get a message stating that the levelX files are corrupted in the development console. I have no idea how to fix that. Any Unity guru knows what is going on?

Anyway, get the game, and have fun (and give me some feedback if you have a couple of minutes to spare 😉 ) :

Web – Windows – Linux