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



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.

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!!!

Some thoughts

{DELETED BY MODERATOR}

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.

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.)

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...

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.