Your shoes and the world to come...

BattleRL : Day 4 progress report

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!

BattleRL : Day 3 progress report

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 🙂

BattleRL : Day 2 progress report

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.

 

BattleRL : Day 1 progress report

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!

BattleRL : a 7DRL

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...

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!

#OneGameAMonth
A step further

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.

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.

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!

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?

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 😉 ) :

WebWindowsLinux

 

LD #25, the aftermath

So, the 25th Ludum Dare rating period has closed, so it is time for a little mathematics.

The first key piece of information is that there were 902 entries in the competition (1327 in total). That gives a frame of reference for the rest of the numbers.

So let us delve into the results :

Overall : #128 (3.45/5)

This ratings is the ‘main’ one. And the result is not half-bad! In fact, it is by a good margin my best entry so far if you take the size of the competition into account. I have made, so far, 3 entries in the main compo (2 others were jam entries, and the rest I have not been able to complete on time). The first one placed 231th out of 242 overall, and the second one was 61th out of 288.

If i take the ratio (rank)/(total # of entries), we get (the lower the better) :

  • LD19 : 0.95
  • LD20 : 0.21
  • LD25 : 0.14

So I am on the right track, I placed in the top 15% of the competition. That makes me really happy, of course! Let’s take a look at the other categories in alphabetical order.

Audio : #129 (3.16/5)

My game had not much in terms of audio content (two short and simple guitar tracks and a single sound effect), but they seemed to be quite well received. I still think sound is one of the most overlooked aspect of a jam game, yet one of the most important one. Audio really sells your game world to the player, and really makes it seem more polished.

I cannot make any comparison with the LD19 game, as my entry did not get enough ratings to place in that category, but I placed 36th in audio with my LD20 game. In terms of ratios :

  • LD20 : 0.125
  • LD25 : 0.14

So while I did a little worse (the music was more integral to the experience of the LD20 game I think), I am still in the same ballpark. I think I need to focus on the quality of my recordings to move pas these kind of scores, and maybe think more about the sound effects, or even do some sort of voice acting. Still a good score though.

Fun : #358 (2.85/5)

I do not think my game was very ‘fun’ in a typical way, as it was very methodical and lacked a bit of polish to not be a memory on steroids. The payoff came only for those willing to beat the game, and even then it was more a neat tidbit of information than anything else. So still a good score for that game. Again, I did not get enough ratings in LD19, but let us compare against the LD20 one, where I was 75th :

  • LD20 : 0.26
  • LD25 : 0.37

So a fair bit further down. But again, the idea behind the LD20 game was simple and focused on a very visceral sensation : it was a runner. The turn-based, slow-paced game I made this time was decidedly less ‘fun’, and it shows.

Graphics : #244 (3.25/5)

I was pretty happy with my output this time, it being my first really pixel art-based game, but I knew from the get-go that I could not hope to top my score from the LD20, where I was 13th in graphics with a 3D game. I did beat my LD19 entry though, wich placed at a pretty low 144th place. But as far as ratios go :

  • LD19 : 0.59
  • LD20 : 0.04
  • LD25 : 0.27

So, yeah, still a good final score for that. I have a hunch my next LD game will be in 3D though, but with me joining a now very numerous group of people making 3D stuff (as opposed to LD20 when it was more uncommon), I think beating my LD20 ratio will be my main goal for the forseeable future.

Humor : #330 (2.63/5)

I do need to focus on my writing, even though I do not usually do ‘funny’ games. Here the humor was not really in the mechanics, but really in the text, and it was not so funny. The score is decent, and at least this time I placed (not like, again, LD19). In the LD20, I was 178th in that category. Which gives us ratios of :

  • LD20 : 0.62
  • LD25 : 0.36

It was better in that department, but clearly still an area I need to progress in!

Innovation : #209 (3.2/5)

Innovation should be a cornerstone of many jam games, yet mine are not really good in that category. I hope to improve that in the next year, hopefully with the help of the #onegameamonth challenge. In LD19, I placed 69th, while LD20 saw me at the 209th place. In ratios, it gives :

  • LD19 : 0.28
  • LD20 : 0.51
  • LD25 : 0.23

So my best effort yet, and obviously better than a simple runner. I feel it deserved to be in the same general ballpark than the LD19 entry, which idea was not as fully realised as the one in this entry, but equally ‘innovative’. Two categories left!

Mood : #59 (3.55/5)

This is the best aspect of my game this time, and I am extremely happy about it. I tried really hard to have all the elements of the game come together supporting the same aesthetic, which was tied closely to the setting of the game. It obviously paid off, and was the main point I got feedback on. It is a new voting category that was not around for LD19 or 20, but it gives me a ratio of 0.06, almost on par with the one for the Graphics of my LD20 entry. So I was really happy to discover that score this morning!

Theme : #128 (3.75/5)

Again a quite good score! I was also quite happy with my interpretation of the theme, which is quite literal while having another layer of meaning to it, and again it paid off. For LD19, I was 121th, while for LD20 I placed 209th. As for the ratios…

  • LD19 : 0.5
  • LD20 : 0.72
  • LD25 : 0.14

So, yeah, I think the numbers speak for themselves. I really opted for a dumb way out for LD20 (I had the game idea way before the compo), and my LD19 entry was so-so. So this is something I will try to keep up next time.

Conclusions

I could dissect the numbers all day and draw various conclusions, but I will simply look at two last things. First is the range of the ratios for each entry :

  • LD19 : 0.28 to  0.95
  • LD20 : 0.04 to 0.72
  • LD25 : 0.06 to 0.39

The conclusion there is clear : I am doing better (or the others are doing worse). My scores were, this time, all in the upper 40% of the rankings, and my best score did not come down too much. If I can keep the level up, I can hope for some good things.

The other things that I need to check if I want to get a more objective picture of my progression are the actual scores. Here they are (all out of 5) :

Category LD19 LD20 LD25
Audio N/A 3.38 3.16
Fun N/A 3.25 2.85
Graphics 2.6 4.19 3.25
Humor N/A 2.2 2.63
Innovation 3.2 2.94 3.2
Mood N/A N/A 3.55
Theme 3.0 2.31 3.75
Overall 1.8 3.25 3.45

So, while I could not replicate my highest score of 4.19, my LD25 entry fared better in the big picture. So my first conclusion still stands : it seems I am improving. Eventually, I hope using a more modern engine will let me put out something that has the same kind of aesthetic ‘flair’ as my LD20 entry while maintaining the overall quality of my last entry.

Thank you very much for reading all this, if you have similar breakdowns of your scores, I would be interested to read them, so drop me a comment or a link or a tweet or something ^^ ‘Till next time!

#OneGameAMonth
The first prototype

Since the new year is there, I have started to work on my first game for #OneGameAMonth. Which means I have (finally) started learning Unity. I have always been very interested in Unity, but had held off on learning to use it because it did not offer an option to export to Linux. Being a Linux user myself, I require that my game should at least be available for that platform. But with the release of Unity 4, that is no longer a problem, so here I am.

On January 1st, I installed Unity and got to work, discovering just how brilliant it is. For once I felt like a was making a game instead of simply coding ‘technical’ stuff. So sure, there will be a fair bit of coding to do, and a new language to learn, but the fact is I could really start working towards the vision I had right away. Well, I did get distracted and added terrain, trees and the likes, but since then I have gone back and actually gone forward with my original plan.

Said plan is very simple, and is meant as a learning tool for me, as well as hopefully guaranteeing I can release on time. The gist of the idea is that it will be a timed first-person platformer where you need to climb towers or other structures as fast as you can. And after less than ten hours, I have a proof of concept running.

Hop to the top is the name of the game.

Hop to the top is the name of the game.

So yeah, it is pretty crude, and not all that interesting, but it is working in far less time (while being much more pleasing to look at) than it would have taken me in an engine like Panda3D, even if it is Python and I am pretty familiar with it already. As this prototype has all the gameplay elements in place, and is midly fun for one minute, I will build on it. If you want to know what I am planning, I have set up a workflowy task list that is shared and which you can view here. This will probably be the place where I will put all my roadmaps and most of my design thoughts and decisions throughout the year, so you are welcomed to save the link.

Without further ado, I am going to get back to work, but not without letting you download a first build of that prototype for feedback. It is available for Windows and Linux, or you can play it directly in your web browser, let me know what you think (and if some of you want a Mac OS version too) in the comments! (And my best score was something like 2.59 seconds, for your information.)

2012 in game dev
: : GSM Productions : :
or
Ahead of us

Happy 2013 everyone! Hope you all enjoyed the festivities of yesterday, and are ready to dive into the new year full of energy and renewed motivation. That is certainly the case for me, and so I would like to close my “2012 in game dev” series of posts with one that has an eye set on the past year, but the other firmly turned towards the future.

Thus, the final topic of this series will be… GSM Productions.

GSM Productions, a logo that still has to be attached to a full game.

GSM Productions, a logo that still has to be attached to a full game.

For those of you with a keen eye, you will have seen that this blog is hosted on the GSM Productions domain. Yet, if you head to the main website, what you will find is a semi-dead, quite empty website. Something about a small indie team from Belgium and stuff, but nothing more (if you do not count the endless ‘a release is coming soon!’ posts).

So, as a quick recap: GSM Productions is the name of the team me and two friends – another programmer, and an artist/web developer – formed a couple of years ago after deciding to try our hand at making video games. Due to several reasons, which I will not delve into too much here, we only released a couple of semi-finished games that are not even listed on the new wordpress-based website, but nothing more tangible. Even then, we have been working on several projects all this time, and we feel ready to get things to the next level.

If you are also full of motivation, or if you need some. INDIE HIGH FIVE!

If you are also full of motivation, or if you need some. INDIE HIGH FIVE!

The end of the year is always a time for reminiscing about and assessing what you have done in the past months, and we took that opportunity to put everything we had going on the plate and discussed what we need to do in 2013 to not only finally release our first ‘full’ game, but through that taking steps towards making sure we would have a shot at someday making game dev our ‘real’ job. It may be a far-fetched dream, but it is one we are ready to pursue nonetheless.

So, after many game jams, prototypes and noodling around with various technologies, both me and Thomas (the other coder) have decided to sign in to the One Game A Month challenge, to help us hone our skills in a more regular fashion. And in parallel, we have actually decided to go back to one of our game jam games and improve/polish it to release it as our first game.

If you read our team blog archives, you will see that we had an ‘almost done’ tower defence game, Alun Hevel. While we are not abandoning it per se, we decided to keep it as a ‘background’ project, because to be honest, there is not much in that game’s design or execution that excites us. We realise that we need to aim low at first, but that game asks for not only a great deal of content, it demands an even greater amount of balancing. And that is something we will do on a longer period of time, but the very slow development pace, coupled with a very big loss of interest in the game, drove us to this decision. Hopefully in a couple of months we will look back on it and feel confident that it was the right choice.

Alun Hevel, in its first playable version.

Alun Hevel, in its first playable version.

So there you have it. 2012 has come and gone, and I personally feel deeply grateful for everyone that has crossed my path in so many different ways. From close friends working with me on projects to famous devs inspiring me with their work or their words. From film-makers that made me smile to studios giving a glimpse of what it could be like to work on games for a living. For all the tweets, all the +1’s, all the comments, the unexpected replies or gifts…

For everything. Thank you.

And let us all blast through 2013 with brilliance!

(And to keep in line with the tradition, you can follow me on Twitter, Google+, or subscribe to this blog, or follow our team on Twitter or Google+! Thanks for stopping by 🙂 )

2012 in game dev
: : Dark Acre Jack : :
or
Razor sharp

If one indie game developer is deserving of the term ‘badass’, it is the one to which this post is dedicated. This is a person that has influenced me in many ways, both consciously and unconsciously. This fine gentleman is Christopher ‘Jack’ Nilssen, running the one-man outfit known as the ‘Dark Acre’.

Dark Acre Jack.

Dark Acre Jack.

Earlier this year, I wanted to take up running again. It did not work out as well as I hoped it would due to me letting days slip without having the mental fortitude to carry on my running routine. Yet, I have tried again and again because I have a clear goal. A strict plan. And that plan is actually the one Jack put out on the web (you can find it here if you are interested). It may not look like much, but reading, on his blog, about the results from that plan and having an example of someone sticking to it makes it, to me at least, more than just a list of progressive running times. It was a set of footsteps to follow.

Then, the Dark Acre blog is full of details about the organisation and discipline that Mr Nilssen has set for himself in his now full-time indie dev life. This is invaluable to me, and his whole story is one I find immensely inspiring. And while he still has to release a full-scale game on his own, he already has made a lot of smaller projects, most of which oozes a style I find extremely appealing. The most recent example of that is his entry for the last Ludum Dare game jam, called ‘The Condemned’. The dark and brooding mood which seems to be prevalent in most of his games make them really cool to me.

Another influence Christopher Nilssen has had on me, albeit on a more subconscious level, relates to his sense of polish. Everything from his website to his games, and even his backloggery page, feels really polished and thought out, with a coherent style that has become part of my own aesthetic sense, I think. Revisiting his website recently, I found out that I actually made the theme of this blog quite similar to his, without ever making that decision consciously (sorry ^^; ). Inspiration comes in many forms, and I am grateful for that.

 

The Dark Acre captain is a man of many trades, being also a writer with several novels under his belt. He is also a man of challenge, participating to the National Novel Writing Month and many game jams like Ludum Dare. Even with all of that going on, he still stays quite easy to reach on social network, making him one of the most approachable game devs I know of.

Between all that and the iron resolve you exhibit in all your undertakings, I wanted to tank you, master Jack. Thanks for strengthening my own dedication to the craft of game dev, and for doing it with tons of style and panache.

The Condemned

The Condemned

You can find the Dark Acre on Twitter, in games or books flavours, or follow the man directly. Then there is the Dark Acre website and Google+ page.