The path has been found, let's move forward!

We've improved the pathfinding in the time management game. The system was working very good already but had some drawbacks when moving the actual character model along it's path. It just followed the tiles one by one until it reached it's target. Moving the character model from tile to tile results in this kind of movement:

As you can see, the movement of the character model is very mechanical like. A human would never walk like this in an open aera. But rather move in a straight line. We also want this more logical movement in the time management game.

I read several articles on how to find shortcuts in these kind of paths. I was looking for a simple solution which was easy to add to the current pathfinding/movement system we have. For now we use this;

When the path is found, the system is going to cast a ray from the tile the character model stands on towards the last tile node in it's path. Two things can happen obviously. If the ray doesn't hit anything it means that the character model can directly move towards the last tile in the path, ignoring the other path nodes. If the ray does hit something the ray is being cast again towards not the last node, but the node before it. If it doesn't hit, character can move directly to that node. If it does hit it needs to cast a ray again. It seems to work pretty good, The character models now move in a more human like type of motion.

Doing it this way has some drawbacks. First, it isn't the fastest way. Casting a ray is not cheap. We also need a seperate mesh to define the 'walls' to ensure that the ray will hit a wall. In the time management game this is all fine. The environment is static and isn't that big.

-- Joep

We’re Number 1!

On shockwave.com that is… Our latest release (the press release can be found here) Redline Rumble Revolution went straight to the number one spot over the course of a week. The game was released last week Tuesday and rose quickly to the top of the charts. In the pic below (taken yesterday 08-11) you can even see that we have three Xform games in the top 5, some (Burnin’ Rubber 3) have been there for a while… a year or so… :)

Strangely enough, even the original Redline Rumble has re-entered the top 10! As you might know Redline Rumble Revolution is a remake of the first- and original game in the Redline Rumble series. The game was released on the second of September, 2003 and has spawned 3 sequels, before returning to the original with ‘Revolution’. There are numerous fans of the game to be found on shockwave.com and they also produce lots of fanvideo’s of the game, where they show their fastest times or some dirty tricks they’ve learned by playing the game over and over.

It’s important to note that Xform was not the developer for any of the other Redline games, we’ve only produced ‘Revolution’. The game was met with as much enthousiasm as indignation, as to why the game should have been remade in the first place for example. Most gamers however are very much excited and love to replay their favorite game with the added value of the Xform quality stamp! Please let us know what you think of our newest release. You can leave your feedback here below, on Facebook or Twitter!

Click here or on the image above to play Redline Rumble Revolution right now!

-- Erik

Text trouble

Hi all! At this moment I'm busy creating a more definite look for the interface of our animal-related game. A big part of interface design is the creation of all textual elements such as dialogs, HUDs and buttons. Although an icon of some sort is often used, a lot of these elements require texts to function properly. There's a big difference between creating an interface for a 2D or 3D game though.

In 2D engines, texts can be rendered relatively easy to screen using conventional bitmap and vector / shape technology that is available in most 2D (middleware) engines.
In 3D, everything must be on a texture that is applied to a triangle in 3D space. For this, you are heavily dependent on what your engine supports or how much time you want to spend on it yourself. How annoying!
That's why, for simple 3D games, often programmers create buttons and text-elements as they go along using anything they can find. Sometimes an artists takes a quick look to adjust some colors and sizes and that's it.
For more complex 3D games, there's a whole team just for the interface. It is properly designed, and then it's up to the programmer to try to approximate it as best they can in code. Nowadays, some developers even create their interface in Flash and then render it onto their 3D games using middleware like Scaleform, allowing text effects and development flexibility that was never possible before.

Unfortunately, that's something we're not able to use in our 3D dev pipeline. We're very limited in the amount of different styles we can use, just because it would become a nightmare to manage. We also have to take 3D texture filtering into account (making some texts too blurry or too pixelated when scaled). On top of that, we need to consider that some of our games need localization. That's an ugly word in both 2D and 3D development. You never know how much space 'Thank you for playing' will take up in Chinese! Or, if the font that looks good for your game even supports Chinese characters! Doh!

-- Diederik

First alpha version

Hi All,

Like Matthew, Stijn is working on the Alpha version of our new platform game. He’s slowly discovering the joys of videogame production, which involve last minute changes and fundamental disagreements that only arise at the very last moment. There’s so much involved when making a game, even on a smaller-than-Triple A scale. To give you a small taste, we take a look into Stijn’s production diary:

Dear Diary,

Today is the deadline for the alpha version of the platform game I'm working on. Yesterday morning I was under the impression that only a few changes were needed. But then the game designers decided to make some last minute changes: We don't need feature A and B in the game, remove it, but we do want feature C... And feature D, E and F. I don't mind changes, but right before an alpha version is kind of stressfull. Apparently that's how it usually goes, but I think I'll call for another meeting one week before the next alpha/beta/gold version. That should save us all some stress :)

Right, back to work!

-- Stijn

Alpha Rush!

Hi guys,

The deadline of another milestone for our platform game is fast approaching. We’ve had a major upgrade in the graphics for our game over the last two weeks. At this point I’m really busy making art assets and pre-fab level elements for our programmer (Stijn) to integrate into his code. The idea is to have ready-made elements that can be used in various compositions to build levels.

It’s very important that everything works well together, so sizes of objects and distances will be essential to make gameplay feel exhilarating, a feeling I usually have when playing Mario games and something we want to recreate to a certain extent in our game. Tweaking these distances and adding elements in the right places can make all the difference between a platform game that feels like a chore and one that feels like you’re in the zone and makes you want to play more. Ofcourse Nintendo’s platform games are based on a legacy of great platforming and we can’t match the amount of tweaking and experience they have. However, our game is already looking great and without boasting too much, it's really is fun to play!

Now I have to get back to building the levels and interface elements so Stijn can do just the right amount of tweaking to make it feel right. If we’re making this much progress now already, I’m really excited to see what we can deliver in the end!

Cheers, Matt

Debugging trick!

This week Richard and I came across a bug in the time management game which we just couldn't solve. At some point, a visitor moves towards a so called 'free spot' (I wrote about this in another post) and moves to it's next target if it is available. Each visitor has points, and somehow when leaving a 'free spot' some visitors lost a point, which shouldn't be happening.

The hard part of this bug was that it didn't occur regulary, it was very hard to reproduce. So how did we solve this. We could have tried watching and playing the game over and over again figuring out what was going on when the bug occurs. Even while watching the game memory/variable values, it would take a lot of time to figure out what was happening. Therefore I decided to 'force' the game into the bug, well at least try to force it.

We let the game run until the bug occured. Then we paused the game and looked at the variables in the debugger. We did this a few times. Then we compared the memory data from the different situations to find matching values. The next step was to write a function which sets the game's variables, or better said, to 'force' the game's memory to specific values. The values to set to were the values we found to be matching when the bug occurs. When playing the game we ran the 'force game memory' function. After some small changes on the values to set, we were able to reproduce the bug. And find the piece of code which wasn't doing it's job properly. 

So to conclude it all, if you're working on a system which has a lot of different variables it can be a real pain to find a bug. Creating a function which sets the game's memory to specific values which you record when the bug occurs can help you reproduce the bug much faster. Which then most of the time helps you find the bug much easier.

-- Joep

We’re nominated!

The news reached us late last week; we’ve been nominated for the Dutch Game Awards in not one, but several categories! Both ‘The Adidas Neighborhood’ and ‘Burning Rubber 3’ have been nominated, the former in the categories ‘Best Advergame’ and ‘Best Visual Design’, the latter in the category ‘Best Online Game’. It’s my pleasure to let you guys know that we’re the developer with the most nominations of all contestants! Like this article mentions. That’s because the game we didn’t make, but did publish: ‘Flipper’ for DSiWare, which has also been nominated. Check out: Goodbye Galaxy Games to contact the Flipper developer!

The Adidas Neighborhood

Burnin´ Rubber 3

Flipper

The game award ceremony will take place on the 18^th of November in Amersfoort, a city not too far from Utrecht. In an old train reparation hall the entire Dutch development scene will be present to eat and be so nerdy that everybody will be afraid to talk to each other until they’re drunk enough. There’s more to enjoy on the 18^th and 19^th of November, when ”Game in the City” takes place in Amersfoort. There will be masterclasses, meetings and discussions. Interesting for both students and the people who have made so much money developing games that they can afford to miss two days worth of work. It can be very interesting if you need to orientate yourself in the Dutch Game Development scene or if you want to start for yourself. There are attractive subsidized possibilities coming up (courtesy of the Dutch government) in all sorts of directions. Bottom line: if you want to be where the development happens in Holland, you need to check this out!

We hope to see you at the Dutch Game Awards! We’ll be there for sure :)

-- Erik