Monday, April 11, 2011

GameMaker 8.1

GameMaker 8.1 will be released very soon, so I thought I'd talk about some of the major changes and what this means for both Lite and Standard users. First, naming; Game Maker has become GameMaker, while Pro has become Standard. Simply put, we think Game Maker feels like a description, while GameMaker is more like a product. It should also help focus searching in the future.

So... onto more interesting things - new features! The first big thing is the room editor's new ZOOM and PAN features. This helps bring the room editor more into what a modern editor should be, and it feels so much better, so much so, that swapping back to 8.0 is now a nightmare! What I find is that I now move around the level by zooming out from one spot, and zooming back into another. It quickly becomes a natural part of your workflow - as it should. There are 29 levels of zoom (14 up, 14 down) allowing you to zoom right in, or right out to see the whole level. This helps when using small sized tiles, just as being able to zoom right out helps you visualise an entire level.
This improvement in workflow is also the same for panning. Using the middle button to pan around instead of clunky scroll bars, again makes life much easier. To me, these two features are the MUST HAVE things in 8.1, and I'd recommend everyone try it before deciding not to upgrade - it's that important.
Initially the zoom wasn't going to be available in Lite, but we've since decided to add it; more on this later.
We've also updated the image editor to use the controls, while adding PAN to the path editor allowing much smoother workflow there as well.

The code editor has received a little love as well. I've increased the drawing speed in the code editor so large scripts should be quicker to edit. I've also added a couple of common requests. First, you can now select a block and use TAB to block indent, and Shift-TAB to unindent.
Another often requested feature was to add CTRL-F for searching, as it's such a common key in windows that not having it really breaks usability. So this has also been added.
We've also added the ability to cancel the codesense allowing a better smoother coding experience.

We have also improved 3d a little. Turns out hardware T&L wasn't enabled, so we've turned that on, but what does that mean? Well, modern graphics cards offload all transform and lighting calculations to the GPU, but if your using software T&L then the CPU does it all. This will give a little speed boost, although due to the way things are built in GameMaker, not as much as it should. There is a further update which should give a big boost, and one we've done in the C++ runner. This will come in future updates, but for now the hardware T&L will give a visible boost. We've also increased the ZBuffer from 16bit, to 24bit. This means there will be less artifacts as things intersect, and better depth control when things get very close to each other. So this should be great update for anyone using 3D, with better to come.
I've also added a new command for Standard Edition users, which allows them to control the ambient light level and colour. This again, should be a massive change for 3D users as it removes the jet-black background light level, into whatever you want! At the very least it means you'll be able to raise the darkness to you can always see something in the darkness.

We've also added a few new general commands.
dot_product(x1,y1, x2,y2)
dot_product_3d(x1,y1,z1, x2,y2,z2)
point_distance_3d(x1,y1,z1, x2,y2,z2)
These are common commands, so by putting them into native code, we give a speed boost to anyone using them. If you don't know what a dot product is, it's a very handy little thing that gives you the Cos of an angle between two vectors. The simplest use is for lighting, but since it effectively returns the angle between 2 vectors, it's very handy indeed; and now it's much quicker to use.

The last BIG thing is totally rewritten FONT generation. We haven't as yet rewritten the rendering (so it's actually still a bit slow), but we have rewritten the generation of fonts. This now gives much nicer, and smoother fonts, while at the same time fixing the horrible cropping some fonts used to get!
I've also updated the Font dialog, allowing you to type your own text in, and pick the language character set to aid multi-language support. Multi-language isn't yet complete, and is still bugged, but it will be fixed in a future update. You can see the new dialog

The all new Font Dialog You can now choose the charset, and t... on Twitpic


So...I said last big thing... but that's not true. The last BIG thing, is the auto-update system. This is huge as it finally lets us do small, quick updates, and to fix bugs that are stopping developers make the games they want. In the past, doing and update was horrible, but now, we simply release it into the web and everyone finds out about it and can download it. I hope this will make life easier for everyone!

So while there's a few other things in there - like full script searching, these are the biggies for Standard users, so what about Lite?

Well, first off you do get some of the new features (like the font update), but some are held back for standard users only (like script searching), and yes, there is a new TV style logo in the Lite edition, and there is an ad for GameMaker on exit. Upgrading to Standard removes these additions.

However, since we're adding further restrictions, we've also decided to "give something back". So, we have enabled ZOOM in the room editor (which is actually a biggie), and have also taken the decision to allow access to draw_sprite_ext(), which allows you to specify an angle, and an alpha value. This is another BIG change, as you will no longer will you have to pre-rotate all your graphics. This saves effort, and reduces the size of your games significantly.

So, along with a heap of bug fixes, we hope there's enough in here that makes everyone want to upgrade.

Thursday, April 7, 2011

Call for assistance

So I just awoke to what can only be described as manic giggling and intense keyboard mashing. First thinking it was hallucinations caused by recent days' fumes I ignored it. But it would not go away and I finally went up to investigate. What I found was that my desk was spattered with fresh blood and mucus, something I spent the last minutes cleaning up with high pressure hose (we installed one after the "Sottoth-incident").

Anyhow, this can only mean that one of the old specimens, subject H, has escaped once again. How he did manage to pick the lock without any fingers boggles the mind. I guess he always did have dexterous feet though. Once we catch him there will no more of that though.

In any case, if anybody spots strange messages on the forum or whatnot, please ignore them and just report back to me or anyone at FG. I assure you anything that subject H says is all just a mad animal's ramblings. Nothing to take any note of. Would be great if you all could help me catch the bugger.

Oh, well time for placing some bear traps I guess!


PS: Good news from Razer, looks like the problems are fixed now. To all those that have reported missing limbs: we are working on finding (somewhat) fresh replacements!


PSS: What in god's name is that in my shoes!!!

Friday, March 25, 2011

Some Industry Reflections

One thing I have been thinking about recently, is the direction in which the indie game scene seems to be heading. This is something that can be seen in upcoming of games, various talks, articles and what is considered the largest recent successes. It is a direction that might have large consequences for the future of the medium.

Quickly summed up, there is a strong design trend of making games by iterating and extending a fun core gameplay mechanic. This is then incorporated to a game with heavy emphasis on re-playability and/or ease to make levels. The main perks of this approach being that the game becomes more fun to create (as you can have fun at a very early stage), it makes it easier to home in on a "fun" core and allows for an early beta to be released (thus allowing feedback and income to trickle in before completion). This is of course a rough outline of the trend, but I still think it represent the main gist of where the industry of indie game development is heading.

Designing a game like this is of course perfectly fine. It makes sense financially and personally. By having a game where the fun comes in at a very early stage, it is much easier to discard bad ideas and figure out the best way to do things. Getting some kind of income before completion can be crucial for a start-up company, which is much easier when having an early playable version. Betas/alphas also help building a community and spreading the word. On the personal side, motivation comes a lot easier when almost every added feature add something to the gameplay and change is easily tracked. This can make up for other not so motivational aspects of being an indie (low income, non-existing security, bad working conditions, and so on and so forth). Summed up, making games like this make a lot of sense and it is not strange that it is a wide-spread trend.

However, what troubles me is that this kind of development is seen by most as THE way to design a game. While of course many great videos games can (and have!) come out of this manner of creation, it is not the only way to go about. I believe that doing games this way makes it impossible to do certain type of video games and to expand the medium in a way that I personally think is the most exciting. Because of the focus on instant gratification, gameplay will pull towards a local maximum and only take short term value into account. This disqualifies videogames that focus on more holistic experiences or has a non-trivial pay off (for instance, lowlevel gameplay that only becomes engaging in a certain higher-level context).

As an example of this, after finalizing the basic mechanics, it took six months before Amnesia: The Dark Descent became a somewhat engaging experience. Note that this time was not spend on perfecting the mechanics but on building the world in which they existed. Without the proper context, Amnesia's core mechanics are quite boring and it took additional layers, such as the sound-scape, high fidelity graphics, etc, to bring it home. With this I am not saying that Amnesia is the way forward for the medium. I am simply saying that a videogame like Amnesia could not have been made using the type of development that a large chunk of the indie scene (and mainstream for that matter too) is currently advocating!

Another thing that has also struck me is how many people that are interested in videogames with experiences not solely focused on a fun core. For example at GDC, we met many people, from many different places in the industry, saying how much they liked the game because of its non-gamey aspects. Also, most of the random people that we "dragged" in to the booth were very interested in this kind of experience and often surprised that videogames like Amnesia even existed. We have also seen this kind of response across the Internet, with many people wishing there were more games focusing on these aspects. Again, I am not saying that this means Amnesia is some candle bearer into the future. What I am saying is that there was an overwhelmingly positive attitude towards the kind of games where a fun core mechanic was not the focus.

However, because the current trend of developing games, this potential market will most likely go without many games.

A positive consequence of this is that it creates a potentially very profitable niche with almost no competition. So while the preferred way of making games might be more secure, these projects will be launched in an extremely competitive environment. I think this evens out some (all?) of the risks involved in a development not focused on quickly iterating fun mechanics.

A negative, possible devastating, consequence is that the lack of these kinds of video games might remove the market altogether (or at least limit it to a very niche one). What I mean here is that if the general population's view on view games is that they are just about "cheap thrills", people will never bother looking for anything else. Thus most people who would have been interested in more holistic video games, will never be exposed to them. In a worst case scenario, this would mean that these kind of game will pretty much be stopped being made.

I consider this is something worth thinking about and believe the critical cross road will come very soon. The video games we decide to make today, will shape the future for quite some time.



End note: For those wonder what other ways of designing games there might exist, check this post as a starter.

Friday, March 18, 2011

Birth of Monster. Part 2.

(Not read part 1? Do so here.)

Molding the Abomination
by Olof Strand (www.OlofStrand.com)

As a modeler the first thing I noted about this character was that the concept design demanded it to be completely unique in all of its parts. Usually it is possible to mirror some parts (e.g. an arm, a leg or some cloth piece) to save texture space and maybe some production time when modeling game characters. Not so this time.

The character was based on a human body type with various deformities and modifications done to it. This meant that I could easily use a regular human base mesh as a starting point. Using already existing meshes as a starting point is, when possible, very important for production efficiency.

Another thing that needed to be taken into consideration was how the character would be rigged for animation later on. In this case the rig would be shared with another character from the game and therefore needed to be built under certain specifications (joints in specific places, etc).

The basic mesh created before importing into Zbrush. (Click to enlarge.)


When the the base modeling was done, the mesh was taken into Zbrush for a sculpting pass. The purpose of the sculpting pass is to create details that can be projected on to the final in-game mesh to make it look more detailed than it really is. Since the proportions and general shape where already defined on the base-mesh these should not be changed too much and mostly only minor details were added.

All the separate parts of the base-mesh where imported into Zbrush as separate sub-tools. This made it easy to hide, show and mask parts off. It was also possible to assign different materials to the separate parts as a visual aid. In Zbrush the mesh was subdivided several times giving me more polygons to work with. Once there was enough polygons, new details and shapes could be added by pulling, pushing and using other various tools, almost as if it was a piece of clay.


The different subdivision levels in z-brush. (Click to enlarge.)


When the sculpting was done the lowest subdivision level was exported in obj-format to use as a starting point for the final low-polygon in-game mesh. The reason to make a new low polygon mesh and not use the mesh from sculpting is to optimize the number of polygons in the final mesh. This can be very important for performance when added in the game. The mesh used as a base when sculpting has a a relatively uniform tessellation (distribution and a size of polygons) and mostly a quad layout of the geometry (meaning that most polygons are four sided). The in-game mesh then had to be modified to only have geometry where it was needed. By doing this, more details could be added where really needed without decreasing any performance of the final mesh. This process is sometimes called retopologizing and can be done several different ways. Some people like to use the specialized retopologizing tools within Zbrush, but I personally like to use the regular modeling tools in my 3d software.

The final version of the low polygon mesh. (Click to enlarge.)


When the modeling was done it was time to create the uv-map. A uv-map is basically a way to show where parts of model belong on a flat surface, the texture. This is called a projection, and in this case a 3D to 2D one (the model is in 3D and the texture 2D). Unless the 3D object is a very simple one (like cube or plane) this is a very tricky operation and it is almost impossible to maintain the same ratios as on the model. A good example of this is to look at the various ways our planet earth (a 3D object) has turned into maps (a 2D surface) and all of the distortions and/or strange layouts that follow.

There are some conventions that should be followed when laying out this uv-map. The most important is probably to make sure to put seams (places where polygons split up during the 3d to 2d projection) in places where they are not very visible. This since it is often very hard to match up colors of pieces not next to one another on the texture. Seams can also mess up shading when using normal maps. On a humanoid character a good place to put them could be on the inside of the arms and legs for example. This character also have some irregular areas that have to be given some extra thought. For example the head had an unusual shape making the uv-mapping extra tricky. Once the placement of seams in the uv-map have been established the chunks where laid out to maximize the use of the texture space.

The uv-map layout. (Click to enlarge.)


Before starting the actual texturing work I generated colors for some of the texture maps from information in the high poly mesh. The textures produced this way were the normal map and an ambient occlusion (AO) map. The normal map gives the mesh some extra detail and makes it seem like it is made up from more polygons than it really is. The AO map was to be blended into the diffuse (the base color) texture to give a greater sense of detail and form. Basically, AO is a calculation of how much light reach each point on the mesh, making creases darker and pointy details brighter.

The diffuse map represent the base color of the character and was created in Photoshop by using a mix of various photos, custom Photoshop brushes and the previously mentioned AO map. The diffuse map was extra important as it was also used as a base for creating some other maps like the specular and gloss map. These two are black and white maps that control how light will affect the model. Specular determines the strength of shininess on an areas and gloss how sharp the shininess is. Some of the detail in the diffuse was also used to add extra details in the normal map, like wrinkles and scars.

The final normal, diffuse, specular and gloss maps. Notice that all use the uv-map layout as base. (Click to enlarge.)


Once the texture was completed, the model was ready to be used in-game!

Renderings of final model using different setups of texture maps. (Click to enlarge.)


It's Alive!
By Thomas Grip (Frictional Games)

Before the model could be used in game, some other things was required. First the model needed to be rigged and skinned, a process where the mesh is connected to a skeleton. This skeleton then need to get animations and not until that was done where we able to get a it into the game. This job was made in part internally and partly by an external company. There were a lot of job put into this, but is unfortunately outside of the scope of the article. To some sum things up: we got the creature moving and it was now time to put inside the game.

For Amnesia: The Dark Descent we use a proprietary engine called HPL2 which is a vastly improved and revised version of the engine that powered the Penumbra games (although quite old now as we are developing version 3 of the engine for our upcoming game). It uses a rendering algorithm called deferred shading at its core, a technique that is very useful when rendering lots of lights. It works by drawing out the the normals, depth, specular and diffuse colors to separate buffers and then use these to calculate the final color of a light. Normally when drawing a light, all models that intersect with the light needs to be found and then redrawn based on the light's properties. The nice thing about deferred shading is that models are only need to be drawn once, saving tons of rendering time and allowing more predictable frame rate.

Amnesia: The Dark Descent can be a quite dark game in places, sometimes making it hard to see enemies properly. To remedy this we added a rim lighting algorithm that made the creature's outline light up when in dark areas. This proved extremely moody and when walking in dark passages the player could suddenly get a glimpse of disturbing silhouette slouching off in the distant. After this final touch, our creature was ready to frighten unknowing players!

In-game screenshot showing of the rim-lighting on the creature. (Click to enlarge.)


Hopefully this article will give you some insight into the work that it took to create an enemy for our game. It was quite a long process and took several months from idea to finished asset but we think the final result is well worth it!

An in-game screenshot of the final rigged model in a scene. (Click to enlarge.)

Thursday, March 17, 2011

Birth of a Monster. Part 1.

(The following was supposed to be an article in a Russian magazine, but was never published. So because of that, I decided to post it on the blog instead. It was written in June 2010 by myself, Jonas Steinick Berlin and Olof Strand. Jonas and Olof were working as contractors for Frictional Games at the time. )



Creating Unspeakable Guidelines
by Thomas Grip (Frictional Games)

The following article outlines the process of creating a creature model from scratch for our first person horror game Amnesia: The Dark Descent. It will go through the basic thinking that went into the design of the enemy, how the concept images where made, how the mesh was built and finally how it was put into the game. For this work we used two extremely talented external artists and they have themselves outlined how their horrific creations came about below and it a future part. Before moving on to their work though, I will detail the thinking that went into the basic design of the creature.

When creating a horror game, making sure that the antagonistic creatures are properly designed is an extremely important issue. One wants to make sure the player faces something that feels frightening and works with the game's atmosphere and story. Another important aspect is to make sure that the enemy fits with gameplay. Certain movements might be required and it needs to fit, size-wise, into certain environments and situations. Finally you need to make sure that it is within the constraints of the available resources, something that is really important for small company such as ours. Having these three guidelines in mind I will now walk through the process of coming up with the core requirements for the enemy codenamed “Servant Grunt”.

My favorite way to go about when creating a creature is to take something normal and then add a disturbing twist to it. I also wanted some kind of character that the player could easily project agency to and believe it has motivations, imagining it more alive than it might actually be. Because of this I decided that we use some kind of human or at least humanoid entity, which is a shape that is easily recognizable (no other animal walks like a human) and which we all assume have feelings, desires and motives.

The problem with having a creature which gets the characteristics of a human projected on to it, is that the player will also assume it is intelligent. Because game AI is notorious for doing stupid things, this could easily break immersion. Having enemies do simple tasks like opening doors, avoiding obstacles and investigating strange noises in a believable human-like way is very hard to do. Hence, we had to have something in the design that hinted of stupidity, making it part of the immersion were the enemy to do something silly. Usually this means making something zombie-like, but I really did not want have something that cliché. This mean that I wanted the creature should look and feel stupid, yet still be as far away from a zombie as possible.

Avoiding clichés is usually something that ones does to keep things fresh, but in horror games a lot more is at stake. It is vital that the player does not feel familiar with the dangers faced as it drastically decreases fear and tension. It is when we are unsure about something and not able to predict or makes sense that true terror really emerges. For example, when building one of the game's maps, there was a vast difference in perceived horror between using an old, familiar enemy model from Penumbra (our previous game) and the new one discussed in this article.

Gameplay-wise the main constraint was that it had to walk in some human-like fashion and not crawl or move on all fours. This because we wanted to have a base collision that could easily fit into a cylinder, making it easier to code. For the first Penumbra game, we had dogs as the main enemy which, because they where four-legged, caused tons of issues. Something we wanted to avoid that this time around. Making sure implementation of the enemy is simple ties into saving resources. It was crucial that we did not want to have too many unknown factors when making the enemies. By making sure that most of the game's elements where familiar to us, we could much easier assure that we kept to the timetable and could spend time on polishing other parts of the game instead of trying to find AI bugs.

It was actually not until all of the above was determined that I started to figure out the story behind the creatures. This is not always the way we do it in our games, but this time it fit very well. Our basic story designs only referred to the enemies as “the servants” and did not talk much about their appearance or where they came from, so I had a lot of freedom to make a fitting background story to the guidelines. The finalized idea was that these “servants” were actually beings from beyond that had been summoned into bodies of humans. Once inside humans, they did their best to deform the host into a body that they are used to control, shattering bones, tearing flesh and producing cancer-like growths. This in turned resulted in a scene where the player witness how some humans under great pain are taken over, showing how designing graphics can shape the story, as well as the reverse.

With these basic guidelines completed, I contacted Jonas to start on the concept art.


Conceptualizing the Horror
by Jonas Steinick Berlin (pudjab [at] hotmail [dot] com)

Thomas gave me almost full creative freedom. The basic guidelines were that it had to be a humanoid and nothing like standard zombies, "The Infected" in Penumbra: Black Plague or the creatures in Dead Space. It should also fit the the story of demon-like creatures taking over human bodies and be super creepy. Apart from that, I was free to do pretty much what I wanted.

This was my first character design for a commercial game, so I was a little bit shaky. The great freedom was both exciting and quite overwhelming. So many choices! I first researched and got inspiration from unusual anatomy, photos 18- and 19th century clothing (the time in which the game takes place), surrealistic paintings and various disturbing stuff.

I then continued brainstorming and did a lot of small quick sketches of character silhouettes and different faces. I really wanted to avoid stereotypes and do something unique and memorable. Every single doodle got assembled on a collage and I then showed it for Thomas. He said which parts he liked and from that I went on and created something more detailed. At this time I had a design in my head that I really felt would be perfect. I drew it down with details, colors and lots of love. The result was something of a hunchback with interesting clothing fitting the era and a really grim face. This is perfect I said to myself! Excited I showed it for Thomas. However, I quickly got knocked down to earth again when he said that it looked too funky and resembled “Grodan Boll” (which is a character from a Swedish children's book taking the form of frog). I got instructed that I should avoid the cartoony style and make something more realistic, something that you almost could find in real life. Thomas also thought that it should have a lot less clothes.

The first batch of sketches. Contains the infamous “Grodan Boll” (“Frog Ball”) on the right. (Click to enlarge.)



After this setback I started putting a lot of attention on the head of the character. I think this is the part of the human body that you can make the most disturbing because of the emotions it can show. I instantly chose to give him a crushed jaw with parts of skin hanging down and eyes with dilated pupils which pointed in different directions. Thomas approved of this and I moved my focus to the rest of the body. Important here was to get the feeling of a demon possessing a body that it was unfamiliar to. The creature should try to deform the body into a, according to its own twisted standards, more familiar form, breaking bones and bending joins while doing so. It should also have accidental injuries and be held together with bandages and ropes.

The create is starting to shape up and the design of the head has been approved. It is not yet decided what to do with the lower jaw though (an issue discussed until the very end). (Click to enlarge!)


Because of the lack of clothes we had a discussion about showing genitals or not, but soon scrapped that idea after we realized that it would be best not to tease the rating systems too much (this turned out to be a non-issue as other part of the game show /Thomas).

Clothes have been determined to be nothing but a few bandages. Also started studying how the head might look viewed from the side, which turned out to be not a simple task. (Click to enlarge.)

One thing that was hard to decide was the final look of the left hand. It had to be deformed in some way, but yet be usable and able to be used as a weapon. I did at least 10 different arm designs before coming up with something that we could use. For example I did an arm in the shape of snowballs with spider fingers and one arm twisted in a spiral, with its bones pointing out. The final hand-design was more of a claw with bony fingers that we thought would be perfect for both scaring the player and give a good scratch on the back.

Before settling on a final design, many different version were tried. The left arm was the most troublesome part and changed a lot. (Click to enlarge.)



When I did the detailed final concept I started by drawing it up traditionally with a pencil. This may not be the most effective way to work (because it makes it harder to do big changes and also caused unwanted coffee stains), but I feel more in control this way and find it easier to do the smaller details. After that I scanned it and quickly colored it in Photoshop using multiply layers. I first tried a bluish skin tone, but it made it feel too much like an alien, so I changed it to a more desaturated one, warmer colors with elements of purple, blue and yellow to create a pale corpse-like look. At this point it didn’t feel too professional and had to go over the concept with Photoshop to add the final touches, such as highlights, noise removal and sharpening. The Photoshop-file ended up having forty plus layers, most of them containing small and unnecessary changes. Nothing I recommend, because of the insane file size, but this time it did the trick and I managed to convince Thomas the concept was completed.

The art was now done and could now be used by the modeler to create the actual 3d asset.

This was the final sketch of the enemy. After this was done I started painting it digitally. (Click to enlarge.)



Final concept for the enemy. Note how the lower jaw has been removed, something that was made after the entire character was fully colored.




Continue to the second part...

Sunday, February 27, 2011

Game Maker and HTML5...

So we've sprung a little surprise on folks by releasing a video of a Poker Squares playing directly inside a browser using HTML5, but how was this done, and what does this mean?

Well, first... we've made NO decision as to how this will be used. That is if it'll be available to the public, if we'll sell an exporter, or if we'll use it to publish stuff ourselves. This was done in such quick order that we really don't know where it'll lead to, but you can be sure we're now thinking about it. We obviously realise that everyone would simply want it as a free part of Game Maker, but that's unlikely to happen as it'll take time and money to make. Aside from that... we simply have no idea, so don't ask because we simply don't know yet.

Now... as to the tech demo itself. This was a lot of fun to do. I'd never touched Javascript before so I hard to learn Javascript and HTML5 programming while writing this, and while some of it was a little odd for me, it actually went pretty smoothly. In fact, far smoother than any of us thought it would. The project took a week and a half of Russell's and my time; pretty much to the exclusion of everything else. But even with that, a week and a half to produce what we did is an amazing result.

Before I go any further, I should stress this is a standard Game Maker game converted "automatically" into HTML5. We didn't rewrite Poke Squares to make it look good on the web, it IS the iPad version of the game running unchanged inside the browser.

So, there are two main parts to this demo...1st, the runner (or engine), and second the GML conversion. Now this is the first time we've attempted to write a Game Maker runner from scratch. When Russell and I first started we had a code base in the form of the C++ runner, and although we hated it, it was what we started with. So writing this version was a particular challenge to me because there were still areas we've never looked at, and this time I would have to understand the flow completely. It's ended up being a great learning experience, because many of these "black holes" have now been clarified. Some have had us rolling our eyes as to why it was implemented in a certain way, and others have lead to a deeper understanding as to why something was implemented in a certain way.

So with the runner side progressing, Russell then started on the GML conversion. What's really exciting about this, is that we compile the GML, then output javascript directly. This means that browser will run it as it would any native code (thanks to the Just In Time compiler). Now, while there's lots of padding around it due to the way GML handles certain things, it does mean we have now put the "GML to High Level Language" conversion to the test - and it works!! Boy does it work!! Russell has done a great job of this conversion, so much so that a couple of games convert directly, and are runnable inside the browser WITHOUT ANY GML/GAME MAKER CHANGES AT ALL!!. This is staggering really, that in less than 2 weeks we have produced something that would just convert a game and run it.

Now the runner has some issues to be sure. We are currently using the HTML5 canvas tag, although we may well swap the WebGL at some point because it'll give us everything we need. Currently the Canvas tag is lacking in some key areas; tinting images being one of them. I currently cache a slow conversion of any rendering with a colour tint. It works... but if you changed the colours a lot, it'll grind to a halt. WebGL would fix that, although there is word that canvas may well support this soon anyway.

Now it has to be said that currently, HTML5 isn't the best thing in the world. It's actually pretty slow on most browsers, and although Chrome is pretty good, IE9 blows them all out the water - its amazingly quick. FireFox 3.x is runnable, but slow, Safari is just rubbish, and IE8 doesn't work at all. All this will change over time. HTML5 is the way browsers are heading, and they'll all just get better and better.

That said... the engine, and the GML's javascript conversion runs incredibly quickly. ALL the slowdown is in pixel drawing, where as everything else runs in a few percent of the time. This is great news. Not only does it mean that the way I've rewritten the engine works okay, but for totally unoptimised code, the JIT is doing a great job with it. This is all good for the future.

Now, running this on an iPad or mobile device is still gonna be slow - really slow. These devices aren't optimised for this kind of experience, so don't think that once this is out you can do your own iPad games. It's just a bit pooh. This means our iOS and Android runner still has a place, and is still valuable to us. This also goes for windows and Mac though. Anything that will run in HTML5 should run MUCH faster natively. Soi native runners are still valuable there too.

Lastly... security. Yep. Put a game on the web and everyone will get your source. Not really much that can be done with that. We thinking long and hard about this one, it's nasty to be sure. Leave it with us... we know about it, and we're thinking about it. We do have a few ideas, but need to think about it. We don't actually think putting the "runner" on the web is an issue. All the "smarts" are in the conversion process, and that wouldn't be there. You can also obfuscate the entire code base. Still. We're thinking about it, lets leave it at that for the moment.

So there are two big lessons I'll take from this. First, I now have a much better idea on how to manage the C++ runner, and how to rewrite the bits I hate that are slowing everything else down (the events being the main thing for me). Second, we now also know we can do some amazing things with GML, from optimise the interpreter, to convert it to a whole new language to get it compiled - or even compile it natively ourselves. This is all pretty exciting stuff to us as it's not JUST about how well the HML5 port went, it's also how we can now use this invaluable information to make future versions of Game Maker and it's runner better for everyone! So while these aren't quick fixes or changes, we are now armed better for the future, so when we do a rewrite, we'll know exactly what we need to do to make it fly!

EDIT: Theres a discussion about this here: http://gmc.yoyogames.com/index.php?showtopic=501194 in the Game Maker Community Forums (GMC), feel free to join in there.

Monday, February 21, 2011

The Dragon Speech

This weekend I discovered the "Dragon Speech" by Chris Crawford and found it really great. He brings up a lot of good stuff, and touches on many subjects that I have ranted about. You can watch it here:

Part 1 "The Dream Well"

Part 2 "Interactivity"
Part 3 "Genesis of Art"
Part 4 "Characters"
Part 5 "Charge!"

I am actually a bit embarrassed that I never seen this talk before. I have heard about it, but never thought much about it and thinking it was not worth any attention. Now that I have seen it, I can say that is definitely not the case and it is one of the best things I've heard/seen on games.

Which brings me to another point: This talk is almost twenty years old and yet not much have changed. The points he bring up on focus on "fun" and serving a hardcore market are all still very valid. Also, characters in games have evolved very little, in fact, apart from a few IF games like Galatea, not much has happened since Monkey Island days. It feels like his views were ignored by most people in the industry. (If anybody has sources on what kind of impact it had on other people at the time, I would be really happy to hear about it!)

I like to think that things are shaping up a bit though. For instance, players and media have started to accept that games does not have to just about "fun", but can be about other type of emotions as well. (Something I like to think the horror games of the last ten years or so as had a part in). We are also starting to see the first step at a merge between the "casual" and "hardcore" market*, with games such as Drawn, which I see as the beginning of a less specialized market. The situation is far from good, but at least there are some sources of light.

Another thing of interest is that Chris Crawford has never made a conventional games since he held this speech. Right now he seems to be involved in something called Storytron, which I have to admit I do not know much about and have never tried. Now I feel I really must give it a go though! If anyone has tried it, I would be very interested in hearing your thoughts about it.

Finally, I also recently heard that Chris will be giving a speech at GDC this year. So will definitely try to attend that (me and Jens will be going there because of IGF and all).


*I do not like the names casual and hardcore. because they compartmentalize the audience far too much and I also think it is a bad way at looking at things (either you like to shoot stuff or play simple puzzles!!!). But since I refer to a trend in the industry I thought it was kinda okay to to use them.

Friday, February 18, 2011

The Dead Island Trailer and the Future of Games

By now most of you have probably seen the teaser trailer for Dead Island. If not, you can check it out here:
http://www.gametrailers.com/video/cinematic-trailer-dead-island/710652


This trailer has been getting tons of attention over the Internet and many seem to think that it is one of the best game trailers ever. I find that this is quite interesting, since just about everything that makes the trailer good are things that modern video games lack. I would even go as far as to say that a video game made using modern gameplay-centric design could never create something that gives the same experience.

This is why I think so:


Non-coherent narrative
The video does not have follow the normal rules of making a narrative (where time flows coherently through plot events), but instead provide a disjointed one. Past and present are not explicitly stated, but is something that the viewers must figure out themselves. Game with a focus on story just do not work like this and instead go through plot points in a predetermined (although sometimes branched) fashion.

In order to get the same kind of feeling you get from the trailer in a game, stories needs to be looked upon in a different way. A story should not be seen as a string of plot points, but as a certain essence that is meant to be communicated. (See this post for further discussion on the subject).


Violence is not the focus nor the fun part.
This is something that I have talked about lots before, most recently in a discussion on Dead Space 2. When you start to focus on making sure that all gameplay is fun, then that trumps any other emotions that could have been evoking. The violence in the Dead Island trailer is not fun. It is desperate, repulsive and tragic. How can you possibly hope to evoke the feelings of a man forced to "kill" his own daughter if your aim is for it to be fun?


Hard-to-repeat moments
An important part of video games today is that they stop you from making progress unless you meet specific requirements. This is mostly in the form of some skill-based challenge (succeed or restart), but can also be in the form of navigational or puzzle-like obstacles. While of course imperative in some games, this sort of design can greatly decrease the emotional impact of events. Mainly because forcing a player to relive an event dilutes its impact and sets focus on mechanical aspects. Secondly because blocking the player from progress can make certain situations unbearable.

The trailer has both versions of this problem. For instance, the chase sequence where the child runs to the door is not something that works when repeated. Also, the event when the child falls through the window is an example of something that you do not want to replay or get stuck at. (A more in-depth discussion can be found here.)

Just so I am clear here: I do not mean that a game should try and replicate the events exactly like in the trailer. Video games are a different medium from film and needs things to be done differently. Instead what I do mean is the recreation of the essences of these events and situations; to provoke the same kind of emotions and thoughts. Not to make a direct copy.


A holistic experience
What I mean by this is that you need to see the whole thing to get the full experience. Unless you see the trailer until its end, you will not the get full meaning of the work. Mainstream games almost never work in this way, but rather focus on maximizing the entertainment value moment-to-moment. This is partly because of the goal to make games "fun" above all else. Other causes are the focus put on length of the experience as a large part of the value, and a general attitude of games as products rather than works of art (explained nicely here and here).



With the above in mind, it should come as little as a surprise that I find it highly unlikely that Dead Island will be anything near what the trailer is like (although I hope the reactions to this trailer inspire them to give it a shot and perhaps succeed!). I think there really is a desire for games that offer a different and more emotional experience, the attention this trailer got being a clear sign of that. But if we stick to the tried formula of making video games, these kind of experiences will remain beyond our reach.

Wednesday, February 9, 2011

Thoughts on Dead Space 2

Introduction
So I just finished Dead Space 2 and wanted to discuss it a bit. Mainly because it is a perfect example of some trends in game design that I find are really harmful. I also find that it has some moments that could have been brilliant if just slightly changed, making it extra interesting to discuss.

Before going into the actual critique I want to say that the game did have some enjoyable parts, especially the at times absolutely amazing scenery. Dead Space 2 just radiates production value and it is a very well-put together game. I quite liked a lot of it and it is one of the few games in recent memory that I played until the end. The game has very nice atmosphere in places and even attempts at a sort of meaningful theme(more on that later).

At the same time, it is very clear that Dead Space does not aim for any real sophistication. For instance, you need to stomp on dead mutant children to get hold of goodies and gore is quite excessive. In many ways, the game is much closer to Dead Alive (Braindead) than to something like Alien, and should probably be judged that way. However, in the following discussion I will approach the game as if the goal was to create a tense sci-fi horror game.

With that out of the way, let's get down to business.


Cheap deaths
When I started the game, I was not in the best of moods (being a bit agitated), but I did what I could, darkened the room and so on. Everything to heighten immersion. As the game started out, it began with a non-playable sequence, something which made me relax and slowly immerse myself. Once the game actually began and I gained control, my mood had changed quite a bit and I felt I was ready to be immersed and role-play. Then after just playing for 30 seconds or so, I took a wrong turn and died.

This broke all the immersion I had built up over 10 minutes or so, and I had to start all over. The intent was probably to communicate the danger to the player, but this could have been made a lot better. Why not simply hurt the protagonist, or something similar, giving in-game feedback that the player should be very careful. After I had died and gotten a loading screen, I had to build up my mood again almost from scratch.

The same thing happened at the end of game, where you need complete a sort of chase-sequence before the final cinematic. I was unsure of the controls in this sequence and died just before it was over. Just like with the death at the start, this completely spoiled my mood and removed any emotional impact the ending might have had. Instead of becoming an exciting sequence, it became an obstacle and I concentrated on the pure mechanics instead of role-playing.

Having cheap deaths during immersive/emotional events like this is just lazy design. The sequences are meant to be completed in a specific fashion anyway, so I cannot understand what can be gained by having players restart over and over until they "get it". Sure it adds some kind of excitement, but this is greatly removed on subsequent attempts anyway, not speaking of how bad this is for immersion and role-playing. And considering there are other ways to add consequences to actions, I do not think it is a valid reason. It is just falling back to old and uninspired design.


Saving Progress
Scattered across the game are save stations, all using an interface similar to 20 year old games. I do not understand why these are in, as it is the most immersion-breaking device one can think of. Having to enter a menu, and choose a slot in which to save, has no connection to the game world at all. Consoles nowadays have large hard drives (and save games can be made very small) so it cannot be a technical limitation like in older games. I am guessing it is just another case of falling back to old design patterns, and again I think it is totally unnecessary.

The way I save games in systems like this is to loop through the visible slots (usually four), always picking the oldest save game to overwrite. That way I have three older save games to go back to in case something screws up. As this is basically the system we emulate in Penumbra and Amnesia, and nobody has raised any complaints on that, I guess I am not alone in saving like this. So, if one still wants to use the save stations, my first suggestion would be to simply skip the interface and just save upon interaction. If players want to go back to certain places have a "Save Game" option in the menu or simply a chapter selection.

But why stop at that? I would have liked the game to skip saving altogether and do it automatically for me. Dead Space 2 implements resource streaming extremely well and you never feel like you travel between different maps, but roam a continuous environment. Not having any kind of visible save system would fit this design perfectly and most likely increase atmosphere.


Repetition
It seems quite clear to me that Dead Space 2 tries very hard to provide a lengthy adventure (took me 10 hours or so go through) and to do so it repeats many elements over and over. This is something that exists in just about any game, where the goal of having filling a certain length quota trumps pacing, story development and the like.

For example, I really liked the first time the protagonist is forced to crawl through a ventilation shaft, but the tenth time this was repeated it just felt old and uninspired. Instead of trying to come up with new ways to create similar moments, the first one used is just recycled. Another example is the hacking mechanic that was served as an interesting diversion the first time, but ended up being an unwanted frustration.

You rarely see this sort behavior in other media (at least the good works). It is only in games where an, at first intriguing and noteworthy, event/idea is repeated until tedium. I would much rather have a shorter game that constantly bombards me with unique and inspiring sequences.

Dead Space 2 does do this right at a few times though. For instance, one section has the protagonist hanging upside while enemies swarm from all directions. This sequence is never repeated and not even dragged out. I would have liked to see that for all parts of the game.


Looting and Shooting
I might be that I am slightly disturbed, but I find shooting limbs of monsters a great pastime. Especially with the fun and greatly varied arsenal that Dead Space 2 provides. So much did I enjoy it in fact that it is hard to focus on much else. Sure, some of the fighting can be pretty intense with enemies swarming you, but not that much different from how a game like Tetris can be. Added to this is the focus on upgrading the weapons and finding ammo/money, which further brings your mindset toward the shooting part of the game.

I have talked about how focusing on fun can be bad before, and Dead Space 2 is such a perfect example. Your main motivation to explore the environment is not to get deeper into the story or to enjoy the art, instead it is to search for goodies. Because the game constantly bombards you with items popping up and force you to pay attention to them (you will run out of ammo otherwise), this becomes the main thing occupying your mind. Everything else is simply pushed into the background, which is really a shame consider the epic set pieces and sometimes interesting background facts. In their effort to comply with "fun" gaming standards, the creators have actually let much of their hard work go to waste.

I must add that the combat was not completely un-scary though. I started out playing on normal, and at one point, my resources had almost run out, which made me much more careful and tense when I thought monsters might be near. As I was put in this state, it completely transformed how I approached the game, and I started to pay more attention to background sounds and the like. Unfortunately, as I died the combat sequences stopped being scary and instead became tedious challenges in resource management. This together with the increased urge to find hidden items, killed most of the atmosphere to me. I then change to easy difficulty and could enjoy the game more as I did not have to worry about looting or combat strategies as much.


Story
Dead Space 2 does have a story, but you will have to make an effort to find and experience it. As if the focus on combat was not enough, the actual story seems to be consciously pushed into the background. I can actually only recall one time when you had to actively confront the story (reading a note gives a clue on solving a puzzle). The rest of the story just plays out in the background and as a player you are pushed on by the urge of upgrading weapons and dismember mutants.

The game does have some interesting aspects though, for example trying to tie the entire game up with the protagonist's grief, but since it is so drawn out and overwhelmed by other elements, it does not really work. Another intriguing part of the game are some earlier sequences where you encounter people fleeing from monsters and people locked up in cells. Hearing the hammering of somebody wanting your help was quite disturbing and had they just added some kind of interaction related to this (like try to open the door) it could have been extremely effective. Instead it was just pushed into the background.

One of the story things that I did really enjoy was how a recording spoke of the material of a ceiling in an upcoming room. When entering the room your attention is directly drawn up and you could relate the recording, graphics and background story to each other in a nice way. I really wished the game had a lot more of this.


Motivation
In the first Dead Space you played the part of a silent errand boy, something that the creators tried to change in the sequel. The way they try to do this is to make the protagonist an active character and make his own decisions. However, I think this sort of backfired and in Dead Space 2 I had even less of an idea on what is going on. Several times I had to check the "mission log" in order to find out what I was up to, and to find out the reasons for this. Since the protagonist was already talking, I wished he could have done this just a little more, explaining his action and reminding me, the player, of what I was supposed to do.

This also connects to the way the story is told, and further distances the player from the events in the game. Instead of deciding for yourself what the right course of action is, you just follow the game's instructions in hope that will allow you to progress. So while in the previous game you followed the commands of in-game characters you now follow the commands game's interface. This is of course much less immersive.


End notes
Playing Dead Space 2 made me both sad and hopeful.

Sad because I feel there is so much excellent work that has gone to waste and that I keep wondering if there will ever be any change to this. For every game i play I feel that there is so much potential lost due to following old and dull game conventions.

Hopeful because while there is much I do not like, it feels that there is not that much needed to totally transform the experience. Simply removing all combat focus and making the game half as long would probably have created a much more interesting experience. The question is if that will ever happen, but now I am at least confident that it is possible.

Tuesday, January 25, 2011

Physics and Heightmaps

When I thought that all problems with heightmaps was over, I stumbled upon something sort of tricky recently. The only thing I had left for heightmaps was to add physics to them. This seemed easy to do as it was basically just a matter of sending the raw heightmap data to the physics engine (newton game dynamics) However just as I had done this I realized that this was not enough: the terrain could have many different physical properties at different places (a spot with dirt, one with rock, etc).

The thing is that in physics simulations you give a material per shape, each material having certain properties (friction, etc) and special effects (sounds, etc). The heightmap is counted as a single shape, and thus it only has a single physics material. This was something I had totally forgotten. Luckily, the physics engine supports the assigning of special properties to each point in the heightmap. Once I found the proper info, it was pretty simple to add this (see here).

Now it was just a matter of adding extra material values to the heightmap (basically just an array of single integers, the id of the physics material at each point). My initial idea was that this could be "painted" on as an extra step, and to be sure I asked Jens what he thought about it. His reaction was that this would be way too much work and wondered if it could not be auto-generated instead. We already had a physics material assigned to each render material, so the basic info was easily accessible.

However, when I started to thinking about this, I found the actual auto-generation increasingly tricky. How should we determine which of the many blended materials to set the physics properties (blending was not possible)? Also, how do I get this information, considering that the blend textures can saved as compressed textures, into a CPU buffer?

The way we chose to solve the material picking was that the top visible (meaning over a certain limit opacity) blend material always sets the physics material. This allows map creators to set priority on materials in terms of physics, by simply placing them at different places among all blend materials. For example, if a material like gravel should also have its effects shown no matter what it is blended with, then it should be placed high up in the list. While currently untested this seem pretty nice and can also be tweaked a bit (like having something else determining priority).

The generation of this data was made by rendering the blend textures to an off-screen target and then grabbing the data into normal memory. What this meant is that the GPU would decompress any packed textures for us. This also solved some other problems, like the need to resize the texture according to heightmap resolution. Once the data is grabbed from the GPU it is just a matter to loop through it, check values and write to the final buffer.

Problem was finally solved and physics properties auto-generated!


With this little post I hope to show that there often is more to a problem than what is visible at first. Also, this shows another advantage of using normal texture splatting (more info here), instead of megatextures or similar. With the auto-generation of physics, it is much easier to create and update the terrain, something extremely important when you are a small team like us.

Would be very interesting what other techniques people use (or known of) for setting up physics properties on terrain!

Saturday, January 22, 2011

Reading GM suggestions...

So, would you believe it... I found some free time. Probably because everyone at home is ill, or sleeping but time none the less. So I decided to read through the current GM suggestions listand there's some interesting stuff on there. I suspect much of it wil have to wait for the rewrite, but we can still do a fair bit during the many updates to 8.x we hope to do in the future.

Types... Not for 8.x (or not fully that's for sure)

Values
we'd like to get ints/bools etc. in there, but not sure when. Enums are also a must at some point - I hate having to define constants in the menu system. Unicode is a long term goal for Game Maker, but I think it may well be too painful for 8.x.

Collections.
Actually, I don't really like any of the collections. I think it's one of the few areas where you really NEED "class" based operations. So instead of giving you a handle to something, you actually get the object back. This will be a hotly debated topic at YoYo, that's for sure. We don't want to break everyone's source, but at some point, you have to make a change. This may mean keeping the old ones and giving some new ones, then removing the older stuff in a later version. But at some point, I think the old "handle" system should go. Again.... will be a huge debate internally on this, and we'll then need to open that debate up to external devs as well.

Scope.
Yes. Need Scope. I'm not a huge fan of C++ style namespaces, but they work well on C#. That said... they aren't vital. So not sure, another one to discuss. Multiple inheritance...Mmmm...prob not, but who knows. def not for 8.x. As to uninitialised variables not being 0, well.... that's needed for beginners, there's no doubt. We are coming to the conclusion that there may be a new level though - Pro (or something), where things get really interesting! Time will tell on that one.


Scripts.
Default args would be better. I suspect we may well start allowing proper script definitions, then all this would be possible. But it would also allow us to keep the current method for beginners. But I prefer proper definitions as it means you get proper error checking when calling functions as it knows the number of args it needs. We can work it out I guess simply by checking how many args it uses IN the script, but it's cleaner and less error prone to define it. I don't think you need pass multiples args back. Again, if you had proper defined functions you could specify "outs", but other than that, you can currently just use globals and set them. It does the same thing.

Flow control - not for 8.x
Multi level break? Don't be silly.

Editor.
non-modal editors. Sooooooooooooooooooooo YES! I hate the horrible modal dialogs! Hate them!! Hate them!! Hate them!! Hate them!! Depending on time, This might get in to 8.1, however we need to discuss with the community to see if there's any valid reasons to keep them. Mark thinks there is... but couldn't remember, so we'll open it up for discussion soon.
Better window management. Yes. def. Tabs would be nice.
Multiple selection/editing of tree resources. Yes.
Dragging resources between projects. This would be nice... but no idea when.
Group duplication. Another nice but "when we have time..." one.
Portable Installation.. We'd have to look into that due to piracy issues.
Escape closes... yeah.

Debugging
Whole debugger needs redoing, but that'll probably be 9.x or so. You need the new scripting engine for this. Once thats in, then pretty much all this is possible, and will be done. Not sure about dynamic recompiling though. It's nice, but might be tricky... Probably between game "ticks" is the simplest way.

Code
I've said before. The code editor is reasonably good, but just needs a little update to make it very good. Most of these should be done at some point, with luck during 8.x life cycle. I'd remove the external editor, but more on this later....

Objects
Bypassing D&D - yes.
Inheritance graph. I guess. I never use them, but on others games it might have been handy to see, and I know others use them.
Show GML equivalent of D&D. We hope to go one better than that...
undo.. yeah... need a better undo system over all. But that's probably a 9.x thing.


Rooms
Instance stuff. Yes. The idea at some point in 8.x is to move to a more select and change system, rather than the current kinda mushed one. We will start making everything brushes, and that will let us do all manner of things. Group selection/editing, grabbing chunks from the map, painting with them and all the rest. You should also be able to set some instance data directly from the editor. rotation, scale, colour etc...
Zooming. Oh HELL yes. Will be there in 8.1, in fact... it's almost complete. We might post a video soon to show it working. It's a massive MASSIVE improvement.
Layers/tiles. Yes. In fact, I want to completely change the tiling/instance system to be more "playfield" based. I find this is much less error prone, and will let the graphics engine draw everything much, MUCH faster. Currently tiles are really just very cheap instances, and everything is drawn pretty slowly. But if you do a proper tile/layer system, then you can blast whole layers very quicly indeed. Rendering would speed up massively. Not sure if this will make it into 8.x as again, we will need to take care not to break everything.
Grid offset/colour - sure.

Sprite.
onion skinning. Yes. Might be 9.x
Selection/manipulation... not sure.
Curves. Probably.
default precise checking. If this is the pixel checking for game collision, then no. This is really REALLY slow... so you should be forced to think about it. If its something to do with the editor, then not sure. Preload. I think all preload stuff is going.

Triggers.
Not used them yet, so won't comment.

Files.
split gmks... More on this later....
Remove redundant compression. The file format will be changing. More on this later.
conditional compilation. Yes. Would be nice. Not sure when.

Editors
Sound editor. Perhaps...
Particle/effect. Yes, at some point. Preferably right inside the room editor. Prob a 9.x thing, but you never know...

Extensions
DLL access to in game resources. Yes, would be nice. But tricky. At the very least getting texture handles and a pointer to variable "values" would be good, but I don't know how possible this is yet.
IDE mods. Not for 8.x
extensions in general will be changed in 9.x I think. We want to do a lot more with them. 8.x ones are pretty limited.

Drawing.
Animated tiles - yes.
isometric tilesets. Not high on the list. (I presume you all mean free assets here)
alpha in colour - oh hell yes! Full 32bit colour values rather than alpha, and colour would save LOADS of effort in the engine.
draw_*_tiled_region... not sure what this means. Draw a sprite./background tiled? yes, sure.
More vector support. more prims. bigger better drawing in general... yep
Layers - I'm a BIG fan of layers...
Correct normals for 3D solids??? They aren't correct? (spheres, cubes etc?)
More 3D formats - 9.x (at some point)


bloody hell this list goes on some!


Collision
Not used the more complex collision very much.. so won't comment. It's pretty slow though, so needs an overhaul.

Instances - sure. Though don't hold your breath for Lambda stuff.

Sound
Sound instance. Yes
formats - yes.
seek - probably
length - probably.
modification - probably
mute - yes. Master volume should mute media player music too really.

Rooms - yes and yes.
I'd also like to add scissor regions. So you can hardware clip to a rectangle.

Networking.
Total rewrite required.

Reflection.
Yes. But not sure when.... 9.x prob

Maths.
Well, better maths in general.


Files
ini files. INI files aren't too bad. But need some kind of instance or handle so you can have multiples open at once. You also need to be able to flush an ini file, to get rid of old stuff. Basically, a refresh would be nice. xml etc would also be good.
read whole file - yes. soon I hope.
game save/load. This whole thing needs redone. But it could throw an event.

Input
yes. Allow multiple mouse clicks at once as well (allows for multi-touch devices)
Joystick - sure.


Timing.
Mmm...
Naming alarms would be nice. I don't like just having alarm[3] either.
Hires timer would be great. It's available, so we should provide it.

Interface.
Message boxes. This is an on going debate. I think we should make all message boxes the OS native ones. This allows for Macs to look like Macs, and windows to look like Windows. But there is a backward comparability issue, in that the code allows your to change the look/feel. I think if you want to do that... do your own dialogues. SO not sure if it'll be in 8.x.
Not sure about the rest.....

Runner.
We will be changing the runner format, and making it harder to decompile. Will be done in 8.x time-frame.
Bytecode generation at build time. Yes. Not sure when. Might need the c++ runner for that.
remove debugging in release builds - would also be nice.
Unused resources. Yes, however... since you can refer to resources as strings, and then later make them into actual object references, then it becomes hard to actually know if someone has used an object. However, we hope to make this an option so if you don't do this, then we can strip out all the crap. We've seen sketches and photos in a games .exe as the developer as used it as a project workspace, but the final program has gotten it all as well. This should be cut in some way.



Wow. Okay, that was much longer than I though it was going to be..... Now just because I've said yes doesn't mean it'll happen tomorrow. And just because I've said no, doesn't mean it'll never happen. ALL these things are still up in the air, and under discussion. We're very aware that anything we change will have a massive impact on the community and developers work flow, so we want to be very careful as to how we proceed. I think I'll probably start some GMC topics to open discussion with the community about some of the changes, and we will speak directly to the devs we've been working with before anything major is affected. In general, additions will probably go right in, while changes may take some time to validate the need, and the effect on the community.

I've mentioned before just how excited I am to start working on Game Maker itself. It's a fabulous product, with a great community, and huge scope for change and improvement. I think we can drive Game Maker to be the tool to use for indi devs, but it'll take time. The real improvements will only come with the rewrite, but we should be able to start the process in this iteration.

In the next few weeks, you'll hear whats going to be in our first update, although you all know about the room editor zoom. We hope to do small iterations, more often. So with luck, for 8.x there won't be any more massive waits, you'll get updates much more often, and new features will slowly start to appear.

EDIT: Oh yeah... The documentation needs an overhaul as well. It should be more like DirectX with actual examples of function use, not just listing them - that's no use to anyone! However, this is a massive task. But one day, we will.

Thursday, January 20, 2011

Tech Feature: Undergrowth

Introduction
After a little break with updates on the rendering system, holidays and super secret stuff, I could finally get back to terrain rendering this week. This meant work on the final big part of the terrain system: Undergrowth. This is basically grass and any kind of small vegetation close to the ground.

As always, I started out doing a ton of research on the subject to at least have a chance of making proper decisions at the start. The problem with undergrowth/grass is that while I could find a lot of resources, most were quite specific, describing techniques that only worked in special cases. This is quite common when doing technical stuff for games; while there are a lot of nice information, only a very small part is usable in an actual game. This is especially true when dealing with any larger system (like terrain) and not just some localized special effect. In these cases reports from other developers are by far best, and writing these blog posts is partly a way to pay back what I have learned from other people's work.

Now on with the tech stuff!


Plant Placement Data
The first problem I was faced with was how to define where the undergrowth should be. In all of the resources I found, there was some kind of density texture used (meaning a 2D image where each pixel defines the amount of plants at that point). I did not like this idea very much though, mainly because I would be forced to have lots of textures, one for each undergrowth type, or to not allow overlapping plants (meaning the same area on the map would not be able to contain two different types of undergrowth). There are ways past this (e.g. the FrostBite engine uses sort of texture atlases), but then making it work inside the editor would be a pain, most likely demanding pre-processing and a special editor renderer. I had to do something else.

What I settled on was to use area primitives, simple geometrical shapes that defined where the undergrowth would be. The way this works is that each primitive define a 2D area were plants should be placed. It then also contains variables such as density, allowing one to place thick grass at one place, and a sparser area elsewhere.

I ended up implemented circle and convex polygons primitives for this, which during tests seem to work just fine.


Generating the Plants
The next problem was how generate the actual geometry. My first idea was to simply draw the grass for each area, but there were some problems with this. One major was that it would not look good with overlapping areas. If areas of the same density overlapped, the cross section would have twice the density of the combined area. This did not seem right to me. Also, it was problematic to get a nice distribution only using areas and I was unsure how to save the data.

Once again, the report on the FrostBite engine gave me an idea on how to approach this. They way they did this was to fill a grid a with probability values. For each grid point a random number between 0 and 1 is generated and then compared to to the one saved in the grid. If the generated number is lower than the saved, a plant is generated at that point, else not. Each plant is then offset by random amount, creating a nice uniform but random distribution of the plants!

This system fit perfect with the undergrowth areas and simplified it too. Using this approach, an undergrowth area does not need to worry about generating the actual plants, but only to generate numbers on the grid.

The final version works like this:

There is an undergrowth material for each type of plant that is used on a level. This material specifies the max density of each plant and thus determines how the grid should look. A material with a high density will have a grid with many points and one with a low density will have few grid points. Each point (not all of course, some culling is used) on the grid is checked against a area primitive and a value is calculated. This is then repeated for each area, adding contributions from all areas that cover the same grid point.

This solves the problem of overlapping areas, as the density can never become larger than max defined by the grid. It allows makes it possible to have negative areas, that reduce the amount of undergrowth in a certain place. This way, the two simple area primitives I have implemented can be used for just about any kind of undergrowth layout.


Cache system
Now it is time to discuss how to generate the actual plants. A way to do this is to just generate the geometry for the entire map, but that would take up way too much memory and be quite slow. Instead, I use a cache system that only generate grass close to the camera (this is also how FrostBite does it).

The engine divides the entire terrain into a grid of quads, and then generates cache data for each quad that is close enough to the camera. For each quad, it is checked what areas intersect with it, and layers are made for each undergrowth material that it contain. Then for each layer, plants are generated based on the method described above. The undergrowth material also contains texture and model data as well as a bunch of other properties. For example, the size can be randomized and different parts of the texture used, all to add some variety to the patch of undergrowth. Finally plant is also offset in height according to the heightmap.

This cache generation took quite some work to get good enough. I had problems with the game stuttering as you traveled through a level, and had to do various tricks to make it faster. I also made sure that no more than one patch is generated at each frame (unless the camera is teleported or similar).


Rendering
Once the cache system was in place, rendering the plants were not that much of a problem. Each generated patch comes with the grass in world coordinates, so it is as simple as it can get. The only fancy stuff happening is that grass in the distance is dissolved. This means that the grass does not end with a sharp border, but smoothly fades out.


In the above image you can see how the grass dissolves at distance. Here it looks pretty crappy, but with proper art, it is meant that grass and ground texture should match, thus making the transition pretty much unnoticeable.

Another thing worth mentioning, is that the normal for each grass model is the same as the ground. This gives a nice look to many plants, but an individual plant gets quite crappy shading. Undergrowth is meant to be small and not seen close-up though, so I think this should work out fine. Also, when making grass earlier (during development Amnesia), normal normals (ha...) were used and the result was quite bad (sharp shading, etc).


Animation
Static grass is boring, so of course some kind of animation is needed. What I wanted was two different kinds of animation: A global wind animation (unique for each material) and also local animation due to events in a limited area (someone walking through grass, wind from a helicopter, etc).

My first idea was to do all of these on the cpu, meaning that I would need to resend all the geometry to the graphics card each frame. This would allow me to use all kinds of fanciness for animation (like my dear noise and fractals) and would easily allow for lots of local disturbances.

However, I did some thinking and decided that this would be a bad idea. Not only does the sending of data to the graphics card take up time, but there might be some pretty heavy calculations needed (like rotating normals) for a lot plants, so the cpu burden would be very heavy. Instead I chose to do everything on the GPU.

Implementing the global wind animation was quite simple; i was just a matter of sending a few new variables to the grass shader. But it was a bit harder to come up with the actual algorithm. Perhaps I did not look hard enough, but I could find very little help on this area, so I had to do a lot of experimenting instead. The idea was to get something that was fast (i.e. no stuff like Perlin noise allowed) and yet have a natural random feel to it. What I ended up with was this:

add_x = vec3(7.0, 3.0, 1.0) * VertexPos.z * wind_freq + vec3(13.0, 17.0, 103.0);
offset.x = dot( vec3(sin(fT*1.13 + add_x.x), sin(fT*1.17 + add_x.y), sin(fT + add_x.y)), vec3(0.125, 0.25, 1.0) );

add_y = vec3(7.0, 3.0, 1.0) * (VertexPos..x + vOffset.x) * wind_freq + vec3(103.0, 13.0, 113.0);;
offset.y = dot( vec3(sin(fT*1.13 + add_y.x), sin(fT*1.17 + add_y.y), sin(fT + add_y.z)), vec3(0.125, 0.25, 1.0) );


This is basically a couple of fractually nested sin curves (fbm basically) that take the current vertex position as input. The important thing to note is the prime numbers such as vec3(7.0, 3.0, 1.0) without these the cycles of the sin curves overlap and the end result is a very cyclic, boring and unnatural look.

The offset generated is then applied differently depending on the height of the plant. There will be a lot of swaying at the top and none at the bottom. To do this the base y-coordinate of the plant is saved in a secondary texture coordinate and then looked up in the shader.

Now finally, the local animation. To do this entities called ForceFields are used. (Thanks Luis for the name suggestion! It made doing the boring parts so much more fun to make.) These are entities that come with a radius and a force value, and is meant to create effects on the graphics that they touch. Right now only grass is affected, but later on effects on ropes, cloth, larger plants , etc are meant to be added.

These effect of these are applied in the shader and currently I support a maximum of four ForceFields per cache patch. In the shader I either do none, a single entity or four at once. This means that if three entities affect a patch, I still render the outcome of four, but fill the last one's data with dummy (null) values. Using four is actually almost as fast as using a single. Because of how GPUs work, I can do a lot of work for all four entities in the same amount of instructions as for a single. This greatly cut down the amount of work that is needed.

Again, just like with the global wind, it was hard work to come up with a good algorithm for this. My first idea was to simply push each plant away from the center of the force field, but this looked really crappy. I then tried to add some randomness and animation to this in order to make it nicer. As inspiration, I looked at Titan Quest, which has a very nice effect when you walk through grass. After almost a days work the final algorithm look something like this:

fForce = 1 - distance(vtx_pos, force_field_pos)/force_field_radius

fAngle = T + rand_seed*6.28;
fForce *= sin(force_field_t + fAngle);

vDir = vec2(sin(fAngle), cos(fAngle));
vOffset.xz += vDir * fForce;


Rand seed is variable that is saved in the secondary texture coordinate and is generated for each plant. This helps gives more random and natural feel to it.

Here is how it all looks in action:


Note: Make sure to check in HD!

And in case you are wonder all of this is ugly, made in 10 seconds, graphics.


End notes
Now that undergrowth is finally done, it means that all basic terrain features are implemented! In case you have missed out on earlier post here is a summary:

Terrain Geometry
Fractals and Noise
Terrain Texturing

I hope this has been of use and/or interest to somebody! :)

Next up for me is some final terrain stuff (basically just some clean-up) and then I will move on to more gameplay related stuff. More on that later though...