Game development using agile methodologies

Yeah, yeah, I know I told I would be away for some time, but yesterday found this while I was searching for additional reading for one of my exams.

The page in question is agilegamedevelopment.com, a site maintained by Clinton Keith, chief technology officer and lead engine/tools programmer at High Moon studios. A very interesting read (don't miss his blog!)

As an extra, found a link in his blog to a conference by Mary Poppendieck entitled "Competing On The Basis Of Speed". As Keith says, "one hour of solid gold".
Before I forget, here's the Link to the conference.

Enjoy!

About software static design

People often ask me about suggestions for good class design, so I'll write this with the hope more people will find this more easily.

The concept of class comes from the social classes. Every society has always been stratified, so people is classified into one of those stratus. As such, every class has their responsibilities already defined: A hunter must hunt, a guardian must guard, a paparazzi... Well, so we now have classes with responsibilities. Cool! We have a starting point.

When designing the static part of a model (this is classes, packages...), the first thing we must identify are responsibilities. Good, now we have a set of responsibilities identified but, what do we do with them?
The answer is easy: Define classes.

Societies have needs, and must have responsibles to be in charge of them. So people is classified according to their capabilities and skills to be responsible of those needs. A class is defined by both their abilities and responsibilities. We have the latter, and we're to find the best abilities to take charge of them.

Now our point has become just to find the best design for those abilities, but that falls outside of the scope of this rambling.

One more thing to remember. People usually burns (nope, no spontaneous combustion here; just metaphorically speaking) when they're assigned too much responsibilities. They will become unstable, hard to maintain and keep under control, and most probably, attack you. And so classes do. Try to keep their amount of responsibilities low (I've found the "two responsibilities per class at most" rule quite useful). If you can't, delegate some responsibilities on a different class, just like people do. I'm 99.999% sure you can do it!

Those are just my thoughts about defining classes. You might disagree, of course, but this reasoning has worked great for me in these last years, so I suggest you to give it a try :)

Caelum @ youtube... again!

This is a video from Rigs of Rods, a game being developed using Ogre that recently adopted Caelum for the sky management.
This fan video shows how the game looks with the new sky :)

Our visit to Códice Software

Today we visited Códice Software, the team behind PlasticSCM, and had the chance to take a look to how they work. They are currently being evaluated fot the L2 CMMI certification.

We went to Valladolid (Spain), to the Technologic Park of Boecillo. I must say that first of all, it's a dreamlike place to work in a software development company. Calm, quiet and surrounded by a beautiful nature environment.

So we came into the building where they're located, along with other software development companies. There Pablo welcomed us to their company and invited us to come in. The first impression I got is that it's a clean and nicely decorated place. Every single piece is cleverly placed and serving a purpose. Large room to share with the teammates and enhance communication and workflow.

Then Borja told us about their testing process. The testing process is very cleverly done, and there's not a piece of code that isn't tested several times and in different situations. That's something you're being told everytime but you're never asked to do. And they demonstrated us that testing is necessary. This is a reason of why the branch-per-task development pattern is so important in the development management, allowing to verify every single step of the development, and then the whole software. So you increasingly create fail-safe and stable software releases.

Later, we saw how they successfully are using their own product, Plastic, as the SCM tool. They store a well-designed repository, boosting the development process to levels not reachable in other ways. Of course, source repositories have loads of advantages such as version-based operations (such as retrieving previous versions or rollback conflictive changes) or codebase safety.

Then, we were present at their today's Scrum meeting. Scrum is an agile methodology for development management, based on sprints and tasks that go into those sprints, releasing functional and stable versions of the software being developed in an increasing way. So after each sprint, you have a program that works, and you can play with without warning of crashing it all. Scrum tells to do short daily meetings of about 15 minutes where the team exposes what they did the previous day and what will be next in the current working day (sort of a development postmortem). So they met at the meetings room and talked briefly about the steps given and the next ones. I must say the way they manage the meetings is smart and efficient, by the way.

We then finished our visit and let them continue working on their new tasks.

So, these are my conclusions:

1. It's important to work in a good development environment. One must feel comfortable at work, as I felt being there. Also, the working place must have all the equipment needed to help the development process, as well as enhancing teamwork.
2. Test your software. Planify your tests according to your tasks and overall development methodology. Don't be lazy and do test your software. Skipping tests can be harmful too often.
3. Keep repositories of your codebase. We all have done harmful changes we couldn't rollback, or messed with hordes of zip files storing the "codebase". Honestly, I've tried it, and must say that I simply can't go back to the dark world of .zip versioning systems ;)
4. Scrum works, and agile development works. Maybe their detractors have good reasons against them, but I've witnessed why Scrum is defiitely good. Códice uses it, and it's a success story. Why should I need theorethical reasons of why this doesn't work, when I have real-world reasons of why this works?

My final conclusion is, that as a CS student, there are a lot of good-practices and bad-practices that maybe are taught to us, but we never take into account (specially when developing our graduation project). Now my mind has definitely changed. Most times the difference between a success and a failure (specifically talking about the graduation project development) can be simply following the good practices or following the no-noes.

A fruitful visit I will take as a reference for my future works. Can't wait to start using these practices for everything (of course, starting with Caelum ;))

More Caelum news!

Yeah!

I'm working hard on this, but unfortunately most of it has been in the inside, so few of it can be shown.

The good news are that the tasks I first defined are advancing pretty well, and I'm moving faster than I estimated, which is good. At this pace, a new release should be out by end of this year!

Meanwhile, some more Ember shots with Caelum; this time, layered clouds added :)Now I must go for another "damn fine cup of coffee" :p
Have a good time!

Clouds!

Today is a cloudy day... in the world of Caelum!

Its development is kinda boosted recently. I've been working on it almost all day long, and this is the result:Some nice detailed "dynamic" altocumulus clouds during a sunset! The blur is because of the bloom filter. Anyways, the bad part is that it's not fully integrated yet, and the performance keeps quite low... :-/ I need to take a look into it as soon as possible...

Caelum meets Tux!

This seems to be a good week for Caelum. It's development is much better by using some tools like task management and the patch tracker. The "stabilisation" task has gone into beta phase, and I've got it to finally run under my Ubuntu distro.

I've had a lot of issues with the nVidia drivers and the kernel headers, but it's finally working. Here is a screenshot I took some minutes ago of the Caelum demo under Linux :)
Next: Getting Java and JavaCC to run :/