dinsdag 30 november 2010

From Marketing to Production

As the snow begins to fall and mass hysteria sweeps the nation over a bit of frozen water, we all start work with ice cold enthusiasm here at the Xform offices. Even the mice seem to be too cold to come out and grab our breadcrumbs. The end of the year is always the perfect time for a bit of contemplation on what has happened in the last year. Mainly because there’s nothing else to do of course. I’m staying inside as much as I can from now on, but before I get cabin fever I want to reflect on some videogame related memories and thoughts for the future.

I started in videogames as a writer. I was so bored with the movie theory I had to read for my study (“Film- and Television sciences” at the University of Amsterdam) that I decided to apply my own  theories to videogames. Videogames played a very small role in the curriculum as a part of “New Media” the major (nowadays you would call it a Master) I decided to follow. 

I ended up at a Dutch television show about videogames for an internship. It’s a show called Gamekings and they still make damn good television now. These guys were really cool and I enjoyed my time there very much. I learned a lot about work and life in general there and made some good friends. Plus, I got to travel all over the world as a cameraman on location.

After that I made a clean break there, because it felt wrong staying there not knowing what I really wanted (as always with me). I ended up at now defunct Playlogic International N.V. as a Product Manager. My first experience with an actual “office space” got me depressed for a while. But I did see potential in the company at that time and felt the motivation to push on. After 2,5 years I jumped ship just in time and joined Xform.
Now it’s time to switch my work once again, from marketing into hardcore production. I think videogame production suits me the best, because marketing involves too much lying and betraying your conscience in general, not a strong point for me. Being part of a real production company, seeing how products get made and actually get finished is a great experience.  Plus, more importantly, you actually get to see the fruits of your labor, once you put something in you’re instantly rewarded with the result of what you do. I’ve had contacts with production at all times during my marketing times and always wanted to know everything about the project. In marketing you’re always treated as someone who doesn’t know what it takes to make a game and your requests are always greeted with a very deep sigh. I think I’ve always known how it works a bit, because I’ve worked in television production, but at Xform I can finally see it firsthand. Browsergame production is actually the most hands on I’ve ever seen videogame production work. It’s production in its purest form and at Xform  games tend to be pure fun.


-- Erik

maandag 29 november 2010

Office Space Invaders

Hi all,

Bad news! We had a break-in this weekend. Another one…

A couple of months ago we were also ‘targeted’ and all of our game consoles were taken. This time nothing is missing,.. Fortunately… The door to one of our offices was kicked in, but the only valuable thing in there is a TV and it is probably too heavy to carry anyways. Nevertheless, it is a pain in the ***. The door needs to be fixed, a visit from the cops, etc. All sorts of time-consuming tasks you don’t need or want when starting a new week on Monday morning.

Honestly, I don’t really care that much if they would take the PS3 again as long as the leave our computers alone. When something like this happens it always reminds you of making sure your work is properly backed up and safely stored. Thankfully, we've always done this since the beginning. Not only by making regular hardcopy backups (DVD storage and external hard disks), but also by storing your work on multiple computers at work and at home (using file versioning software). So if things go wrong again we’ll always have the most recent developments versions of all of our projects. It is a shame you have to keep this all in mind. Making sure that whatever happens; theft, fire, airstrikes, alien invasions (I am blaming the aliens for this one), nuclear detonations and earthquakes your work is never gone. Wouldn’t want to start Burnin Rubber 4 from scratch again…



Well, to end this post on a positive note. This week we will be starting to work on an update of one of our games. Of course I can’t tell you anything about it, only that it is going to be awesome! Again… ;)

--Pieter

vrijdag 26 november 2010

Turning 2D into 3D

Dear readers,

I've been waiting for artists to continue my work on the platform game, but they were all put on other projects. So it was just me working on the platform game, which is not very exciting. In the meantime I've been working a little bit on a side-project, something that would be useful for the level designers. The levels for our platform game are in 3D and currently our artist Matthew has little bits and pieces that he has to copy and put together to make a level. Only in the 3D program we're using this is not a fast process. Matthew suggested using a 2D tile-program and then converting the 2D tiles to 3D as in the 2D tile-program you can create the level much faster. Good idea, but easier said than done of course. So I investigated a little to see if it would be doable within a short amount of time because if it takes me more time than Matthew gains by it then it might not be worth doing. But I was able to do it within one day and it works nicely and gives us a quick and easy way to make levels. The level designer no longer has to attach vertices himself or detach the grass objects on top. On conversion I also made it so that each disconnected piece of ground becomes an object which makes the game run more efficiently (as we can choose not to display ground objects which are not in the player's view). The level designer will still have to place custom items manually in the 3D program, but the 2D is very nice for quick prototyping.

Test level designed in 2D map editor:









 Converted to 3D:









I think I took more time programming this than if it was all done manually, but I learned more about scripting in the 3D design-program we're using plus the names of objects are always correct. So it's very useful :)

-- Stijn

woensdag 24 november 2010

Minigame Mayhem

The time management game is making good progress. We are entering the final stage of development. Which doesn't mean that there is less work to do. We took a look at the game to see how it plays at this moment. How long it keeps us interested and entertained while playing. In my opinion the game is pretty solid already. But we decided to add a little more to get some variation in the gameplay. At this point most of the 'Levels' you can play feel pretty much the same. They vary in difficulty but the gameplay is generally the same. This is where we want to make a change.











Diederik came up with the idea of adding minigames. Imagine collecting a bucket and a brush. Then fill the bucket with water and take it to an animal to wash it. The minigame to play could be to wash an animal within a certain time limit. Washing for example, could be done by dragging over the animal with a brush as cursor. When the player succeeds, extra points are awarded. This way we 'break' the straight forward point and click gameplay of the main game.

The first 'wash' minigame is currently working with mockup graphics. It seems to blend into the game pretty good. If it works out as planned we probably keep this in the final game. And of course, add more different minigames.

-- Joep

dinsdag 23 november 2010

Just another awardless day…

We at Xform find ourselves at the office again for another day of work. Lately it seems just a tad bit more meaningless than normal… Why? It’s because we didn’t win anything last Thursday at the Dutch Game Awards :(

I’m kidding ofcourse, we’re slightly disappointed, but we don’t need recognition from a… well from anyone really. The fact that a single Xform game gets played by more than a 100.000 people each day is recognition enough that what we do is liked by a lot of people. However, with all that said, we have won a little bit in spirit with Flipper. The game won an award for “Best Mobile/Handheld Game” and the jury credited its only developer Hugo Smits (Goodbyegalaxygames) for this huge achievement in designing and programming the game on his own. The term “Bedroom coder” was used to describe what he had achieved on his own… literally in his bedroom (in Dutch we normally tend to say: “attic coder” for that type of person, just to emphasize the loneliness of it all). He has had a lot of help from us in publishing Flipper, but as this prize is meant for the development, it’s only right that he should take the credit for this on his own. It was great to see Hugo shining with his red owl on stage, a great crown on all his efforts and hard work. It’s still unclear what will happen with Hugo’s upcoming Flipper 2 but I’ll try to keep you up to date as much as I can what will happen from our standpoint. Nothing has been decided on this new game yet, so it’s up to Hugo!


It wasn’t all bad… for me at least… I was able to claim two awards with my former colleagues for a game I’ve worked on in 2009 and 2010. It’s a testament to the open and kind character of the Xform people that I was able to join my ex-colleagues in celebration of the award for “Best Visual Design” and “Best Audio Design” for the game Fairytale Fights. It was my old employer Playlogic that developed and published this game and I helped (my ass off) to make it! The company has unfortunately filed for bankruptcy in the summer of this year. This was after the game proved unsuccessful, with a very small chance the company will start over under new management, but this chance remains minuscule at this point. I decided not to stay for all the pictures at the award ceremony, this is something that the PR person should do, he still represents the company, together with the composer of the game, responsible for the audio. I’m working at Xform now! Next year we should definitely win a prize, as someone that has joined the company very recently I think there’s so much worthy of appreciation in the Xform line up, it’s high time for us to get the recognition we deserve from the jury. In the meantime millions of gamers will play our games, for now that really is all we need to keep going…

-- Erik

Color correction on textures











Hi all!

The last few days I've been working on some color correction for the textures for the water race game.

In most 3d games, the designer wants to achieve a certain ambience in the level he is building (i.e. dark, gloomy or maybe bright, sunny or even red and vulcanic). Nowadays, this is done by using techniques such as ambient occlusion, realtime pixelshading and shadows and fancy postprocess color correction on (parts of) the screen. As you might have guessed, we can't use any of that :(

Although for some games we do use lightmaps for more defined shadow and shading, sometimes this makes the whole game just too big and sluggish. So for now, we just use real cool retro realtime vertex shading and fogging.

Vertex shading can color the object's faces darker depending on the vertex's position and orientation toward one or two lights. Not really a lot of control on final tinting unfortunately. But at least it gives some more definition to the object's form and perspective.

Next to this we use fogging of objects in the distance. When used with a nice atmospheric skybox this can work really well. We don't want to fog too much though since it may interfere with our transparent objects and particles. Doh!

If done properly, this usually looks pretty okay, but not very special or unique. We sometimes like to add some additional color correction to the base texture to achieve more color depth and tinting, as seen in the final results picture above. Of course, this will make the texture only useable in one particular ambience! For our project, this is no problem.

In step 1, the darker tints in the base texture are desaturated. Often the darker tints of a particular texture are just darker version of the same color. This sometimes makes color spectrum a bit dull and fake. Maybe you could even add a step here to make the lighter colors more saturated.

In step 2, we create a gradient map that defines the color scheme for our level and apply that to a copy of the base texture. We then blend that with the prior result to make the texture fit more into the environment.

In step 3, we add just a tad of fog color to the texture. This will make it blend even more into the environment and sky. It removes too much unwanted distracting contrast and is more pleasing to the eye.

Back to work!

-- Diederik


vrijdag 19 november 2010

Turn around, every now and then...

An important feature of platform games is enemies. Enemies that will try to harm you and make the levels harder and more diverse. From a level designers perspective you want to be able to place enemies wherever you'd like, so for a programmer there is no hard-coding enemy behaviour like "when the x coordinate is greater than 5 then turn around". Instead enemies should be able to find their own paths. When the enemy bumps into an object he should turn around, so we might think "Ok, let's use the collision report that the physic engine will give us", but that won't do because sometimes the enemy needs to turn around when there is no collision. "What?" you might say... well, we don't want enemies to run off platforms and in to pits, so they should turn around at the cliff but we won't get a collision report. We might introduce a new invisible kind of object and place that at every cliff, but our level designers won't like it. So let's explore a ray casting solution.



We cast a ray from the center of the enemy (a collision box, see image). W is the box width, H is the box height and L is how far to look ahead, R is the length before the ray hits the ground (on flat ground, ignoring slopes for now). This diagonal ray captures both to turn around on objects that are on the enemies path as well as to turn around when reaching a cliff. If the ray hits an object within distance R then there is some object in front of the enemy, but this doesn't necessarily mean the enemy should turn around. It could be that the ray hits the player in which case we don't want the enemy to turn around because we want the enemy to hurt the player. So some objects the ray hits should be ignored. When the ray hits an object at a distance exactly R then it's the ground the enemy walks on and it shouldn't turn around. If the ray didn't hit any object (ignoring the player) within distance R (plus a little bit) then we should turn around otherwise we will fall down possibly in to a pit which we don't want.


Now let's also explore slopes. Slopes sort of ruin our solution so far because now when the enemy starts walking up a slope we will get a ray hit with the ground within distance R as shown in the image. What we can do to avoid turning around now is taking into account the normal of the point on the ground we hit. If the normal is not strictly up (Y axis) or strictly to the side (X axis, the walls are also ground) then we've hit a slope and we won't turn around. It gets more tricky when walking down a slope. What we would like to know is "the distance along the ray when we can be certain we're not looking down a slope, but we're at a cliff and we should turn around". This depends on the steepest slope we have in the game which is 2 units right, 1 unit down. The ray we cast has "slope" (W/2)+L units right, H/2 units down. Looking at the image above at "Walking down a slope" we want to find the distance where the ray intersects with the slope. To calculate this we start at the intersection point and walk back until the difference between ray and slope is H/2. The equation to solve then becomes ((H/2)/((W/2)+L) - (1/2)) * t = H/2 in which t is the unknown which can be calculated by t = H/(H/(W+2L)-(1/2)). Note that (H/2)/((W/2)+L) should be greater than (1/2) or else t will be negative or when they are equal we get division by zero (meaning they never intersect). The distance S after which ray R intersects the slope then becomes sqrt(t^2 + (t*(H/(W+2L)))^2). This should actually be a bit more cause I haven't drawn the worst situation (Can you see what is the worst situation?). Now if ray R hits a slope and the distance along the ray is greater than S then we should still turn around (this situation can happen if we're at a cliff but somewhere below there is a slope).

And now that I've thought this out, it's time to code it. There are still little things to take into consideration, but this will do for the most part.

-- Stijn

donderdag 18 november 2010

Fixing Potholes

As the week draws to a close certain events return like a vicious cycle. The ending of the workweek at Xform is usually the sign that some sort of Alpha, Beta or Gold Master Candidate (GMC) milestone for one of our games needs to be finished. This milestone is then delivered to one of our customers for their approval and (depending on the type of milestone) to receive comments on playability and design from them.

In the Alpha version you get real happy that there’s something there to begin with. The process of planning and brainstorming on the game design document finally gets expressed visually in a playable game.

By the time you reach the Beta version more elements come into play and there’s a lot more to think about. As the only dedicated artist, lots of requests land on my plate for assets that need to be enhanced beyond the lower grade visuals that might be in the game up until that point. For this version you want the game to look a lot closer to final, but it should be clear that there’s still a lot of tweaking to do in order to have the game ready for launch.

Once you get to the point of the GMC, you’ll be fixing potholes everywhere. It’s a lot less about getting the game to work and a lot more about getting the game to work perfectly. The analogy works very well because of our racing game heritage, but is of course, also very true for our differently themed games. There can literally be bits and pieces missing in the scenery that might only come up when someone falls through them while playing. It’s a process of fixing and filling the world with believable textures and I’m afraid I have to get right back to work in order to do that. On top of all the work today we’ll be leaving earlier today for the Dutch Game Awards, so I’ll have to make it count!


-- Matt

woensdag 17 november 2010

Learn to play!

I'm currently working on the 'Tutorial' mode for the time management game. We are going to display the tutorial as a text bulb on screen, filled with text telling the player what to do. We decided that the player always has to click through a tutorial message. Of course, the tutorial can be skipped entirely.












A system like this is pretty tricky to develop. It has to be modular, so it is easy to add more tutorial messages and actions for example. We use some sort of scripting from external files to tell the game which tutorial message to display at what time. Some tutorial messages have triggers, to force the player to do a certain action before the game can continue. These triggers are partially defined in the main code, or better said 'hard coded'. And partially defined in the external scripts.

Currently the only drawbacks of the system are the hard coded triggers (and long scripts.. to define all the tutorial messages..). It would be better to have these completely working on their own from the scripts. So we can manage the tutorial message system entirely from external scripts.

(Not the most exciting update.. but hey, work can't be always exciting! )

-- Joep

dinsdag 16 november 2010

The Dutch Game Awards

I’ve mentioned this before, but every year the Dutch gamedevelopers get together in an abandoned train hall near Amersfoort station. If Utrecht is the place where all the traintracks in our country come together (Utrecht is very much in the middle of Holland) then Amersfoort is the place where all the trains used to cool off when they were done transporting everyone around the country.

It is in a hall where these trains used to be repaired that the Dutch Game Awards will take place. Both Amersfoort and Utrecht play a central role in the development of Holland as a government subsidized gaming country and Amersfoort even hosts Game in the City completely in their city, putting it on the map not only as a gaming-, but also as a very creative city, due to a huge push from the government and other cultural funds. Unlike most of these government projects, these actually seem to work and have a very positive vibe to them.

Xform isn’t a company that is subsidized in any way (yet), most of the companies nominated for the awards aren’t either. The Dutch Game Awards are the awards that unite all Dutch developers and publishers and is more to honour the development, boost the morale and bring all the developers together in one room. This year, the biggest Dutch game publisher (and my former employer) is honoured posthumously with a nomination for their game: Fairytale Fights. A game I have worked on too… The Fairytale hack ‘n Slash fighter has a lot of my (and a lot of my colleagues’) ‘crunchtime’ in it and it would be nice to see the game get one award since the company that released it is officially bankrupt now and will probably not restart any time soon.

One of the organisors mimicking the look of the award: an Owl with sharp edges that could easily poke your eye out!

As I posted before right here; we’re nominated for four categories with three of our games: Burnin’ Rubber 3 (Best Online Game), The Adidas Neighborhood (Best advergame, Best visual design) and ofcourse Flipper (Best Handheld/Mobile game). If you haven’t voted yet for the Control Industry Award, please subscribe yourself to the Control Magazine newsletter (Control Magazine is the official host of the dinner party) and you can still cast your vote for this year’s winner.

Fingers are crossed. We’ll see you there!

-- Erik

maandag 15 november 2010

The end...

Hi all,

We’re nearing the end… The end of 2010 and our ‘secret’ water game. The holidays are coming and we aim to be done with it before we celebrate them. Last week we delivered a beta version of the water game. It includes everything the game needs. Art assets, functionality and audio. Now we’re entering what we call ‘hell’ ;) Tweaking, testing and fixing the game.

Although it can be quite rewarding, finishing and polishing a new game is a rough, tough, stressful and sometimes frustrating job. Personally, I find it quite difficult as well. It is a moment when you are confronted with your toughest bugs, issues and wrong decisions . Confronted with bugs you already know, but also the bugs you get from testers and clients. You need to keep focus on creating the best game possible without losing hope while reading all bug lists and documents.

When finishing a game I tend to list all ‘easy’ bugs (at least the ones I think are easy) versus the more difficult ones. This way I can actually reward myself with progress. This might sound weird, but I can feel quite satisfied when fixing a difficult bug and the run through a whole list of easy ones and see the game becoming better, more stable and more fun with each new iteration. I find this actually very good practice as it provides me with some incentive to tackle the really tough ones. Most of the time these bugs are challenging, but not impossible to fix.

However, the worst ones are the bugs that keep returning from the dead. They are like zombies. You put them down, but they simple stand up and reenter the bug list during another QA round. Although sometimes they are on the updated list, because people forgot to remove them. That is actually quite nasty, because I think I screwed up again while in fact it is working just fine and I am just wasting precious time.

I can track the really tough bugs in my code quite easily. When things go wrong I comment my code ‘differently’. Comments like: Hack, Stop! Hackertime!, Just Hack it!, New Hack City, or Dutch/English profanity. I have a nice anecdote about this, but I’ll save that for another post. It is sometimes fun to read those comments on a Friday afternoon with a ‘cold-one’. However, it is Monday now and while things are looking decent for finishing up this game I do suspect some laughs and frowns at my comments next Friday afternoon.

-Pieter

vrijdag 12 november 2010

Find that safe spot

Dear readers,

Last week was the alpha version of my platform game and I'm pleased to say it went well. So from now on I'll be working towards the beta version.

There's a lot of stuff to do for the beta version and one of these things is when the player falls in to a pit, he needs to spawn at a safe location. Previously the player would just die and have to start the level all over again. We decided that that was too much of a punishment and instead the player should lose a little bit of health and spawn back at a safe location. To find that safe location we keep track of when the player was last on the ground. This is shown in the picture below.


Here the player falls in to a pit and the last location on the ground is shown with the transparent model. A problem here is that when spawning the player at the transparent model he is right at the edge and could fall off again, instead we should make sure the player spawns at a position that is not too close to the edge. A solution would be to spawn the player at the last location on the ground plus a displacement in the negative direction the player was looking. Then in the above case the player would be spawned away from the edge. But unfortunately that is not a good solution as can be seen in the next case, where the player would then not even be spawned on the ground and immediately fall in to the pit again:




Instead we cast rays to the left and right of the player, straight down and see which rays hit the ground within a short distance. If both rays hit then the location is safe. If only the left ray hits then we displace the safe position to the left and similarly for the right ray. And this solution will work fine for now.

-- Stijn

Level editing and workflow

Today I’ll tell you guys more about the level editing of our new Rhino-themed platform game, in its essence this game is a 2D sidescrolling platformer with 3D graphics, much like New Super Mario Bros. We’re working on quite a few projects right now here at Xform so unfortunately we don’t have the time or resources to build a custom level editor, instead we’re using 3D studio Max and some custom max scripts. It’s far from perfect but it’ll get the job done. 

Before building the levels I’ve prepared three files: 

  1. LevelTiles.max which contains the floor tiles
  2. LevelMisc.max which contains all the non interactive background elements like trees, bushes, rocks, clouds etc.
  3. SharedObjects.max which contains interactive elements which are re-used in each level like destructible blocks, pick-ups and floating platforms.
For each level I have to create a new file(LevelX.Max) and merge the files mentioned above using Xref. The reason I use Xref  instead of a normal Merge is that it’ll automatically update changes made in the original file. For example: I’ve made a tree in LevelMisc.max and placed 50 copies of this tree in LevelX.max but afterwards I had to change the trees mesh, luckily changing the tree in the original Xref file will automatically update the trees in the level file.

When the level is done I export the LevelX.max file using a custom max script, this script exports the floor 3D mesh and replaces all the Xref objects with dummies which only store the location, rotation, scale and name of the respective object. I also export the 3d assets of LevelMisc.max and LevelTiles.max.

Once this is all done the game engine loads the 3d floor mesh and replaces the dummies with their respective assets. This setup makes it possible to adjust level assets until the end of the project and also keeps the filesize small.

























-- Matthew

woensdag 10 november 2010

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

dinsdag 9 november 2010

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

maandag 8 november 2010

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

vrijdag 5 november 2010

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

donderdag 4 november 2010

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

woensdag 3 november 2010

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

dinsdag 2 november 2010

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 18th 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 18th and 19th 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