Category: #GAM


7 Days and then some…

May 10th, 2013 — 11:35am

As was hinted in the previous post, here is some more details on the challenge I took part in march. The aim was to create a roguelike in 7 days or less. If you want to read more about what a roguelike is or how they are made, the excellent Roguebasin wiki comes highly recommanded. But in a nutshell, a roguelike is somewhat like a role playing game in which depth of gameplay is put at the center of the experience. Traditionnally, they have featured ASCII graphics and extensive command lists, are turn-based games, and feature some kind of permanent death (as in, if your character dies, you cannot resume from a checkpoint and need to start from the very beginning of the game).

From a personnal standpoint, I have always liked roguelikes, and decided that this year would be a good time to try my hand at one. Having set time limits tends to make me more productive, so it was only natural that I entered the 7DRL challenge.

The idea

For the longest time,  I have been an avid fan of the Battle Royale book and movie. Logically, I have from time to time about how I could turn the “Battle Royale experience” into a game that I would like playing. A first-person game used to be the main idea, but without even considering the amount of assets that would be needed, and the complexity of programming everything, the sheer amount of parameters needed to truly recreate a faithful and interesting Battle Royale setting would be much too important.

Enter roguelikes, and their propension to accomodate detailled simulation and complex interactions even without any kind of art needed. The more I thought about it, the more it seemed like a roguelike would be, in fact, the perfect kind of game for what I had in mind. If I did not want to make a glorified deathmatch game, I would need several things :

  • Many viable styles of gameplay : Some characters in Battle Royale embrace the game and kill everyone on sight, others try to approach their prey cunningly, some try to find safety in numbers, others try to hole up somewhere and place traps or guards to defend themselves, and some even try to escape the game itself. All these and more should ideally be options for the player. As they should be pursuable by the AI. If it was simply a matter of fighting, the initial random weapon would pretty much settle the end result.
  • An unknown island : For best effect, you should arrive on an island which you know nothing about, except maybe the rough shape and a couple of landmarks. This would lead for an always-fresh and stressful game. Without that, you would simply be trying to optimise your initial moves.
  • The social interactions : Perhaps the most important item in this short list. One of the facts that make Battle Royale a high-impact story is that the contestants in the ‘game’ are no strangers. Being all from the same class, rivalries, friendships and cliques are already present in the group before the story begins. Including that element is central to recreate the Battle Royale atmosphere.

This list seemed to fit the idea of a roguelike, with the emphasis on simulation and procedural content that these kind of games tend to exhibit. The next step was to fit this idea into a game I could make in 7 days…

The game in its first moments.

The game in its first moments.

The plan

Obviously, making everything I wanted in a short span of time was impossible. I decided to trim the concept to a minimum form.

What that meant was to cut much of the open-endedness from the game. No possibility to escape by disabling the explosive collars, no killing the soldiers in the school and taking over the island, no hacking, just basic killing of other players. The only feature I was not ready to drop was the social aspect. I decided to include some form of alliances/friendships into the game, with gameplay implications. For instance, if you had a best friend, killing him or her would have resulted in severe (if temporary) penalties while your character was overcome with grief.

I also dialed way back my ideas on the island generation. Instead of doing many types of structures and terrain, I decided to make only ponds of water, trees, and rectangular buildings. This was an area where more could always be added at a later stage, but having done my fair share of game jams, I know you never have as much time as you think you have.

My plan would then be as follow :

  • Day 1 : Island generation
  • Day 2 : Player movement, field of view…
  • Day 3 : Other students and combat
  • Day 4 : Time and forbidden zones
  • Day 5 : Weapons and other items
  • Day 6 & 7 : Polish

Seemed doable enough at the time…

The execution

As they said, the best laid plans never survive engagement with the enemy. While things started pretty smoothly thanks to my tools of choice (Python and libtcod), around the middle of the week I fell ill, and had a mountain of work pile up on top of me, two things that combined to make me fall way short of the goal I had set to achieve.

I started documenting the process of creating the game on my personal blog (read the articles there) and several systems were completed on schedule (combat for the most part, pathfinding, line of sight, random generation…). I tried to push forward during the last 36 hours of the challenge, but was dealt a fatal blow when I realized that the game slowed to a crawl when 20 or so characters where trying to figure out where to go. I had several possible solutions in mind, but by that point I was tired, and too disappointed to make it.

In the end, quite a few features were included.

In the end, quite a few features were included.

The conclusion

Seeing how a well thought-out plan fell flat, you would be forgiven to think that the whole challenge was a bitter disappointment, right? Well, in a way, yes, surely I would have loved to end the week with a new game to show for it.

But, in the grand scheme of things, I finally started on one of my ‘dream projects’. And that is something. I have a nice code base off of which I will continue to work until I get a more fully realised project.

And I am planning on entering the challenge again next year, that is for sure!

Comment » | #GAM, 7DRL

March

April 2nd, 2013 — 5:15pm

#GAM February and March : OneFailAMonth (but working on it)

They started the challenge with lots of determination. But unfortunately, it requires a bit too much time from our developers for them to be able to fully focus on it.
However, projects have been making progresses!

Continue reading »

Comment » | #GAM, 3D, Alun Hevel, Bloboy's journey, Ludum Dare

February

February 25th, 2013 — 9:08pm

February, and we are back !
So, a quick review of January…

#GAM January

Because of several issues, Thomas directly focused on his February project. It consists of a dungeon crawler for which level design data will be saved on a database server.

Bastien isn’t entirely satisfied with his own project that isn’t totally polished (LINK : read what he says about it on his blog). It however allowed him to have his first experience with Unity and to wholeheartedly adopt it. He perfected the game during February.

FOSDEM

We told you we would go, and indeed we did!

First, a quick presentation in its organizers’ words : “The Free and Open source Software Developers’ European Meeting (FOSDEM) is a two-day event organized by volunteers to promote the widespread use of Free and Open Source software.“

Talks were held on plenty of topics and booths presented a variety of products, softwares or project teams. Some were well known – like Gnome, Firefox, Ubuntu, LibreOffice… – but there were also others far less renowned (or finished).

Bastien and Pascale, the true warriors they are, already attended FOSDEM on Saturday. The rest of the team joined on Sunday to follow a few talks about Open Source games, of course, but also lots of other topics.

ephy Personally, I felt both very intelligent (I understood the title of the books, I who didn’t code at all only eighteen months ago!) and very inexperienced. Since I don’t have much technical knowledge, I couldn’t follow everything.
But next year, hopefully, I’ll have improved!

Alun Hevel

Even though this project became secondary, we are still working on it, especially on visuals.
Last one? Angelic forges… which gave our imagination a hard time.

forge

Bloboy

The long and hard coding work is ongoing, thanks to our devs !

This month, they worked on jumps, in a very particular form : the main character is launched using the mouse movement – a catapult-like system – and gets thrown upon release of the mouse button.

bsj_jump1

bsj_jump2

Moreover, they made a great effort to give an elastic effect to our character’s movements since he is, after all, a blob.

bastien To manage this, I cut the sprite’s rectangle following a grid, and I move the different points to distort the rectangle. The texture (Bloboy’s image) is thus distorted in the same way. This gives the impression that the sprite is crushed in the direction of the mouse pointer.

And tests are conclusives!

 

Now, the effect still has to be polished…

Comment » | #GAM, Alun Hevel, Bloboy's journey, Navigation

Back to top