I have been tinkering around with the software I use for image feature extraction in my large collection of SenseCam images.

Using OpenCV, a SURF algorithm and Python I have been able to create a small command-line application that can accurately determine places I have visited before based on the captured images.

The Python script is also capable of tagging images such as “Venice Office" or “Home/Bedroom” or “Local Coffee Shop” very accurately. I am quite pleased with the results.

By automatically tagging images I can group them in to similar sets of images, and quickly locate pictures of an event or location. Next I want to start working on automatically recognising and tagging people.

Share this post with others

Posted in SenseCam, Software Development, Toy Box | No Comments »

Are games engines worth it for casual games?

Should you purchase a game engine to create your latest casual game? Or will you just need to throw it all away once you realise the game engine doesn’t live up to expectations? Will you have to start all over from scratch in 6 months time?

Most game engines are not game engines at all but just a rendering engine with a lot of middleware haphazardly bolted on to the graphics system.

Unfortunately "game engine" is a poor term to use to describe something so specialized.

Imagine if you will someone stating that they have "a car."

We shall call this "car" a "Honda Civic."

And so with this Honda Civic the owner is going to drive off-road across the desert in the Paris-Dakar Rally, they are going to pick up 2000lbs of lumber at Home Depot for a building project, they are going to take their family of five on a two week vacation, including all of the luggage, they are going to enter and attempt to win the IndyCar 500, tow a 30ft horsebox and to cap it all off they are going to shuttle off the entire high school football team at the prom, including their dates.

So any reasonable person will realise, you need specialised vehicles for specific tasks. A rally car, a heavy truck, a minivan, and so on and so forth.

So when people claim to have a "game engine" it is a bit like claiming "I have a car."

Sounds rather ridiculous when you think about it, right?

Nobody would think of attempting to use the Diablo 2 RPG game engine for a vehicle racing game — and if they do they should be shot — and you wouldn’t think of using the Star Wars Galaxies game engine to create a casual puzzle game — and if you do, well… good luck to you.

The generic parts of a game engine, the graphics engine, the audio engine, the A.I. engine, the asset management system, are all re-usable on any project just like parts of a car, e.g. the steering wheel, the seats and the actual engine. These parts are all re-usable in other vehicles, but you need to configure the generic parts in such a way to make them work harmoniously.

So other than the issue with Not Invented Here/Other People’s Code which pretty much every programmer, everywhere, suffers from, it comes down to picking the right tools, and the right "car" for the correct job.

Having said all of this, creating technology from scratch for a casual game is a bit ridiculous as you aren’t delivering value to the customer whilst you are doing that and frankly, the customer that buys casual games doesn’t bloody well care what engine you used. Pick a generic game engine, Ogre, Torque, Irrlicht, etc and create some custom classes specific to your casual game needs. For casual games my company Infinite Monkey Factory maintains a word search game engine, a pinball game engine, a lightweight RTS game engine, a gem drop game engine, a hidden object game engine, and a slew of other niche casual game engines for very specific genres of games. The beauty of having a dedicated game engine for a particular game type is that a prototype idea takes only a few hours to create.

So yeah, get a game engine, I highly recommend it, just realise it won’t do precisely what you need out of the box. A game engine is a foundation on which to build, and not all game engines are created for all game purposes. The "game engine “is the glue that holds all of the other parts together, and it is the glue that is often the weakest part of the whole, the glue is most neglected and can rarely be made generic enough to suit all purposes.

Share this post with others

Posted in Advice, Games Industry, Software Development | Comments Off

If you develop software either professionally or as a hobby using a modern version control package is a no brainer.

Even if you only work on hobby projects by yourself and nobody else ever gets to touch the source code or binary assets there is little excuse to not use version control for your projects. It doesn’t matter what version control package you happen to use, using the package effectively is universal issue.

Hopefully these guidelines that I’ve adopted over the past few decades, most of them learned through bitter experience rather than any useful guide or manual, will enhance your effective usage of version control. Never again be afraid to change a piece of code to test out an idea or worry about "losing the source code" years after you have worked on something.

1. Never check-in anything at the end of the day.
   1. Ever.
   2. This rule is the Golden Rule.
   3. It is inviolable.
   4. You will completely regret having checked in last thing the previous night if you do.
2. Check-in often.
   1. Don’t go weeks (or even days) between check-ins.
   2. Create a cheap branch to allow you to check-in without breaking the build.
   3. If you aren’t comfortable with branches, create temporary directories in the version control.
3. Synchronize regularly.
   1. Synchronize.
   2. Synchronize.
   3. Synchronize.
4. Your check-in procedure should be:
   1. Compile (if you cannot compile, why are you trying to check in?)
   2. Synchronize.
   3. Compile (if you cannot compile after synchronization, why are you trying to check in?)
   4. Check-in.
   5. Synchronize.
   6. Compile (if you cannot compile after all that, you have a merge error.)
   7. Run your unit tests or run the executable, whichever it is you do. ("It compiles, let’s ship it" is not a mantra for the development of robust software.)
   8. This will generally prevent about 99% of screw ups.
   9. It takes an extra minute or two.
5. Build all platforms and configurations.
   1. Xoreax IncrediBuild works great for this. So do other distributed build systems.
   2. Make it your job to have the time necessary.
6. Other programmers will thank you for not breaking their configuration or platform.
   1. The continuous integration server/build monkey is not a crutch for bad habits.
   2. Bad habits make the build monkey angry.
   3. Don’t use the build monkey to catch your compiler errors.
   4. An angry build monkey is not something you want to deal with.
7. Don’t check-in then go for lunch, coffee, smoke, bathroom break, nap, etc.
   1. Wait for the automated e-mail from the continuous integration server/build monkey to be sent out to verify all is good in build land.
   2. You do have a continuous integration server/build monkey? Right?
8. Don’t edit files without checking them out.
   1. Not even for "quick fixes."
   2. If you are going to be editing a file to test something out, and just want to "try it", check out the file to a new change list with the description "DO NOT CHECK-IN."
   3. That way, if you do something stupid, you can easily tell which file you did the stupid thing in by performing a diff.
   4. You can instantly see how your source code differs from the one in version control.
   5. And if you find you do want to commit your changes, it is easy to determine which files you modified with your "quick fix."
9. Atomize your commits.
   1. Each one should be a discrete step in the development process that reproduces perfectly a singular change.
   2. Don’t check out dozens of files, complete a half-dozen tasks in your project plan then commit them all back in.
   3. Break it up.
   4. Commits are cheap.
   5. Mistakes aren’t.
10. Don’t work outside of the version control directories.
11. Configure your continuous integration server/build monkey to compile after every commit.
12. If you think it should be in version control, put it there.You can always take it back out later.

Bonus Rule!

1. See rule #1.

Share this post with others

Posted in Software Development | No Comments »