Meet the Cape

The Man almost had a panic attack when he saw her across the hall.


The day had previously been surprisingly rewarding. He woke up in the morning, blinded by the sunshine coming through the vast window of his dutch loft. He spread his legs in the bed and realized he was alone. "Honey?", he said, and his voice broke from an unquenched thirst. He called again, this time in a louder voice, but soon realized that he didn't really care: she was probably long gone, at work, or somewhere.

He sat on the bed and reached for the remote, carefully placed on the table by the pillow. As he pressed a button, it was like if the whole flat was coming to life. Orchestral music raised above his head, red lights turned on in the corridor, and a bath was being set up for him in the bathroom. He stood up and went straight to the kitchen, where a colorful fruit juice had just finished being made. A nearby TV decided to turn itself on and broadcast the latest news. Something about whales, and environmentalists taking over a fishing boat. The Man barely listened: he already knew all about that, and he would anyway learn a lot more during his daily morning brief. A brief he was really looking forward to.

The bath was a delight. It was hot enough, but not too hot, and a skincare substance had been added to the water. He was now perfectly relaxed. "This day is getting better and better", he grinned.
In front of the corridor's mirror, he dressed up, carefully putting every single inch of his suit in place. His suit was everything. It was his status, his power, the ideals for which he stood. It was the suit that made him - and his colleagues - different from the rest of the world. He looked at his image in the mirror, and found it was as close to perfection as it could be. He smiled at himself, but not with a childish, happy smile. It was a scary, proud grin that deformed his face in a frightening way. "I deserve my happiness", he thought, and he let the grin disappear.

Adress:The day was indeed getting better. Walking through Rembrandtpark, he heard birds singing under the warming spring sun. He saw them flying back and forth, building nests and shelters. Finally arrived at the facilities at Slotevaart, he looked up to the sky, almost like begging for a blessing. There were no clouds. He was seizing the day.

Then, he got inside the building.

The Man almost had a panic attack when he saw her across the hall. At first glance, her beauty was amazing, but something with her was wrong. His brain processed the information received from his eyes, and perfectly matched her image with her identity. He knew her, oh dear god, he knew her, and he wished he didn't. As the woman was screaming, he panicked. Everybody in the lobby was looking at her. Guards shared a glance, wondering if they needed to intervene. The Man's throat suddenly became as dry as the new Amazonian desert. He was paralyzed by fear.

The woman screamed something about "revenge", and decided to head to the main exit. The guards - and the Man - sighed with relief: problem solved, by itself. The Man quickly detoured to the front desk.

"What the fuck was she doing here?", he asked to the receptionist.
The latter looked concerned.
"I... I don't know", he started. "But Jenkins does."
"Jenkins?", he asked, having no idea of who he was talking about.
"Er, over there."

The Man looked where the receptionist was pointing, only to discover a sleepy guard. Alcohol was a common problem among the guards, and he knew it. Apparently, that one had trouble hiding the issue. The Man didn't care. He didn't want to think about it. Seize the day. He turned back to the man at the front desk and negligently threw "Whatever".

As the elevator reached the penthouse, his happiness flew back. His personal secretary, sitting at her desk, welcomed him with a warm smile. He walked straight into his office and sat on his very expansive sustainable chair. The secretary came, waiting for him to tell something. He waited for a while, pretending to be reading paperwork on the desk, and eventually decided to say: "So... What about you brief me now?"

She started to relate how the team had boarded from the Zodiac. He smiled when she announced that the whole crew of the fishing boat had immediately surrendered. Then, a big sign was set up on the deck, so that every journalist could have a chance at filming it from the helicopters.

"The operation is a success. We are featured in almost every media outlet in western Europe. Asian and American newspapers are starting to get on the story too", she proudly claimed. 
He was satisfied. "Well, it turns out my wife lost her bet, after all!" He stopped, and stared at her in the eyes. He grinned.
She blinked and smiled in return. "Yes. And you owe me one", she whispered.

She stepped towards the door and closed it. Turning back, she came close to him, very close. They shared a stare. As he started to undress, a piece of his suit fell onto his feet. It was his status, his power, the ideals for which he stood. It was what made him - and his colleagues - different from the rest of the world. 
A sharp, thick, pure red cape.


PS: in other words, we resume working on Impulse!

Mercurial is Good for You

Foreword: this story talks about our use of a Version Control System (VCS), and does not aim at presenting them. Therefore, if it's a new concept for you, you should read some documentation (and you should really do it, because one can't live without knowing it!).

Well, everyone in the team already knows SVN, but it seems that Distributed VCSs (Mercurial, Git...) are here to stay, baby. In other words, DVCSs seem to solve regular VCS problems, in a very effective and clean way. And as a proof, the amount of projects using DVCSs is always increasing.

So we'd decided to give Mercurial a try during the Impulse project. Since the project should test methods and workflows, we would see whether it is an appropriate tool, and whether we would keep it for further projects.

Spoiler alert: we are definitely going to keep it. Let's see why.

Our Mercurial architecture

A big difference between Mercurial and SVN is the meaning of repository. In SVN, a firm could have a single repository, or at best, one for each of its projects. And if the guys are good enough, they could use several branches within the repository. In Mercurial, a firm could have hundreds of repositories, because they act like branches. Mercurial still has the concept of branch inside repositories, but it's not a good way to use it. Whenever someone wants to create a new branch out of a repository, he has to clone it on his local computer. Once the changes are OK, he pushes the new repository into its parent, otherwise he may delete the repository (it's a simple directory). This philosophy may sounds a bit disappointing, but it is learned very quickly and is really worth it.

We spent hours to choose the architecture we would use. The main requirements were that:

• It had to allow us to do code reviews and testing ;
• It had to be lightweight.

Here is the result:

Our Mercurial architecture. The yellow boxes are repositories.

The principles are:

• Each module has its own repository, namely dev-xxx. The Impulse project has three modules: engine, scene and game, so there are three repositories: dev-engine, dev-scene and dev-game.
• Each developer may clone a repository on its computer, to code the module. It is shown as user-xxx on the above image. Since it is local to the developer, he may also use several clones... it is up to the developers.
• Modules have their own unit tests. So code tests have to pass (i.e. yield only successes) before the user repositories to be pushed into the dev ones. A build server then tests again each push, because problems may appear (e.g. platform-compatibility, or missing files).
• When a module is ready, it is pushed into the testing repository. In this repository, the QA tests the modules. Developers may code in this repository (mainly to fix bugs), but they should not add new features to the code.
• When the game being tested is cool enough, we release it by pushing it into the stable repository.

You might see some similarity with Linux (at least Debian) distribution organizations. It's no accident: with this architecture, we can test the game, without releasing it, while development still continues.

Publishing code

Another main difference between Mercurial and SVN is the release of changes. In SVN, when someone commits some changes, it is instantaneously available to other developers. Therefore, we tend to commit only files in their final revisions, because we are afraid of committing them while still working on them. Sometimes with reason! - as the committing may break other people's work, thus making the telephone ring withing the minute! A better way is to develop in a branch, and then to merge it into the trunk. This is exactly the philosophy of Mercurial: committing changes and publishing them are two different actions. That way, we commit more often, thus making us able to keep track of more changes, even if they break compilation. This is indeed the real use of any versioning system.

Terminology in Mercurial.

Since everyone develops on its own computer, the changes may be committed into the local repositories, but they are only published whenever the developer wants, by pushing it into a dev-xxx repository. This is why the code in server repositories should always compile, and have quite stable features.

So far, our team isn't a firm. We are almost all students, either in France, Sweden or Germany. We develop on our computers, behind several proxies standing between us... But we believe that Mercurial's philosophy is particularly well suited for firms. Every computer should be accessible on a private LAN. Thus Alice could ask Bob about the changes she just made: Bob creates a clone of Alice's repository and can see the changes, while they are not published. He can even write some lines and push them back to Alice. This is an exciting workflow to test, as soon as we get into a firm :)

Bob clones Alice's repository and pushes into it back.
By chance, Alice and Bob work at the same firm.

Working with code reviews

I won't tell you again how fabulous the code reviews are. Just that I made a mistake recently. Well, nothing serious, thanks. But embarassing.

I requested a code review for some classes I had to write. But I also continued to develop them, locally. The bad thing came: developers made comments on my code. Well, the very bad thing came: I had to change some functions. So these changes were committed after that I committed new features. And a principle of the code review is that we may change some part of the code, but introduce no new feature. I failed.

Let's say that you have our architecture, i.e. a central repository, somewhere on a server, and a local clone of it. There are two ways - nearly the sames - to avoid this error:

1. Create a clone of the parent repository, since it doesn't have the new features you introduced in your local repository.
   When you have to modify focused code, make your change in this new repository, commit the changes, and push it back into the parent. Indeed, this is the way our testing repository works. Since you no longer need the new repository, simply delete it. You will also have to pull the changes into your old repository to avoid multiple heads.
2. Create a clone of your local repository when you request a code review, and continue development in this new repository while the code review focuses on the older ones.
   When you have to modify focused code, make your change in the old repository, commit the changes, push it into the parent, and here again, pull the changes into your new repository. When the code review is over, push the changes from your new repository into the older, and delete it.

Two ways to work with code reviews.

Of course, I didn't think about any of them. Awful.

Adopt Mercurial today

As pointed out by Joel Spolsky, changing from SVN to Mercurial is not so easy. They look the same, but they are not. It's a new philosophy to learn.

SVN works well, but it seems that Mercurial does better. So far, our project has shown it. As explained, Mercurial allow us to have a flexible repository architecture. The developers learned very quickly how to use it, since 10% of the commands are used 90% of the time. They are now used to coding with it, and everything works fine. Great idea to give Mercurial a try!

The Fifth Element

"Why the ruthlessness?", I had to ask. "Why the cruelty?"

"There won't be no consequences", he said. "Everything is going to be fine."

"But people will get it eventually. They will come after me.", I feared.

"They won't have time to understand. And if they do, I will take the blame."

I didn't trust him. After all, I witnessed the very first steps of this ridiculous creature. I saw him crawling out of his cradle, and I had beholden him growing up and feeding upon it like a rat thriving on the filthiest pile of uselessness: Me.

I couldn't help but shivering, as the void around me became colder than ever. I tried to make him understand how I felt, but he didn't look. Or didn't care. Again, he turned his back on me and started to hurt, through me, his fellow creatures.

I am not sure that he knew what he was doing. Perhaps was he convinced of the goodness of his deeds. Perhaps their influence on him was too powerful. Or perhaps he didn't care either. I couldn't tell. "Why the cruelty?", I wanted to ask. "They will come after me", I feared. I tried to make him understand as hard as I could. 

So I flooded the shelters, I lit up the sky. I melted the ice and shook the ground. But his grasp on me was too strong. He was out of control. And, for him, I wasn't. I tried to make him understand, and he grinned. After all, I was only a small pebble in the void around me. 

A floating, glowing, tiny blue pebble.

Let's face the facts. Our planet is changing. We've got news from all over the world about global warming, ice cap melting, toxic muds and giant tsunamis. In Impulse, the Earth is crying. She cannot take the pain anymore, and desperately screams her heart out. She wants somebody to help her.

Will this somebody be you?

Impulse is a 2D puzzle platform game in which you, the player, control the elements. Each element - Water, Earth, Air or Fire - is a character that you can control and move through the landscapes and nature sceneries of the game.

Each element character has a specific power for interacting with the environment. For instance, Water is able to extinguish forest fires, whereas Fire is able to light them up...
This example also highlights a fundamental principle of the game: everything that the player builds with an element should be destructible by another one.

Let's take another example. If Air happens to turn a water lake into ice, then Fire can make the ice melt down. Then again, Fire could make water evaporate. Fortunately, Water would be here to refill the lake!

But sometimes, elements alone are not powerful or versatile enough to progress through the world. At this point, you, player, will be able to combine the elements with each other, in order to unleash various powerful new characters.

Of course, not all the characters will behave the same way in their environment. As it can be expected, Fire cannot go inside lakes! On the contrary, Water is pretty at ease when it comes to swimming in her element ;).

In order to make the game interesting and progressive, not all characters will be available at the beginning. You will have to make your way through the first levels before finding some. Then, you will have to learn how to use them.

The only character that will always be there is one we call "the hero".
Your goal, as a player, will be to make the hero progress from one level to another. To accomplish this task, you will need to use the elements in order to "clear" some path for the hero.

You control the hero, just like you control the elements. His power is to handle the elements: he's able to unleash and call them back on demand. If you need Water somewhere, take control of the hero, and make it spawn the Water element.

The hero is a man, just like me and you. Mostly you, actually, because you, player, are the hero in this game.

"Why the ruthlessness?", I had to ask. "Why the cruelty?"

"There won't be no consequences", he said. "Everything is going to be fine."

"But people will get it eventually. They will come after me.", I feared.

"They won't have time to understand. And if they do, I will take the blame."

End of the project... in theory!

So the project should end today... well, the truth is a bit disappointing: we didn't manage to complete the game. We didn't even manage to release a simple prototype. The game concept that the creative team has come up with is so amazing that a single month was not enough to make it true...

Therefore, the team is so motivated to finish the game that we can't stop the project now! We believe that this game has potential, really. The upcoming story about the game concept should show it.

On the development side, we set up methods and tools, and they work great as yet. The (private) forum is an effective place to discuss. The Google Code project offers good services: Mercurial and the code review (we haven't tested out issue reporting so far), so the developers code very quickly. Level designers already planned the first levels, and we should be able to integrate them fast, as soon as possible. Finally, artists are creating the graphics, sounds and user interface. The game engine can already load and play animated characters.

If all works fine, we should release our first game prototype in less than one month, so stay tuned!

Errors are among us

A year ago, I didn't know anything at all about quality assurance, because I'd always written code for my own use. But since we studied project management, software quality, and all those things which make that I don't code alone anymore, I realized that errors are far more important than I though.

In fact, the way you deal with errors is the most important. You may know this sentence: the later an error is discovered, the more money it costs. At the early stage of a project, an error costs nearly nothing, because you only designed your project on paper; when a defect is found during development stage, you have to spend - or loose - time to fix it, maybe forcing you to change your design; etc. And the worst case is when your customers find a defect.

Thus, any software project should really consider handling errors, because there will have some, whatever you do. Even if you have the best developers of the world, even if you over-pay them... mistakes will happen, and the way you deal with them can make a huge difference.

The Impulse project, as I eluded earlier, aims at finding a reliable workflow. And you might have already guessed it: we need to handle errors well. So I asked Rémi to set up funny things to handle them easily. As matter of fact, it should not be hard to follow the workflow, because when it's hard, developers do not want to bother with it.

Here are the steps of our process, aiming at finding defects as early as possible.

Unit testing

Each unit of code (in C++ it is often a single class) should have associated tests, and of course, should pass them. Ideally, tests have to focus on a specific point of the specs, all tests should cover all the specs, and they shall be written at the same time than as units themselves...

Well, it is important, but forcing the developers to follow this process is the best way for them to hate unit tests. Developers have to become aware of their benefits, and to know what is really important to test. For instance, the global behavior is worth checking it, but the setter and getter may be simple enough not to test them.

The tests are also the first real application of the unit, before it becomes integrated into the whole project. Therefore developers should enjoy doing them!

For instance, here is the (only) test I wrote to check my BezierFunction class. Self-explicit and funny. I admit that I had no time pressure.

Each developer have to test their modules before continuing in the workflow. At least, they must verify that it compiles, i.e. it will be usable without breaking the development.

To make test development easier, a small library contains functions and macros to test or compare values. There is also automated tests, to launch a set of tests with a single command line.

Team review

This is the big new step: I decided to impose team review for the code. I won't talk for pages about reviews, their benefit and so on, you may found hundreds links on your favorite search engine. I also give two links at the end of this section.

However, why I have imposed team reviews in brief:

• We can fix errors early in the process.
• We know modules, which others wrote: everyone has a better global vision of the project.
  
• The best developers help the not as good ones to improve.

And it turns out well: we use Google Code to manage the development part of the code, and the tool includes a code review tool! So why bother to set up our own? As Rémi stated in his article about the development workflow, provided tools are enough for our needs. This one allows us to put comments on every line of code, thus making discussions on the spotted defects. A rule of thumb is that these discussions may not exceed a few messages: the code review does not aim at finding alternative solutions.

Here is how the whole process should be:

1. Each module has its own repository (an upcoming story about our Mercurial architecture may be coming). During development, developers may push into that repository.
   
2. When a module is ready to be reviewed (and it passes all the unit tests), its code is frozen and a code review is created. The developer in charge of the module assigns another developer as the review moderator (who may or may not work on the module as well).
3. The developer in charge introduces the module and the changes made since last review, if any.
   
4. Every developer who does not contribute to this module read slowly and carefully the code :) They post comments through the review tool, and the moderator avoids that they turn into trolls!
   
5. Once every spotted problem is fixed, the moderator validates the review. The module's development continues in its repository. (No regular development is allowed in the testing repository, except for bugfixes.)

Code must have passed a review before it is allowed to integrate the testing repository. Any review may not move on to a repository push: a code may have several reviews before being integrated. The review is part of the development workflow, therefore all these steps happen in the module repository. Its purpose is to improve code, not to act like a filter for the QA.

So we are going to use this workflow on the project. I didn't say this was the best: the project will show what is good and what must be improved. Since we never did code review before, the results are a total mystery.

If you want to know more about team reviews, I liked in particular this white-paper: http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf (guess what: this company also sells a tool for code reviews! I don't advertise their tool, I am just saying that this document is easy to read and has cool graphs). If you want deeper information, it may be worth reading these articles: http://www.processimpact.com/pubs.shtml#pr.

Quality Assurance

The QA has its headquarters on the testing repository. Since all the code in that repository passed unit tests and code review, the QA should not deal with deep code problems. Its two main focuses are:

1. Integration issues. Indeed, modules were developed inside their own space, and problems may appear when they are grouped. (This should be seldom since the code architecture is well defined and the module repositories must regularly pull the testing repository.)
2. Game testing: rendering, control behaviors, typos...

When a defect is found, it is either directly fixed when it is small, or an issue report is created. Here again, Google Code provides a tool for issue report management. An issue may be assigned to one (or more) developer(s), its status may change, etc.

When both the QA and the project managers agree to release a version, the testing repository is pushed into the stable repository, and a tag is added. Exceptionally, critical bugfixes are allowed in the stable repository.

We hope that this workflow will allow us to handle defects effectively. It is both easy to understand and apply. The Impulse project should show us what are the good points, and what must be improved. And of course, we will keep you posted about.

Why developers should not have to think

Because the minigame is such a small project, but because we still want to gain experience from it, designing the development processes and workflow of this project has been quite an interesting challenge.

When we started thinking about it, Jonathan threw these contraints at me:

• The code must be peer- or manager-reviewed
  
• We need a separate QA departement, with testers playing with an already reviewed version (no playtests of the development branches)
• Application components must be isolated enough so that we can develop them at different paces and submit versions to be tested at different times, without ending with a half-coded module in QA's hands
• Stable versions must be released on a regular basis, once per week for this project
• Automated unit tests would be really nice
• A build server reporting code breaks and running tests could be really cool too

And because at this time I started to feel a bit uncomfortable about running such a heavy workflow for a one-month project, we discussed it and ended up with the following conclusion: "Ok, we're gonna do all this, but we definitely have to keep it lightweight".

And keeping it lightweight is not only about style... If we fail that part, then we put the project in danger for two main reasons:

1. Obviously, if the processes are too heavy, people will lose too much time applying them and the project will quickly get very late.
2. If the workflow is too complex, everybody will eventually get lost in it, work around it, thus making it completely inefficient.

Moreover, both of these problems would probably impact moral and discourage the team, which is one of the worse things that could happen to us :p

Don't-think-about-it philosophy

In order to find an appropriate solution to our problem, we can start by defining a general working philosophy. Because we need the team to realize a huge set of things in a short amount of time by following relatively hard constraints, the more burden we can remove, the better. Part of removing the burden is obtained by applying what I call the "dont-think-about-it" philosophy.

That's why you can buy a golden fish without bringing water with you to the store.

Really.

Because it's annoying (and risky for the car) to carry a water bag, because you wouldn't know what kind of water (salted?) to bring, because maybe you didn't even plan to buy a fish at this moment, etc.

But while marketing professionals seems to have figured that out for a very long time, computer science looks a bit outdated on this.

The point is that when you have to think about a lot of things at the same time, the chances that you get something wrong increases very, very quickly. In a similar spirit, when you have to check many things before doing something, it is likely that you will forget one or two and then realize that this was wrong.

Thus, when designing a workflow, we should strive towards two main goals. First, always reduce the likeliness of something wrong done, by reducing choices and checks a developer has to do in everyday operations. And second, we should always design the system by taking into account that mistakes and errors will happen.

If this sounds familiar, it is normal. That can almost entirely be found in any good UI design course. The fact is that things doesn't have to become overly complicated when we get to developer side.

In our project, this state of mind translates to as much sentences as possible looking that way:

• Developers should not be scared of pushing/committing something on the central server. Never.
• Finding which version of the game a bug is related to should not require any research in the repositori(es). When a bug pops out, everybody should know on which version it has been found.
• Nothing in the compilation process should have to be handled manually.
• No special action (to be remembered) should be taken at each commit/push, including triggering the build server for a new build.
• There should not be any repetitive and error-prone work (e.g copy/paste/replace). Obviously this kind of thing can be hidden in scripts or small IDE tools, but it's generally much better not to have it altogether where possible.
• etc.

The tool side: trying bottom-up

Because whatever solution we choose we will have to implement it on existing tools, here is a small review of what tools we need, and what alternatives we considered.

The code must live on one or more centralized repositories. It might seem obvious at first sight, but DVCS like git or mercurial allow developers to push/pull directly from someone else's repository, which would allow server-less source control. But in our case, the team is exploded between numerous European countries, and we cannot expect a developer machine to have the same disponibility level as in a company local network.

Thus we must make a choice between the hosting possibilities:

• Managing our own server. This is the most flexible option, but it will inevitably take a lot of time to set up and administer everything.
• Using a free online service, such as Google Code, GitHub or BitBucket, and add missing features (such as a build server) on our side.

For many reasons, we chose the latter solution. These reasons include administration burden, server reliability and backups, and more generally the fact that the free online offers are enough for what we need. We chose google code because most of the team is familiar with it and with other google tools (e.g docs), and because we wanted to give Mercurial a try on this project, to set up a real DVCS workflow (see below).

To store the different game versions (such as development, testing, releases...), we need a powerful version control system, supporting a lot of branching and merging. This led naturally to Mercurial on Google Code, which allows multiple repositories for free. The repository architecture is made with the following goals in mind:

• Stable releases should be separated on their own repository
• QA testing and bug fixes are done on their own repository
• Feature development is done in several repositories, one per architecture component
• Features can be integrated separately into the testing repository
• Repositories have to communicate. For instance, bug fixes done in the QA repositories must be integrated in the development branches. Symmetrically, reviewed components must be pushed to the QA for testing.

While this could have been achieved with SVN branches, Mercurial seems to have a much more lightweight and clean way of doing it. And most importantly, we wanted to try it :p

Choosing Google Code as a back-end service also helps a lot with the integration of other services we need. Code review can be done directly in the code, on a line-by-line basis, and issue tracking is tightly integrated in the web UI and with commit messages. This is a great advantage because it means developers don't have to go elsewhere (i.e another service, another URL) to do these things. The wiki is equally integrated, and will allow easy project documentation.

As the game is cross-platform and we don't want to lock the developers in only one-tool (i.e a specific IDE), the build system is based on the powerful SCons, which is easily callable from any IDE project, and allows for great build flexibility and cross-platformness. As the build is a complicated topic, another article will be written to explain how our build system was thought and implemented over SCons. The main design points are the following ones:

• Cross-platform and cross-compiler. Users may chooses to reduce compiler choices, but the toolchain must support all of them, theoretically.
• Component concept. Components are something between an IDE project and a package-config file, generalized.
• Explicit component dependencies. This will allow for component dependency graph generation, avoid duplicated configurations and kill dependency cycles.
• Powerful configuration. Everything is Python.

We also make use of a build server which is automatically triggered by Google Code, through Post Commit WebHooks. This allows us to be almost instantly notified if we break the build or some unit tests.

Finally, unit testing is kept simple and flexible. That means we allow both automated and non-automated tests to be written, and that we developed a very simple library to help with test development. Actually, that library is just a header with three macros in it, such as CHECK(expression) which will print either a positive or negative result to the output, along with information about file and line where errors happened.

Allowing non-automated tests is also an important point: we don't want developers to waste time trying to fit a simple module test within a complicated yes/no framework, especially when this test is easy to verify but hard to automate (is that texture yellow?).

Everyday life made simple

As stated before, the ultimate goal of this tool combination is to make developer life simpler. Maybe it is not ideal, but I believe we have reached a fair degree of simplification. The build system handles weird compilation details, the build server handles running the tests as often as possible, writing tests is easy, pushing is not scary because the repositories are separated, bugfixes can be instantly imported in development branches...

But obviously, as this workflow is new, we cannot (yet) know what will really work and what will not. More about that after the project has finished and remarks have been collected...

Challenge: create a mini-game in one month!

Vacation is over! And to get back to work, we are setting ourselves a major challenge: creating a mini-game in a single month.

Well, we don't want to make a blockbuster in only one month. We are aware that it will be small: a few levels, with simple gameplay, limited artwork. Sure, we hope that it will be fun to play, but this project have several other interests.

The first is of course making a game in itself :) Indeed, almost all of us never made a professional looking game, in a well-organized team. This project aims to follow the complete steps of creating a game, from concept to release. It will be instructive for everyone: it gives us the opportunity to understand the game creation process, and to complete our (always starved) knowledge.

Another main interest is to allow us to experiment new methods and workflows. The project lasts only one month: perfect to see whether they are good and have to be applied to our other projects. Among other things, when developers finish a module, it is first team-reviewed and then integrated into the main development branch, only if validated. We also test new tools: code will be versioned under Mercurial (Hg), a private forum will allow more effective communication... this blog is also part of the renewal: we will keep you informed of our last advancements and technology choices!

And to complicate even more, we only have a single month to do it!

The project runs from September 16th to October 14th. Every few days, we will post news, along with technical articles, so subscribe to the RSS to stay informed!