vrijdag 27 april 2012

Mega Man (Rockman) defender grid!

Hello all!

Today a new blog! This week we're going back to NES/SNES games! Why? Well, as you all know by now is that one of our upcoming game will be a new genre! And of course you are all thinking of our Soccer game! The development of the game is going pretty fast since my last blog. That's always nice, but it's also needed to cause our beta version. The last few weeks were pretty good for me since I didn't had to work much on other projects, so I could finally set my mind on the soccer game!

I made some nice progress with the game modes and almost finished the interface and menu. Most of the time we will be having small updates for those 2d stuff, so we won't be finished with that until the release version. But next to that we also need a working keeper (my last blog). And we need some defenders, which is not as easy as some of you think. Can't just place them random on the field and let them do their thing. Like in real soccer we need formations and that's what this blog is about.


Mega Man's Grid
When I was making some notes of how I can make the setup I had to think about Mega Man (Rockman for some)! Remember the passwords for Mega Man?
B1 B3 C6 D3 E6 F1


Picked a stage, run through the level and kill the boss on the end. And you got to see a nice grid with some nodes like my formations. :) Every stage the same order and still stays fun to play:) Kicking the boss his/her ass to get to Willy or Light and watch how he begs for his life and comes back in a new sequel :P awesome:)

Xform's Grid

But as you can see we had to think about some formations to make it harder for you to score. In the beginning they will take some spots in the middle and it is easy for you to score. But when they come with more it will become harder, because they are with so many defenders you can hardly see something, unless you can learn how to control the ball very good. :) Making some nice effects with it and trying to avoid the defenders. :)
With these formations we can make the defenders defend the goal on a more proffesional way instead of some amateurs that are just standing at some random position.

Defenders in Xform's grid

That's about it for now. Enjoy a good weekend and make some cheers for our Dutch Queen, who will be celebrating her birthday!

Greetings,
Michael

vrijdag 20 april 2012

It's all in the game!

Today is the day. We need to deliver two alpha milestones to one of our clients. First of all there’s the alpha of the soccer game Eugène and Michael wrote about. And secondly, there’s an alpha milestone of one of our newest racing games. To make sure that we can send out a neat alpha version, there’s a lot of work to do. Instead of a beta version an alpha version doesn’t need to contain all in game features, but we do want to show our client the most essential game functionality. Together with a (mockup) menu, screenshots of stuff that’s not in the game yet and an updated game design document they can get a pretty good idea in which way the game is developing.

Today is Friday. And it’s quite. Even the radio is turned off. This can only mean one thing: everyone is working his ass off.
Since there are loads of tasks before every milestone, our programmers and artists are always in a rush at the end of the finish line. There’s always something extra that need to be done. And if you think that everything is finished, there are some technical issues to surprise you. So we need to take care not to wait with important tasks until the last day. That’s why I will annoy my colleagues during the week by asking them repeatedly if tasks are already finished, to make sure that everything we’ve scheduled for our milestone will actually be in the game. I want them to finish most essential stuff by Thursday, so the Friday (milestone day) will be less stressful for them. When taking a look around they’re still busy, but I think I can receive their alpha versions in any minute now, which means it’s ready to send out to our client.


Enjoy your weekend!
And give a big applause for my colleagues who managed to finish their work right on time!

Cheers,
Shirley

woensdag 18 april 2012

Shoot to kill



Dear readers,

The past few weeks we've been working hard on the final version of our next game. And it should go live very soon!

In the game the player is shooting on enemies, buildings and crates to destroy them. The way shooting bullets is handled in most of our games is that each bullet casts a ray (in the render engine or physics engine) to check if it hits an object. This is done each frame because the bullets are not instant but they fly through the scene over a couple of frames. Our game however is a flash 3D game and at the time of writing there was not yet a way to cast a ray inside the render engine to check if it hit an enemy. No worries, we still have a physics engine. Unfortunately the physics library we're using is implemented using ActionScript 3 code. A physics library in ActionScript 3? Isn't that slow? Indeed! It's slow, so we must be careful we don't cast too many rays per frame. This is a bit problematic for a game in which a lot of bullets can be flying around so we need some tricks to keep it down.

First of all the enemies in the game are not done with physics, they are done by just moving the visual models. So ray casting on these enemies cannot be done through the physics engine. So we do it ourselves using mathematics: given a ray and a box in space we can calculate if the ray hits the box. We can also do the same for a ray and a sphere. We then associate with each enemy a box or a sphere and in this way each bullet can cast a ray to check if it hits an enemy. Of course this is not pixel perfect but this does not ruin the gameplay as players will barely notice this.

Second, there are objects in the game that do not move such as buildings and crates. The buildings are meshes that are put in the physics engine, only just for ray casting. The bullets have a predefined path (straight forward) as soon as they are shot. This means that we only have to cast one ray at the initialization of the bullet and store the intersection point and associated object. If after a couple of frames the bullet passes the intersection point then it has hit the associated object. In this way the bullet does not have to cast rays on these static objects, only on the moving enemies. This significantly reduces the number of ray casts.


In the image above the path the bullets follow is indicated by the green ray. At the start of shooting a new bullet, the bullet checks along the green ray for intersections on buildings, crates and other static objects. After this the bullet only has to check for intersections on moving enemies along the same ray each frame.

-- Stijn

vrijdag 13 april 2012

Do you snap it?



Do you guys love racing games?? I hope you do, because we're currently developing another one and this one is going to be special! I'm in the middle of designing and creating some of the tracks. In one these tracks the player will enter a big parking garage, drive a few stores up and jump down on the street below. Building a low poly parking garage like this can be a daunting task....unless you create it with modules or building blocks. Most parking garage floors look similar, which makes it perfect modular modelling.

Before modeling first determine which building blocks are needed. An entrance, exit, straight parts, corners, a part which goes a level up/down etc. Now start modeling the building block, keep in mind that all blocks need to snap to each other perfectly so try to work on a grid.

The image below shows all the final building blocks I need for my level. Each block has a high poly version, low poly version and a collision object (displayed in red) which fits perfectly on the other models. In this case the low poly versions aren't used for your typical "Level Of Detail", but are used to complete the garage parts where the player can't drive. The low poly versions are copies of the high poly models, but with all detail like lamps, doors, fire hoses etc removed.


The image below shows all versions of a corner block.


With all building blocks finished it's easy to create a parking garage. A big advantage of building blocks is that it's very easy to adjust the size of (in this case) the garage. Want a few stores extra? Just snap it on!


Cheers,
Matt

woensdag 11 april 2012

Mirror Madness


Hello all!

So another blog about the Soccer Euro game! Last time my brother Michael was talking about a keeper who he programmed and all. Well, I am going to talk a bit about how I made him, the model, rigging and the animations.
A simple trick to get things easy done, is to mirror stuff: the mesh, the rig and yes, the animation. Why model stuff twice and get it correctly symmetrical if u can copy the stuff of one side?

What I did with the keeper model is, I made one half of his total body and mirrored it. With a simple tool in 3ds Max it welds the two meshes instantly.


Well, after the mesh is done and the unwrap is completed we’re going to start with rigging the model. So we’re going to make the model ready for animation. For rigging a model I use the skin modifier in 3ds Max. I will assign certain vertexes to the bones I want, so if I have a right hand bone I’ll assign all the vertexes of the right hand to this bone. Same for the right arm, legs, etc, etc.
Also for this step I rigged only one half of my model and mirrored it. For this there is a handy tool in 3ds Max skin modifier.


After this we’re going to start to animate the model. I had to make several animations for the keeper: an Idle, dive to the left animation, dive to the right animation, dive high left animation, dive high right animation, etc. Again, I can mirror some animations. Why make different animations for opposite sides? So what I did was: I made the left animation first, after this I needed this animation as well for the right side, but I want it to be exactly the same as my left one. Again I used a mirror tool to mirror my animation. And now my keeper also dived to the right side, similar to the left side animation.


Thats all for now!

Hails,
Eugène

woensdag 4 april 2012

Designing levels


Hello everyone!

The game I wrote about in my last post is making good progress. In fact, it is almost done! Past few weeks I've been working on the levels. By this I mean the placement of the level 'blocks', enemies, pickups and triggers. Also creating specific sky settings and atmospheres per level to make it all a bit more interesting to look at.


The above image is a kind of schematical representation of a piece of level. It shows the environment shape and several boxes. Those boxes are used to bring the game alive.
The big red box is the so called 'Trigger'. This tells the game to run a specific pre defined event. The smaller green boxes are 'Spawners'. Those are positions of where enemies and enemy vehicles can be spawned. The brownish/crate like boxes are used to place pickups, such as new weapons etc. The event which is being triggered by a 'Trigger' tells the game at which spawnpoint it needs to spawn what kind of enemy or enemy vehicle. These events are written in text files.

The hard part of creating all of those levels is the balance. The first set of levels should be easy enough for everyone to get into the game. But at the same time challenging enough to keep even advanced players interested. The last thing we want is players who quit playing because there is a lack of challenge in the beginning.

The same goes for the final set of levels. These are obviously a lot harder to finish than the first ones. It is also important to reward the player for his or her efforts. This is done by giving the player special weapons and pickups at specific moments in the game.

Another sneak preview screenshot:


Make sure to keep in touch with our facebook page for the latest updates!

- Joep