Caelum news (at last!)

So, many of you are guessing what I'm spending my time after the exams period (which, by the way, went pretty fine, with the exception of a subject...).

Besides unleashing a lot of ideas I had in mind for pictures, I've got back to the Caelum development. The shaders are under a complete overhaul, and so far they look pretty well. Still want to refactor many things, to make it more physically real, but better to go slow but fine, don't you think? ;-)

Here's a shot I took a couple days ago of its current state. Hope you like it!

Indievelopment

I don't know if I've already told some of you about Indievelopment.

The idea is that the Gamespot crew is releasing a series of videos (most of them home-made) with the tribulations of Echelon, an independent game development studio. This is something like a video-journal, where you can see and hear what indie development is about.

Pure coolness :) I'm loving these series!!

PS: Requires free registration to download the chapters, but it's worth it ;)

DOF, parallax mapping, scripting and other proof-of-concepts

Probably many of you have been guessing what's sucking all my spare time lately. I can't tell you any details on the project I'm working on, though you'll eventually get all the info available.

However, to keep the masses calmed (well, the small group that actually spends some time reading this :-/), I'll tell you a bit of what you can see in these screens:
Well, first of all, sorry for the crappy images. I promise next time will look better ^__^'

Okay, onto the explanation. These last two weeks I've been working on the basic scene parsing. Right now, you can load scenarios from a script, containing static geometries and almost all the camera features. I'll release a video with the camera system working next time. Right now, it smartly switches cameras and adds some interesting effects such as rolling the camera, vertigo effect, and shaking :)
You probably have noticed the scene is blurry. That's Depth of field. Another effect I feel quite happy with. It kills quite framerate, but on high-end cards it does probably look impressive in many circumstances.
The last feature I want to talk today is that crappy material that makes you want to rip your eyes off. I've beaten my personal record spending 7 whole times getting it to work (yes, that means I was up and programming until 6am yesterday... today... whatever!!). That proof-of-concept applies an asphalt material to an object. The material self-applies the UV coordinates depending on the vertex world coordinates, and even shows cracks as required by an "age mask". Quite impressive to see, and even more if using parallax mapping with it as well! If you pay attention, you'll see the cracks looking like 3D even if it's just a simple polygon! This is likely to be redone, but I got it working (quite an achievement as I'm almost a novice when dealing with shaders!)

Well, that's how "my girlfriend" looks like...

Busy-ness

Just wanted you to know I'm pretty busy at this moment (that's why I'm not posting often here).

I finished my exams, and have some good expectations about them, but I'll wait until I've got the final qualifications to let you know.

However, I'm busier than before, because I've took back an old project I really want to see finished. Started it from zero this time, just to start developing it as a serious project deserves. As soon as I have some things working I'll post images/videos here so you understand why I'm this busy :P

As a sneak-peek, this is the result of a proof-of-concept shot after some research regarding fog:

Understand this project means a lot, and I want to tell such a lot of things through it... I simply want this to be done; it's one of my life goals!

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

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 ;))

Coffee

Diane, it's 1:28 pm. It's a rainy, cold, autumn day here.


I spent about four hours yesterday night trying to get Java to work on my Ubuntu x64 distro. A waste of time. Be it because of unsupported platforms, installation problems, or compatibility issues, I couldn't get JavaCC to work. I think I'll have to find a WinXP machine as soon as possible.

And regarding java, last Sunday I found a place with the best coffee I've ever tried. A damn fine cup of coffee (or cup of joe, like Aimee says). My addiction to caffeine is getting worse.


That's all for now, Diane. See you later.