vrijdag 29 oktober 2010

More definite look

Dear readers,

Last week we had a 'tech meeting' for the platform game which means we talk about the technicalities of the game. During this meeting we decide what can or can't be done and how it should more or less be implemented. The game is now starting to have a more definite feeling. As shown here:
 












In the image above there's a lot of textures and objects which are still just a place holder. At the moment some of that art is already coming along nicely (made by Matthew). It's very pleasing for me to see as a programmer how the art is really making the game look great. Unfortunately for you I'm not allowed to show you anything too revealing.


-- Stijn

donderdag 28 oktober 2010

Explosion in action!

If you’ve been reading this blog you should know I’ve been working on the 3D model and animation of a exploding and sinking ship for our “water race game”. Yesterday the head programmer on this project (Pieter) found some time to work on the explosion sequence. Implementing it turned out to be a bit harder than planned. The scene is set up like this, the ship model and debris parts are part of the track scene, the harbor track in this case. I’ve placed seven bomb dummy’s at key positions in the ship model, next I’ve linked unique debris parts to each bomb (i.e. hull debris linked to a bomb placed in the hull, cabin debris parts linked to the cabin etc.). The actual sinking of the ship is animated in a separate file, only the animation transforms need to be exported.  

Now it’s up to Pieter to blow it all up, this is how it works: When bomb trigger is activated, a ingame pickup in this game, the game camera switches to a camera which focuses on the ship, next the exported sinking animation is assigned to the ship model and starts playing. Explosions are spawned at the seven bomb dummies with short intervals, each explosion gives a impulse to the debris parts linked the corresponding bomb which causes the debris to fly around. I can tell you it’s quite spectacular! Check out the screen! 












Matthew

woensdag 27 oktober 2010

Sprites in 3D games

Hello all,

The time management game is making good progress. Richard started to work on the interface animations this week. We are using 3d models to display the interface elements. Some of them need to be animated. Imagine appearing. disappearing or animated icons in general. Such as coins or clocks which need to have some sort of animation. Not only to make it look better, it's also important information for the player to see what is going on. It shows the player the status of an object/item for example.

These animations are done by changing the 3d mesh of a model realtime. Imagine a clock icon playing a 'Ticking' or 'Counting' animation. The image below shows a mockup animation sheet of this icon.













Every so called 'Frame' or 'Sprite' is actually a seperate 3d mesh. These are all flat objects consisting of 2 triangles forming a quad, but have different UV coordinates to display another frame of the animation. The model which is displayed ingame will change it's mesh during the animation. It will switch between resource frames in about 50 milliseconds, so it will look like a 'Ticking' , fully animating, clock.














This technique is often used in 3D games. Smoke, fire and debris particles can be done this way for example. Also explosions can be made using this technique, as seen in burnin rubber 4.

Thanks for reading :)!

--Joep

dinsdag 26 oktober 2010

Regional Heroes

Hi Everyone,

As you might have read from Pieter in yesterday’s post, the Xform office 2.0 is now officially opened! Bear in mind that’s finally official, because we’ve been busy behind the scenes for almost two months. It was ready a while ago, but is now officially open for business now that everyone has collectively spilt some of their beer on our floor. We don’t give it to our dead homies here in Holland, we just spill it on your floor at parties when getting drunk, in honour of the host ofcourse!

More miscellaneous news that I can tell you about is Xforms’ appearance on RTV Utrecht. This is a regional (local) channel here that’s taking a closer look at Utrecht (Utrecht is both capital city of-, and an actual province, same name). They’re not just looking at Utrecht, but at developing businesses worthy of a special mention for students. So it might not be national television, it’s still a nice bit of publicity for the company. Plus, you get to see our (2.0) office and Diederik. Unfortunately, I wasn’t there because I had the flu and Diederik had to do all the dirty work himself. Luckily he knows his own business like no other and he did an excellent job telling everyone about his company!













So, if you’re Dutch or admire the way our throats sound when we spit out our barbaric language, please take a look here: http://www.rtvutrecht.nl/content/rtvgids&dag=1

Click on “Campus Cam” at 18:10 to view the show, our segment starts at 11:40 minutes into the video. I'll have a decent post for you guys again next week :)

Enjoy!

-- Erik

maandag 25 oktober 2010

Blown away...

Hi all,


Another day, another post…
Before I get into all kinds of nagging I want to thank everyone who was at our official opening last Thursday. We had a couple of drinks and a good time, celebrating the Xform 2.0 office. Furthermore, I am proud to say that we have finally got our own Xform theme song!  It has a very 80’s style feel to it. Think about the intro themes for Mask, He-Man, etc. The only thing left we need now is our own cartoon… That would be awesome ;)

Anyways, on to more pressing issues. As you might know we’ve been hard at work on a couple of games. My main responsibility is getting the ‘water-game’ technically up and running. I talked about water before so I won’t touch that subject anymore. At the moment I am doing a lot of ‘boring’ stuff.
Implementing and tweaking the general flow. It is boring to make, but it is extremely important for a good user experience. We have to think about how long loading the game takes, initializing the world, when we should start a countdown sequence, in which order do we show the end results of a challenge. Do we show the game character first celebrating his victory and then show the end results (time , rewards, etc.)? Or do we show him celebrating in the back ground while displaying the result? It all sounds very boring and trivial, and for some things it is, however timing and anticipation can hugely influence the user experience. While typing this I think this might be a great subject for another blogpost, because today I wanted to talk about something else; explosions. I love explosions. I really do. I could look at and talk about them for hours,…


For this game we need more and bigger explosions! IMHO. Matthew told you about destructing the ship a couple of posts ago and this will be my test case for a new and improved explosion system. In our previous games we’ve tweaked and created some cool explosions already, but you haven’t seen anything yet. In Burnin’ Rubber 4 we had to cut our new explosion system, because it was, at that time, too slow. If you look at one of the first trailers of that game you can see some of them in action. I have been working on optimizing that system.  Furthermore, I have added and will add more features ;) The planned shockwave effect will be implemented and I want fire trails for debris. That would look awesome with all the parts exploding. Hopefully, I’ll have some ingame, instead of editor, screenshots for you next week!



Off to explode some more…

-Pieter

vrijdag 22 oktober 2010

Moving platforms

Dear dear readers,

This week I've worked with Joep on fixing bugs in ****. Pretty much all bugs have been fixed, so we're happy about that. One bug in particular was nasty as it happened only in the online version. In the end it turned out to be an old online file which apparently was out of date since a long time ago, but up until this moment it didn't cause any problems.

For the Rhino Rush game, we've had another meeting discussing what should be in the game and how we're going to do it. The... frolicking... ;) game designers thought it would be fun to put in some moving platforms. Easier said then done as is the case in almost every feature they come up with. But it's also a challenge of course.
As we're using physics on the character for collision detection and resolving, the platforms have to be done using physics as well. I started out with a box as a platform and making it move by interpolating the platform's position between its begin- and endpoint. Well... the platform moves but when the player stands on it while the platform moves up, he was hardly able to move due to constant collision resolving by the physics engine. And when the platform went down the player suddenly moved normally again as the platform wasn't constantly placed in the player anymore. Also by bluntly setting positions of objects the physics engine won't know the linear velocity of the object so I'm not surprised this didn't work very well. Anyway it should be clear that this is not the way to do it.

So I turned to my spring constraints, attached 1 spring constraint (a very strong spring with rest length 0) to the platform and another constraint to keep the platform in a set orientation (you don't want the platform to rotate when the player stands on the edge of the platform). Then instead of setting the position of the platform, I set the endposition of the spring and linear interpolate that between the desired begin- and endpositions of the platform. That worked a lot better, but the platforms were a bit wobbly: they would move around when you jump and land on them and when they reached their begin- and endposition. But when I showed it to the game designer he wasn't too pleased with it. Although wobbly platforms can actually work fine a game if you give it an appearance of not being to sturdy. But ok, let's try to get the wobbliness out of the platforms as well.

This required me to use the 6DOF joint. A joint that is very generic and allows you to do many things. As such it comes with a great deal of variables you can set: axisDrive, axisMotion, biNormalDrive, biNormalMotion, driveAngularVelocity, driveLinearVelocity, driveOrientation, drivePosition, globalAnchor, linearLimit, localAnchorA, localAnchorB, localAxisA, localAxisB, localNormalA, localNormalB, normalDrive, normalMotion, swing1Limit, swing1Motion, swing2Limit, swing2Motion, swingDrive, twistDrive, twistLimit, twistMotion. Well, ok that's all fine and dandy, but where's the documentation? Well... there was very little documentation about it. So I just had to experiment a bit with it. And I also found this image, which was also helpful in figuring out variables:
















I mean seeing a variable named swing1Motion, it isn't exactly clear what it's for. But from the image we can see it's actually pitch. And twistMotion is yaw, while swing2Motion is roll. We can prevent changes in pitch, yaw and roll by locking them because we don't want our platform to do any of these movements. There is actually only one kind of movement we want and that's along the local axis (See platform image, where A is platform beginposition and B is platform endposition).

 












So we set our local axis to the direction the platform is moving which is the normalized vector of B - A. Then our normal axis should be set by rotating the local axis 90 degrees on the z-axis. And the binormal axis will be calculated by the physics engine (using a cross product). But we're actually working in the 2D plane and we might as well pick the z-axis to be our normal axis, which is simply (0,0,1), thereby avoiding doing a vector rotation. The result is satisfying: no more wobbliness. Unfortunately I can't show you that in an image, so you'll just have to believe it and verify it when the game is finished :P

Till next time,

-- Stijn

donderdag 21 oktober 2010

BOOM!

 











If you've ever played our games you should have noticed that we like really like explosions, I mean really, really like them! So when we discussed which features the "race game on water" should have we all agreed this game needed explosions, but not like we've done before. The idea is that you as the player create shortcuts by blowing up environment objects which will be unique for each track. For the Harbor track I've created a ship which will blow up, break in half and sink. The rear end of the ship sinks half way into the water creating a huge ramp which the player can use as a shortcut. When the explosion occurs we'll switch to a cinematic camera to give the whole scene a more dramatic effect.




 








At this point I  finished the ships mesh, debris parts and sinking animation, It’s up to Pieter now to dynamically blow the debris parts away and insert the explosion graphics. I'm really curious on how this will turn out in the game, I guess we all have to wait and see...

Matthew

woensdag 20 oktober 2010

Visitors...

Hello all,

I want to talk about the visitor system for the time management game. While playing there will be visitors, or guests, walking around. They will stand on pre defined places or will be moving/walking between them. So it looks like they are visiting/enjoying the park. The game also features so called 'targets' which a visitor is going to visit. They walk into the park, get to the first target. Then look around for a while and move on to the next one. When all targets have been visited by a visitor, the visitor leaves the park.

Technically, this comes with some difficulties. For example, the targets, or 'nodes', can only be owned by one visitor at a time. There can't be more than one visitor standing on a node. This means that if there are more visitors in the game level walking around than there are nodes available, all the visitors will stop moving. Which is not wat we want ofcourse. A visitor should always be able to walk to it's next target.

Therefor we can use some solutions. For example, the most simple one:

A visitor enters the park and visits the target nodes in a linear order. Simply by walking from one to another in a pre defined sequence. When the last target is visited the visitor leaves the park. Also the spawning of visitors is controlled in such way that there are no more visitors being created/spawned than there are target nodes. This way the visiters don't freeze up.

The good thing about this system is that it is very easy to control. And will always work if the amount of targets is kept the same during gameplay. The drawbacks are that it is not very interesting to look at in the first place. Visitors always move the same predictable path, which is not really human like. The system also isn't very dynamic. Imagine adding an extra 'target' while the visitors are in the park. This would cause problems.

The method we are going to use for now is this:

As you can see, we added so called 'Free Nodes'. They almost act the same as the 'Target Nodes', except that there will be far more free nodes. In the image there are only 4 displayed, but we'll be using a lot more in the game.

Using this system, a visitor walks into the park and always moves to a free node. When reached, the visitor is looking for a target node which isn't owned by another visitor yet. Then the visitor walks to this target and makes it it's property. When the visitor is done watching/looking it searches for the next (random) available target node which it hasn't visited yet. If it finds one, the visitor moves towards it and the same sequence is repeated. If the visitor is unable to find an available target node, it moves back to an available free node. Which is, in theory, always available if there aren't too many guests.

This way the system is more flexible and gives a lot more control over the behaviour of the visitors. Also adding a target node while the game is playing wouldn't be an issue here. The only drawback is that there can't be more visitors in the park than there are free nodes. I'm also thinking of creating the free nodes on the fly if a new visitor is entering the park. This doesn't work yet, but seems to be the solution to these last issues.

Thanks for reading, more updates soon!

-- Joep

dinsdag 19 oktober 2010

Power outage/ Office management madness

Yes, I like alliterations in the titles of my blog, it just adds that ‘pulp fiction’ vibe. You know like the old comics and newspaper headlines: “Super Shopping Shocks Nation… “ and so on. 

More to the point; because the others on this blog will inform you about the technical feats they can achieve in game creation, I’ll keep you updated on what happens in the sometimes boring, yet never exciting, world of managing stuff… It isn’t all bad however, so don’t worry. I’ll have tales of epic frustration for you.. I’ll let you know what happens in between the game creation stuff.

So, last week we had a small “borrel” which is Dutch for serving drinks and potato chips for a few guests, basically. This was in honour of our new location being finally completed as a (workable, less mice-infested) new office. We’ll have a second “borrel” this Thursday, so we can accommodate absolutely everybody that wants to drink with us in celebration. If you’re reading this and feel left out somehow, please let me know by sending me an email.

What we’ve been facing in the office is the continuing threat of decay. After the rotting interior and mice, last week our power supply went crazy. When trying to switch our power cables to the sockets on the ceiling instead of the wall based sockets, our whole office blacked out. In our never ending struggle for existence, we managed to get everything plugged in again and working. Today the wiring has actually been properly fixed! We can now use all sockets again and suffer less from the static electricity we used to feel in the office when we touched metal and random shocks while walking around.

Another big thing is my month long struggle to get the a new connection of our interwebz working @Xform. My discussions with the helpdesk people of the service provider had already heated up as I shouted minute long rants at the guy who was telling me that: “Hey, I don’t think we ever received your order at all” After months filled with weekly frustrated calls. Well, they still haven’t delivered anything useable, it’s insane the way these people treat their clients.

More (on-topic) blogs coming in the following weeks, stay tuned!

-- Erik

maandag 18 oktober 2010

The importance of mockup material

Hi all,

Below you see two mockup images of the level for our time management game. The top image is a level I created for some technical tests. It gives an impression of the size of the level and there are some objects to click on. It was good enough to do some initial gameplay and technical tests (i.e. how fast the character should run, how complex the pathfinding should be, how this layout would work for the resolution we want to use).




















After this, I started work on the next mockup level. We changed all layout stuff that didn't work that great. Note that the entrance has moved to the left lower corner of the screen, this works better with the widescreen resolution of 800 x 450 we're going to use. As you can see, we've also simplified the routes for the pathfinding. We've left some space in the top corners for interface elements. The animals and other objects have been scaled out of proportion to make them stick out better. Color, lighting and textures have been added to give a proper impression of depth, scale and speed. This is also done to test if all important elements will stand out once we start adding more 2D stuff. This level is good enough to work with while the programmers are adding in more functionality.

From this, we're now creating a proper model and texture plan to start finalizing the art for the background. Splitting the creation up in two or three steps helps determine level design problems early on, allows programmers to work with proper placeholders and prevents lots of fine art ending in the bin.

-- Diederik

vrijdag 15 oktober 2010

Particle systems, Physics, Coins, ...

Dear readers,

This week I've been busy with particle systems, coins, experimenting with physics, interface, game flow and more.

I've added some particle systems to make the game look nicer. Pieter already has standard code for particle systems so it's very easy for me to spawn them. Furthermore, I added collectible coins which can also appear when destroying boxes.

I'm also playing around with physics a bit. Making a trampoline using springs. And a bridge, also using springs. Springs are awesome! I think Pieter will agree (he used one in his game as well). It definitely looks cool in action and will be even cooler with proper art, but as I said it's just playing around so it's not certain it will be in the game.

Here are some pictures of my recent efforts:















-- Stijn

donderdag 14 oktober 2010

From Concept to model

Hi Guys,

As you might have read I've been off the water race game to do some work on our new time management game. For this game we're aiming for a happy, cartoony and colorful look. Concept artist Verena Gefferie made the initial character design, next Pieter made a relatively low poly model based on her design, here's where I come in to Unwrap and texture it.

Unwrapping characters can be a real chore, luckily max Unwrap UVW modifier has a function called Pelt Mapping. With pelt mapping you predefine all the "cuts" you need to unwrap the model by drawing lines along the models edges, much like you would make cuts in a cardboard box to flatten it but keep it into one piece. Next you press the pelt button, start the pelt, throw in a relax or two and you model is unwrapped and ready for texturing.

For this model I've used a 1024x1024 texture which in the end will be downscaled to 512x512. We won’t be using real time shading in the game but instead I've drawn the "cartoon shading" into the texture. Each color has 3 shades, one for the default color, one for the shadows and one for the highlights.

















Cheers, Matt

Almost alpha time!

The alpha version of the 'time-management-game' is nearing completion. All the basic mechanics are working and the game is playable in it's basic form.




















We currently have some headaches about a system which manages the so called 'visitors' in the game. It is a lot more complicated than I expected. I thought that the pathfinding system would cause far more problems for example. The last things to do for the alpha are getting some new models and textures in the game and making the 'visitor' system work without major bugs.

-- Joep


dinsdag 12 oktober 2010

Social Media Momentum

So, if you’re paying attention to how we’re developing Xform as a company, you might have noticed that we have become a lot more active on social media lately. Not only can we be found on all social media platforms now, we’re also blogging like crazy. A genuine development blog that gets updated every single workday is nothing to sneeze at…

That’s probably also the reason why we’re now listed as a new development blog on the leading site for the Dutch games industry: Control Online. You should definitely check that site out if you’re interested in working in the videogame industry, it can be a really helpful site for general industry info, but also for finding your (dream)job in the industry.

On to social media, that sticky web of self-made importance and “Liking stuff” (just scroll down to “Like” this by the way) in general. It’s becoming more mainstream to be on facebook and it’s pretty much normal if you twitter all day. I do think these media can be used to market or support your brand, but you should use the media to their best abilities and only use what suits your purpose best. Don’t keep on annoying everybody with endless posts about you and an emphasis on what you want to sell to others. Instead, focus on doing what you enjoy to do first and post about it a little more in depth later. If you’re offering something valuable, first of all, to yourself and your business, others should be able to appreciate its value in some way too. If they don’t, then what you’re doing probably sucks. Something that is very important to consider when marketing yourself and your goods in the future.

What we’re offering is this cool development blog, breaking news on our twitter feed and a nice facebook page, full of stuff to like and more to come. We’re committed to this blog and I hope you find it all interesting, don’t hesitate to let me know how you feel, you can always contact me with suggestions. We want to keep our momentum and gather as much fans as we’re growing!

-- Erik

maandag 11 oktober 2010

Still thirsty...?

Second blog post! And again I am going to talk about water!

My previous post I talked about the vehicle behavior for our new game. I got it almost up and running. Although I still need to tweak and enhance a couple of things, but I am fairly happy with it. We’ve also got some animated water in it. It flows and has a sin wave deforming the 3d model. I think it looks nice, although Director still doesn’t support any fancy features like render to texture or shaders. The 3d engine is almost 10 years old and we have to work with the features available. So we throw everything over the CPU and hope we still have some left for the rest of the game :S Nevertheless, I hope you can see all effects and play it for yourself as soon as possible.

For now I wanted to talk about some other water effect: rain! Which is cool! I like making special effects! Don’t get me started about particles and the likes as I can talk about and tweak them for days. A nice side effect is that I can avoid talking about mathematical stuff in my games. I suck at math, so I’ll leave that for Stijn ;)

If you take a look at our previous games you see that most (if not all) have a very sunny and bright setting. Most of the artists here prefer it that way. I think it has something to do with the Dutch weather… Sometimes though, we do need a visual weather effect like snow or rain. Until now we mostly got away with it, by completely ignoring it and tweak the colors, lights and fog settings of our 3d world. We never got around to actually build and implement a visual rain effect. This bothered me a bit and for this game I scheduled time to actually build and implement a system that could handle this (and snow). Normally when I build these kind of systems I make sure they are modular and can be implemented in all of our games.

After some research I decided to make a system that would display a rain effect in 2d. It is a bit of a shame, I know, but I had to do this because Director simply isn’t fast enough. Ideally I would want to use some readymade particle systems (either my own system or Directors built in ones), but they simple aren’t flexible or fast enough. Placing billboarding sprites in the 3d world with an animated textures wasn’t a real option either as I think it will cost too much time for an artist to place all sprites. Creating a system that would automatically place rain sprites in the world could be possible (there are a number of solutions for this), but I didn’t opt for this as it would simply be not fast enough as well. Director doesn’t do batch rendering (combing models with the same shader to be processed as one) and, furthermore, needs to send all mesh data of the 3d models to the GPU each frame. We’re losing quite some CPU power here, so I had to think of something else.

5 Rain layers in front of the camera.
I ended up displaying a large plane in front of the camera with a tile-able texture of rain. Each frame I would ‘scroll’ the texture. This already looks okay. However, because it is 2d and displayed on top of the 3d world I needed to think of something that would actually add more depth and looks like the rain is ‘in ‘ the world. I cloned the plane a couple of times a placed them further away from the camera. This created a denser rain and much more depth at the same time. Furthermore, I linked the rotation and banking of the vehicle to these planes. So when the vehicle moves forward the rain rotates towards the camera. Creating the effect of rain coming towards you. When turning the vehicle we turn the planes as well which makes it even more look like the rain is actually inside the 3d world. The effect looks very decent. Even though I display the rain in ways nature never could as it simply just looks better. The only thing I want to do, if time and schedule permits me, is think of a way the camera can actually move ’through’ the rain. Perhaps I can clone the exact same set of models again and move the camera through the first set, based upon speed of the vehicle and reset it when the camera has reached the boundary of the first set. I think some testing would quickly show it this could
work…


Rain effect in action!

















The last thing I normally do when I design and build system like these is add a sh*tload of parameters and settings. I think it is important to have a very flexible system so I can display all kinds of rain setups. However, I simply don’t have the time (or want to) create all kinds of setups myself. With all these settings the artists or (level)designers can create almost all types of rain or snow they want.

Until next time…

- Pieter

vrijdag 8 oktober 2010

Hooray for physics and mathematics

To my dearest readers,

Unfortunately I've been mostly ill this week, but that doesn't mean I don't think about how to solve certain issues at work. For example I'm now adding slopes to the platform game I'm working on. One of the problems here is that when the character reaches a slope he speeds down and slides back. The desired behaviour however is that he moves on slopes just like he moves on the ground. Now as I've been asked to write a little bit more technical, I will be going into more details and describe to you how to solve this problem using high school physics (who knew it would actually come in handy one day?).


So consider the image below. Point S is the center of our character to which the force of gravity Fg is applied. Now to understand why we slow down and slide off the slope we change our frame of reference to that of the slope so that Fg is split up in two forces: force Fy which is perpendicular to the slope and force Fx which is parallel to the slope. So now we see why we slow down and slide back: force Fx pushes us off the slope. So to solve the problem we must apply a force Fc which is equal to Fx but exactly in the opposite direction so that it cancels force Fx. Note that we do not want to cancel force Fy since that's what will keep us on the slope.












So how do we find force Fx? This is where a lovely sine will help us out. For any triangle with a right angle (90 degrees) we can use that sin(angle) = length of opposite side / length of hypotenuse (see image). We can use this to find force Fx. Consider triangle (S, Fx, Fg) (yes, I'm abusing notation since Fx and Fg are vectors not points, but you get the point. No pun intended.), we apply our equation and get: sin(a) = d(S, Fx) / d(S, Fg) where function d returns the distance between two points. Remembering that Fx and Fg are actually vectors with origin S this simplifies to sin(a) = Fx / Fg. To find Fx we multiply the left and right hand side of the equation by Fg and get Fx = Fg * sin(a). Now we know Fg, but we don't yet know angle a.
 
 
 










To find angle a look at the image again. We will now find another triangle which is similar (has the same angles) to triangle (S, Fx, Fg), namely triangle (T, Fg, S). First notice that angle(S, Fx, Fg) (this is the angle defined at Fx, just like angle a can be described by angle(Fx, Fg, S)) is a right (90 degree) angle by construction because Fx is perpendicular to Fy. Then notice that angle(T, Fg, S) is also a right angle: the force of gravity is perpendicular to flat ground. Next we see that Angle(Fg, S, Fx) is the same as angle(Fg, S, T) because T is on the line defined by S and Fx. For any triangle we have that the sum of its angles is 180. So for triangle (S, Fx, Fg) we have that 90 + a + angle(Fg, s, Fx) = 180 and for triangle (T, Fg, S) we have that 90 + angle(Fg, S, Fx) + b = 180. From this we derive that a = b. And angle b is simply the angle of the slope.

So the force Fc we are looking for is now given by: Fc = -Fg * sin(angle of slope)
We apply force Fc whenever the force of gravity is applied and slopes will now be like walking on flat ground. This will work nicely until the designers of the game decide they also want slopes which the character cannot climb (they're evil like that), but that's a problem for another time.

Thanks for reading. I'm jumping back into bed and hope I'll be better tomorrow.

-- Stijn



donderdag 7 oktober 2010

Working his ass off…

Who is? Matt is! That’s why I’m writing this blog. To literally save his ass, if you will :) Seriously though, he’s really busy…
















At the moment he’s working on finishing some of the models Joep was making yesterday. As you could see on Wednesday Joep was busy modelling some nice animals. Could you guys guess yesterday’s model? It could be anything ranging from Penguins to some alien lifeforms I guess (I’m never quite sure here). It’s Matt’s job to cover these models with the cool art he makes. This art in turn is based on the (final) concept art. Once the models are covered with the proper textures he tweaks them to fit the world perfectly. This gives the models their character and makes them real, useable assets to use in the upcoming versions of the game. 

On top of that he will need to start working on posters. We’ll be having a small party/reception type of thing (“borrel”) soon to celebrate the official opening of our new office. For this event we want to have some of our own art (from Xform games) in cool poster size frames. Mainly to show off to the people that are coming ofcourse, but also because we don’t really have any of our own game art in the office. Up until now, posters of Sam&Max, Monkey Island and even more Monkey Island graced our office. Now it’s time to put up Xforms’ own accomplishments on the wall!

On top of all that he actually needs to be working on the racing game that takes place on the water, the one he told you about in the last weeks. His work on the Time Management Game is needed now, but the aquatic racing game is the first priority, so once the assets are done, he’ll need to get right back to work on that.

So, Matt will be updating his blog next week. I hope that he can mention something about the things he’s doing at this moment, especially “(un)wrapping” textures and the like, in his coming posts.

-- Erik

woensdag 6 oktober 2010

Back to 3D for a day




















The first version, or 'alpha' version of a project needs to have basic gameplay functionality and basic or 'Mockup' graphics. For the time-management-game (TMG) we want to push the mockup graphics a bit more towards final graphics. Currently the TMG's graphics consists out of boxes and other primitive shapes. Which was good to, for example, develop the pathfinding system with. But when making the gameplay more advanced it is nice to have some more final art. Today I worked on some character models. They won't be animated for example in the alpha version. But the important thing for us is to see the scale and sizes of all objects together in the scene. This makes things much easier to work on when creating the game. Later this week I'm going to make some environmental assets, to fill up the scene.

We also started using a new task/project management system as Erik posted below. I have to say that it works very good, much better than I expected and much better than our old 'trac'.

--Joep


dinsdag 5 oktober 2010

Managing our new management system

Managing stuff in general is a hassle, managing a bunch of crazy developers here at Xform can be a real chore. I’ve been looking around for weeks to find the best program to manage our workflow, but most of the programs out there complicate matters even more. Managing your project management software is not only one of the most boring tasks imaginable, it can also add an extra layer of confusion to projects that could have been avoided using simply your common sense. Just like you would without the program to confuse the hell out of your natural instincts. However, there’s also a point where you really need a program to keep the overview clear for everyone involved.

That’s why we now have a cool new program to help us manage our tasks and it’s actually quite simple. In the past open source bugtracking program Trac was the method that was used at Xform. This proved to be a bit too open source and too hardcore even for the very technically oriented people here. At some point it’s not practical to focus on that software anymore and you simply need a service that enables you to do your work.

There’s something cool about open source software, because it’s free and yet works in real life, but it’s at its best when you have a lot of spare time to mess around with the code. There’s no time to do that anymore, we need to focus on making games and I need to make everybody’s worklife here easier. We’re using Intervals now, a very basic program that tosses all MS project lookalike interfaces overboard. It’s very simple and effective, now let’s put it to good use and let’s make some more, properly managed games! For you!

-- Erik  

maandag 4 oktober 2010

First, we need a huge free roaming world...!



Hi all,

Today I wanted to write something about how a lot of game design flaws begin: Designing the wrong way round. Here's an example (looking at our time management game):

Wrong:
We have a cheerful animated player character with lots of moves and actions. We need controls for all these moves and actions in the interface! We've also created this super cool, huge 3D environment and we need to show this off. So, the least we should have is a camera that follows the player around. Ok, that's done. Now let's add loads of other characters, AI, effects and other content! By the way, does anyone know what kind of game it should be?

Proper:
We're making a time management game. Gameplay is clicking on stuff as it appears, overloading the player. The fun in the game is cleaning up the mess! Player needs overview of everything that can be clicked on. So, we need a small, one screen environment. This would mean that a static camera will probably suffice, for now at least.The game needs to be very responsive. The player's click should be rewarded instantly for everything he does. Do we even need a player character walking around, causing all sorts of delays and programming mayhem?

The above seems obvious. However, I've seen so many development teams start off the wrong way. First, they come up with loads of cool features and ideas. Are these ideas relevant to the core of the game, or could they be added later on? They look at successful games that they themselves like to play. But they forget to analyze why it works well in that game and if it could work the same way for their game. The most important thing when you're starting of with a new game design is getting clear what you want to make (sort of, anyway!) before doing anything! And, of course, coming up with decent priorities. Creating cool water shaders is never high priority. Creating a decent end to your game is!

As for our time-management game: Our solution for now is that we'll test the clicking to navigate first. If this doesn't work and proves non-gratifying, we really should consider removing the player character altogether (oh no!).

-- Diederik


vrijdag 1 oktober 2010

Tiling Textures...


Hi There,

As you've might have guessed right now we're currently working on a racing game that takes place on the water. The past week I've been working hard on my remaining tracks which I'll preview to you in later posts.

When designing the tracks I have to keep in mind that they're for a browser based game so I can't go crazy on the texture file size and push the performance (although I'm known for pushing it anyway). Each track has a set of five predefined textures, namely:

  • a tiling texture for flat water which we'll use for seas and lakes
  • a vertical tiling texture for streaming water which will be used for rivers and waterfalls etc.
  • a horizontal tiling texture for the skybox
  • a small texture for additive effects like sunrays and lights
  • and finally one big texture for all the track assets, which can be seen in the screenshot below




















For this project I've created mock-ups of the textures before actually building the 3D mesh, this way I know what my texture limitations and lay-outs are. The next step is creating the 3D track mesh with the textures kept in mind, more on this in my next blog post.

Cheers, Matt

Butt-slam Bonanza!

Hello readers,

I've continued my work on the platform game and added functionality such as a new action 'butt-slam' that allows you to destroy boxes from above (see image). All textures are just place holders and will be changed as soon as the artists get to work on it. I've also added an enemy to the game, you can see him (his butt) on the right in the image. Enemies have to be flexible so level designers can place them pretty much anywhere in the level and the enemies will find out where they can walk and where they can't.















My next task is to add slopes and a sort of shield to the game, so I'll be working on that from now.

Till next time,

-- Stijn

Pink cakes in the morning

The time management project is getting on nicely. The pathfinding is pretty much done for now, some minor glitches when moving small distances ( less than 1 tile in distance).This week I got help from Richard. He recently joined the team as programmer intern. I've been busy getting him started with our tools and engine this week. Also some new systems, but I'll blog about that next week.










Also Diederik gave us some 'pink - cakes' today.. which was not for nothing. We are all a bit behind with our blog posts. We should each have at least one blog update post per week. He tries to get us to make our posts, which worked pretty good with rewarding some cakes. Everyone is blogging right now, haha. You'll probably get to see more than one blog post update today.

Back to work, lots of things to do!

-- Joep