The zombies are coming..

Hello!

Time for another blogpost today. First of all I want to bring some good news.. Our zombie shooter is nearing completion, it is almost done! Last week we did some playtesting to find and fix bugs and glitches. But we actually couldn't stop playing the game itself! Stay tuned, the trailer is coming soon ;)

  

Screenshot Zombie Shooter

The playtesting, or QA (Quality Assurance), is very important. A game, when released, should work. And not just be filled with bugs. During this process bugs are found and listed to be fixed after the QA session. If someone encounters a bug while testing. He or she creates a so called 'QA Ticket'. The bug or glitch is explained in the description of the ticket and also the steps to reproduce the bug are written down. This in particulary is important, because the programmer who's going to fix the bug can reproduce it for debugging. Imagine something very simple like this:

Problem: The sound isn't muted when pressing 'Mute Sound' in the options menu.
Procedure: 1. Start the game 2. Go to the 'Options' screen 3. Clik the 'Mute Sound' button.

This is a straight forward bug, and probably not so hard to find and fix. Bugs that occour during gameplay are much thougher to reproduce. Sometimes the player needs to be at a specific location within the game world. If so, we add a screenshot to the 'QA Ticket'. So the programmer can go to that location in-game, and follow the steps to reproduce the bug. Instead of starting a process of 'Trial and error' just to reproduce the bug in the first place.

The next step is to fix the bugs ofcourse. First the blocker ones, the bugs that cause game freeze's or prevent the player from making progress. What I mean by 'Making process'; A gate for example that should open after some actions, and it doesn't. The player is then not able to walk through it towards the end of the level, and thus not able to finish the level. Then the other critical bugs are fixed. Such as sound/music bugs, graphic issues, getting behind the boundaries of a game level where the player shouldn't be etc.

If the blocker and critical bugs are fixed, a new QA session is behing held. The QA process starts again until the game is ready for release.

Happy QA'ing ;)!
-Joep

Tell me who you are

Hello developers/fans/people who accidentally landed on this site,

Today we have tested one of our new games, which is (surprisingly) a super secret game.
Of course this is a very interesting process. If you like to read more about test days, you can read about it in an earlier post of Stijn.
But unfortunately for this project there's not much to tell, because the game is such a big secret. Instead of boring you by telling how great this game is going to be and that you can play it really soon, I like to tell you about something else: target audiences.

Target audiences? Why?
As you may already know, at Xform we like to make games that we ourselves love to play. But that doesn’t mean we don’t listen to our player base. We just want to know who they are, where they are from and why they especially like to play our games.

Target audiences are very important. For every product. For every game. Whether you are creating console games, mobile games or browser based games, you need to know what kind of people (are going to) play your games.
Are they kids or adults? Male or female? At what age? When do they play games and how much time do they spend on it? Do they play alone or with friends?

Knowing who they are and what they like is very valuable information when making a game. It’s most common to use this information for marketing and promotional activities, but you can also use it for game design.
This doesn’t mean you should base the entire game production on target audience facts. After all game development is a creative process and it is fun to surprise your audience with things they don’t expect. But, for example, if you know that your type of game is mostly being played by people that do not spend more than half an hour per day on gaming, then it doesn’t make sense to create levels with loads of side quests and fights that will take at least two hours to finish. Although this may seem quite obvious, there are just too many games that don’t match with their target audience.
You can also use your target audience analyses to treat your audience on extras like special enemies or funny easter eggs. They will appreciate it!

How to define my target audience?
To define your target audience you have to do research. And of course there are millions of options to start with this.
If you have a lot of money you can spend it on an exclusive research institute that will do all the work for you. Or you can hire some specialists and start a research department at your own office. Unfortunately, at Xform we don’t have this opportunity yet. We have to do the research by ourselves, which is actually very interesting.

My advice for starting with your research is to keep it small and simple. Stay close to your company and take advantage of all the information about game target audiences that already exists. Believe me, you can spend hours on reading books and web articles about this. Now it’s your task to find out which information is valuable for your game.

If this is the first game you’re working on you might start to take a closer look at similar games from the same type of platform. What kind of people play this games? They might want to play your game too.
When you already developed some games you can also do research on these games. Find out what’s the target audience from your previous games. Internet offers you some interesting tools that might be useful for this. Every social media site has an option to track down user data and information from your fans.

We also started to use Google Analytics for our Xform website to see who are interested in our company and games. So now we can see how many and for how long people visit our site, if they were looking for something in particular or that they just accidentally stumbled upon it.
A lot of information might surprise you. I didn’t know most of the visitors on our homepage are from Brazil:

visits on the Xform website (last two weeks)

Have a nice weekend!

- Shirley

Replay fun

Dear readers,

I've been working on another car game and last friday afternoon after doing some boring stuff I felt like doing something fun and that could be done quickly: a replay function. None of our games currently have this, but for the game I'm doing now I think it would really add something.

Before we can replay anything of course we need to record. The first thing that comes to mind is to simply store our key input and on replay the stored key input is used as input for the car. But as we're using a physics engine which I don't trust to be deterministic (the same input results in the same output) it would lead to a different replay which of course is not what we want.

Another approach which is easy and sure to work is to store the transforms of the car each frame in a list and when on replay simply go through the list and setting the car model to the stored transform. This is what I currently do and it works well. But let's analyze it. We're running at 30 frames per second and thus storing 30 transforms per second. For each minute of replay we store 30 * 60 = 1800 transforms. Assuming each transform is stored as a 4x4 matrix of floats, so 16 floats at 4 bytes per float: 64 bytes per matrix. And so for each minute of replay 1800 * 64 = 115200 bytes. Considering today's RAM capacity in computers this is peanuts. But this of course is only for a single car and additional actions have not been recorded (for example car damage, firing of weapons, etc). One way to reduce the size of the replay list would be to store the transform every X frames and interpolate between transforms, although you do lose accuracy with this approach. Another way is to only store transforms when they've changed 'enough' with respect to the previously stored transform. In this way a car that does not move would not cause the replay list to increase in size.

With a replay you can think of simply watching what you (or someone else) did. Currently I implemented it as a replay while you're playing: like a ghost rider (See image below). In this way you get the feeling you are competing which in my opinion adds to the fun and I hope the option will be there when we release the game.

Image from 'BMX Ghost'. A ghost rider is shown displaying the best round you previously played.
-- Stijn

New prototype

Hi all,

A few weeks back Stijn started programming a new game prototype which is basically a downhill ski-game with a special Xform twist. Last Monday I was put on the project to create a track and some (temporary) graphics for this prototype. The game just needs to look and play good enough to get a good impression of what the final product could be, therefore I won't put a lot of time in designing and fine-tuning the track. I'll keep you guys updated on this project when (and if) it goes into full-development.

Cheers, Matt

New Game Sneak Preview

When you don't have anything to write about you can always post a super secret screen of an upcoming game!

Greets,

Diederik

Baking data..

During development of the zombie shooter we were experiencing an increasing amount of loading times due to all of the new features which got added. This isn't unusual, since it is something logic as cause and effect. But the loading times were getting a bit too long. So we decided to take a look at it to find out where we possibly could find a speed up.

Some technical systems in the game use a lot of data calculated/generated during the loading stage, which takes time. One of those is the pathfinding system which uses the most data at the moment. It generates all of the node data needed for the zombies to walk from A to B during startup. As you can imagine, having a decent amount of nodes to be processed every time the game loads up takes time. Too much time in fact for our needs.

So how to solve this. Since it is a system which is 'calculating' things to be stored in the computer's memory for realtime use after loading, it is possible to capture this calculated/generated data. The trick is to save this generated data and store it in some sort of file from where it can be loaded directly during startup of the game.

Now having the data we need saved in a file, it doesn't need to be recalculated/regenerated anymore during loading. We could say, the (navigation) data is baked into a file. With the data already present in a file, it is possible to directly load the data into the computer's memory instead of calculating it first during startup. This is much faster than calculating/generating the data on every startup of the game.

The main drawback of doing things like this is the need of recalculating and saving data everytime something relevant to that data has changed in the game. The plan is to create a system which automatically detects changes, or at least is possible to force into a mode where the already saved data needs to be overwritten by new generated data.

A lot of technical talk, hopefully next post some more images ;)

-Joep

Particle stuff!

Hi all,

Unfortunately, most of the time I am working on ‘secret’ projects or projects on which we simply cannot share as much as we would like. So this post will be about something I am doing in my ‘spare’ time. At least what is left of it ;)

As some of you might know I am a big fan of everything that involves particles. Especially explosions!

Unfortunately, Adobe Director’s own particle system doesn’t really suit my needs. It is ok for a lot of quick things but for the games we make it is a little outdated. For example; you cannot rotate or animate particles individually and you don’t have any blending options (additive blending) yet. Finally, there is no general time or speed multiplier for the entire particle system. Our games sometimes feature slow motion and so we’re unable to dynamically change the speed and lifetime of the system. All in all it was time for our own particle system. So about 10 games ago (more or less,..) I decided to create my own particle system from scratch.

At this time, 10 games later, I still haven’t got a perfect particle system up and running. Mostly because I noticed early on that creating a system that could do everything that I (or one of my colleagues) want is simply not possible. The variations are impossible to count. Furthermore, as I can’t go as low-level as the default Adobe Director particle systems I run into performance problems.

So as we speak we have a default particle system class which handles general particle behavior and when we need an additional or new effect we simple use this one as a base for new particle classes. The default setup handles birth, life, texture animation (if necessary), position, rotation and scale. For the transform properties we also have speed and direction. The slightly more advanced ‘default’ ;) version also does drag, gravity and wind. Each frame the particles are updated until they reach the end of their life after which the are deleted. When all particles are deleted the particle system cease to exists. For most particle systems we use planes (simple 2 triangles forming a square) on which we display the animated (texture). However, we could also use other types of geometry (which we could even add to the physics solution). With the basic setup we can pretty much build any possible particle system we need and can do everything the default system can’t. The biggest and perhaps the only downside is that bigger, more complex system can cause too much of a performance drain.

So to end this post a couple of short cases of particle effects based upon the base particle class.

1. Particle trail

Sometimes you want a consistent trail of particles with a constant size. You cannot spawn a new particle each frame, because;

a. The distanced travelled can exceed the particle size and thus creating gaps
b. In slowmotion this would mean lots of particles would be spawned at almost the same place.

For this system I calculate the distance and direction between the systems current position and previous one. If this exceeds the size of the particle (with buffer) I fill the distance travelled with particles (not forgetting to update all particle settings accordingly).

2. ‘Volume’ explosions

It always bothered me that our previous explosions always start from a single point and move outwards. While this would work perfectly for a grenade it always looks weird with bigger objects. I could spawn a explosion particle system and update it instantly at how it would look over 10 frames or so. I experimented with this, but I simply wanted an explosion to fill up the object. There were a couple of options. Iterate through all vertices of an object and spawn a particle at that world position. Still something I would like to test ;) but I didn’t expect this to be very fast. So for a quicker solution I opted to use the volume of the bounding of the object to define particle positions using a 3d grid. As I store bounding boxes of available meshes anyway this could be done fairly easy. You could say this won’t look nice with weird irregular shaped object and I agree ;) Nevertheless, most of it is blocked by smoke and fire and it all looks cool anyway!

I am off now!

Cheers

Pieter