I feel in the mood to ramble, so stay with me here :)
First... 2010. Been an odd year for me. Start of the year was pretty bad for me, I was having massive disagreements with the heads of the My World project. I felt they were killing it, making stupid short term decisions, and were letting a bunch of juniors who didn't know what the hell they were doing, redesign everything. I started this project; all on my own. There's been a load of posts about the rise and fall of Realtime Worlds, but I think the real crime (money aside), was that they just didn't listen. Over the years, I told them over and over; Don't do this or that, you'll regret it. But no... they knew better. Yet, years later, they realised over and over that they had been wrong. You hire experienced people for a reason, you should really listen to them.
So this was the start of the year. They drove me out far earlier than I would have liked, but then in stepped Sandy and YoYo Games. Having been working freelance for them for quite some time, I was able to just jump right in and get going. Working from home was hard at times, but then again... it was also a joy! With Russell starting just a few weeks before me, we were in a real comfort zone, and worked well together, using Skype to discuss the hard bits. The real long term plans were finally kicking off. After about 3 months of this, we were ready to look of offices, both in terms of needing a place for new hires, and the fact that Russ and I had about exhausted the ability to work at home.
After looking at lots of places, we got a great deal from Abertay that we just couldn't say no too, and we moved in. Starting up, getting an office and moving in is always a great time. You feel like everything is on the up and are extremely motivated, so we ploughed through the work. Kirsty and Andrew obviously joined us about this point, and the feeling of growth continued. Much fun and joy ensued.
We plodded along like this for a little then we heard a loud bang from across road. Realtime Worlds had imploded. While it wasn't a huge surprise, it was a shock that it went down so quickly. Still, every cloud and all that... we picked up a few great guys from Realtime Worlds, Stuart, Lee and later Malcolm. Geoff also joined us as we shifted focus from PSP to iOS.
The iOS port was done very quickly, and so in less than a month we hard ported the Win32/PSP version of the runner over to iOS and had submitted our fist App. The long term dream of Sandy's was now a reality. Games running on multiple devices. Community games being sold on other devices. Getting Stuart from the ruins of RTW was a godsend, he jumped head first into production and started to formulate the pipeline, and we soon had several games lined up, and were pumping them out at the rate of about one a week.
Abertay also came into it's own. A huge pot of student artists, testers and musicians ready to help us, and this was all very welcome.
Sandy then wanted to release a free game, something to raise our profile a little in the iPhone/iPad world, and decided a little Solitaire game would be nice. So Andrew started work on this little game. But it actually turned into a monster. Lots of little niggles and bugs were causing Andrew to pull his hair out, so I took a little break from the platform side, and gave him a hand. This was the first time I had really used Game Maker in anger, so it took some time for me to get my head around it. It's a totally different way of doing things (from my perspective). Still, I took Solitaire apart, and put it all back together, and we were finally able to submit it to Apple. Little did we know that it would cause such a stir!
Now.. Christmas is a unique day in app-store time. Downloads are huge for everything as everyone gets apps for their new devices, and even though Solitaire had been doing great already, it stunned us on Christmas day. 75,000 downloads in a single day! Of course... we didn't find this out right away; no. The Apple site was down for a week over Christmas, so late on the 28th December when we got the weeks numbers, we were ecstatic!
So... all in all, a good year, with a bad start. But a good year never the less. So what's next? Well, Sandy has already said we're now working on Gamer Maker 8.1, and I've been doing just that over Christmas. I've been itching to get my hands on it, and improve Marks already damn fine program. I'm currently adding the much asked for ZOOM feature to the room editor. Ever since I started playing around with Game Maker, I felt this was missing. I've never written a modern tile editor that didn't have a zoom. Simply put: you need it. Moving back from my test version to the 8.0 is now hard going! The lack of ZOOM in there is even more apparent, so it's great to finally get it in.
However, because of this... it also needs a little speed boost. So I'll also be speeding up all the drawing code that's in the editor. I was surprised to discover it's not hardware accelerated, so it's actually doing pretty well in it's current state! We will at some point change that, but not just now, that'll take more time, and we simply don't have that just yet. However... once we've done a new release, we'll be able to play with it in the background and make the improvements we need, and you want.
We will also be doing a load of bug fixes. As many simple niggles as we can, along with the more complicated ones that stop folk dead in their tracks - if we can (it's still a new code base to us). I really feel excited to finally be able to extend and improve Game Maker, and although it'll take a little time; it's gonna be great!
So finally... looking forward to 2011. What does it hold for us? Onwards and upwards I hope!!! We're building some real momentum here, and it's looking better and better for all things Game Maker and YoYo! We have big plans for both community games, and Game Maker itself, and I am literary tingling with anticipation! I'm a games coder at heart, and the thought of helping you make more great games is a real buzz.
So lets all hope for a good 2011, and we'll see you all on the flip side!!
Friday, December 31, 2010
Wednesday, December 22, 2010
Boys Get Ready For The Animation Games
Bikes games are considered as boys games. It can be played individually or with multiple partners. Thus you can enjoy these games with your friends also. When youngsters play bike games then they feel they are riding bike. Boys like this game as they love the speed and difficulties which appear on the way of reaching the target. This builds lot of excitement and craze among them. When we play racing games then we always have an intention to reach first which makes the game more thrilling and exciting.
Creators created these games to attract which everyone wishes to play it. Creators used excellent graphics as well as 3D and 2D animation in bikes games. They have used 3D effect in games in order to protect the eyes of the player. In fact they give superb background music in game. In the game, modification of bikes is really cool. Bike games give the option to choose attractive bikes from the selective options. In games locations are very attractive. They actually bring lots of excitement and originality in game.
Almost every guy is crazy about bikes. That is why bikes games attract them so much. Bike riding is a real passion of guys and they just love it. On internet you will get all kind of bike games. You just have to go through simple downloading process. Then what are you waiting for just access internet at home and download this fantastic game. and there are few bike games which can be played online too.
Creators created these games to attract which everyone wishes to play it. Creators used excellent graphics as well as 3D and 2D animation in bikes games. They have used 3D effect in games in order to protect the eyes of the player. In fact they give superb background music in game. In the game, modification of bikes is really cool. Bike games give the option to choose attractive bikes from the selective options. In games locations are very attractive. They actually bring lots of excitement and originality in game.
Almost every guy is crazy about bikes. That is why bikes games attract them so much. Bike riding is a real passion of guys and they just love it. On internet you will get all kind of bike games. You just have to go through simple downloading process. Then what are you waiting for just access internet at home and download this fantastic game. and there are few bike games which can be played online too.
Friday, December 10, 2010
Player - Avatar Symbiosis
In a recently released paper, Jeroen D. Stout (creator of Dinner Date) proposes an interesting theory on the relashionship between player and avatar. It is related to the things that have been discussed previous post about immersion, so I felt it was relevant to bring it up. The full paper can be gotten from here. I will summarize the ideas a bit below, but I still suggest all to read the actual paper for more info!Most modern theorists of the mind agree that it is not single thing, but a collection of processes working in unison. What this means is that there is no exact place where everything comes together, but instead the interaction between many sub-systems give rise to what we call consciousness. The most clear evidence of this is in split brain patients, where the two brain-halves pretty much form two different personalities when unable to communicate.
This image of a self is a not fixed thing though and it is possible to change. When using a tool for a while it often begins to feel like an extension of ourself, thus changing ones body image. We go from being "just me" to be being "me with hammer". When the hammer is put down, we return to the old previous body image of just being "me". I have described an even clearer example of this in a previous post, where a subject perceives a sense of touch as located at a rubber hand. Research have shown that this sort of connection can get quite strong. If one threatens to drop a heavy weight or similar on the artificial body part (eg the rubber hand), then the body reacts just like it would to any actual body part.
What this means for games is that it is theoretically possible for the player form a very strong bond with the avatar, and in a sense become the avatar. I discuss something similar in this blog post. What Jeroen now purposes is that one can go one step further and make the avatar autonomously behave in a way that the players will interpret has their own will. This is what he calls symbiosis. Instead of just extending the body-image, it is the extension of the mind. Quite literally, a high level of symbiosis means that part of your mind will reside in the avatar.
A simple example would be that if player pushes a button, making the avatar jump, players feel as if they did the jumping themselves. I believe that this sort of symbiosis already happens in some games, especially noticeable when the avatar does not directly jump but has some kind of animation first. When the player-avatar symbiosis is strong this sort of animation does not feel like some kind of cut scene, but as a willed action. Symbiosis does not have to be just about simple actions like jumping though, but can be more complex actions, eg. assembling something, and actions that are not even initiated by the player, eg. picking up an object as the player pass by it. If symbiosis is strong then the player should feel that "I did that" and not "the avatar did that" in the previous examples. The big question is now how far we can go with this, and Jeroen suggests some directions on how to research this further.
Having more knowledge on symbiosis would be very useful to make the player feel immersed in games. It can also help solving the problem of inaccurate input. Instead of doing it the Trespasser way and add fine-control for every needed body joint, focus can lie on increasing the symbiosis and thus allowing simply (or even no!) input be seen by players as their own actions. This would make players feel as part of a virtual world without resorting to full-body exo-skeletons or similar for input. Another interesting aspect of exploring this further is that it can perhaps tell us something about our own mind. Using games to dig deeper into subjects like free will and consciousness is something I feel is incredibly exciting.
Thursday, December 2, 2010
Tech feature: Light Masking
So just wanted to give a quick info on a brand new feature: light box masks.
When placing lights in some rooms, it is common that light bleeds through walls, and show up in other rooms close by. The obvious way to fix this is to add shadows, but shadows can be pretty expensive (especially for point lights), so it is not often a viable solution. In Amnesia we solved this through careful placement, yet bleeding can be seen in some places.
To fix this I added a new feature that is able to limit the lights range with a box. This way the light can cast light as normal but is cut off before reaching an adjacent area. This pretty much does the job of shadows, but is much cheaper.
It turned out to be pretty simple to implement as well. In the renderer, different geometrical shapes are used to render lights (spheres for point lights and pyramids for spots) which make sure the light only affects needed pixels. To implement the masking, these shapes where simply exchanged for a box and then with some small shader changes it all worked.
Without masking:
With mask:
When placing lights in some rooms, it is common that light bleeds through walls, and show up in other rooms close by. The obvious way to fix this is to add shadows, but shadows can be pretty expensive (especially for point lights), so it is not often a viable solution. In Amnesia we solved this through careful placement, yet bleeding can be seen in some places.
To fix this I added a new feature that is able to limit the lights range with a box. This way the light can cast light as normal but is cut off before reaching an adjacent area. This pretty much does the job of shadows, but is much cheaper.
It turned out to be pretty simple to implement as well. In the renderer, different geometrical shapes are used to render lights (spheres for point lights and pyramids for spots) which make sure the light only affects needed pixels. To implement the masking, these shapes where simply exchanged for a box and then with some small shader changes it all worked.
Without masking:
With mask:
Wednesday, December 1, 2010
Bye, bye Pre-Pass lighting
I have an announcement to make.
I am dumping pre-pass lighting.
A couple of weeks ago I started to remaking the renderer from a deferred shader to a pre-pass lighting one. Directly after implementing it, I wrote this post. At first, pre-pass lighting sounded great: faster light rendering and more variation in materials. Having seen that companies such as Crytek and Insomniac Games used it, I thought it would be the next logical step to take.
However, even as implemented it, the problems began. The first one was that specular lighting has to be made through hacks or something that makes it closer to deferred lighting. The next was that implementation become more messy. I suddenly needed to redraw all objects in two separate passes and this made the material and shader code harder to maintain. Normal deferred shading has this nice design where all material info is rendered in one pass to one buffer. But in pre-pass lighting, this spread out and makes more annoying to add new stuff and to update existing.
Still, I stuck to it, because I was sure that the speed and material variety would make up for it. One of the features I was looking forward to was making more interesting decals, with normals and such. Since only the light data is written to an accumulation buffer I thought this would allow me to easily put more effects to the decals. However, I quickly realized that I had been quite foolish and not considered that pretty much every interesting part of a materials is added when lighting it. The surface normals, specular, etc are all baked into the light data. So I ended up doing tricks that I could actually work with normal deferred shading.
So what ended up with was lighting of worse quality, compared deferred shading, and with no more room for special effects. Still, this rendering is much faster right? Well, I did some checks which I collected in this post. It turns out that pre-pass is actually slower unless in very specific situations. None of the improvements I was hoping for turned out to be true.
Still, I stuck to it. I am not sure why, but I guess I did not want to face the truth after having put so much time and effort into it. Going back to the old renderer was something I did not want to consider.
Then last week, as I was starting making undergrowth for the terrain, it suddenly happened. I realized that I had to render the vegetation twice, creating more overdraw and making it a lot more cumbersome to implement. At this point I decided that I should seriously consider going back to the old deferred renderer. What I was most worried about about was that it would exclude us from consoles, but I found out that games like Burnout Paradise used a deferred shader too, and assuring me that consoles would still be possible to do.
This post by Adrian Stone, with an in-depth discussion on the subject, sealed the deal for me and I got to work with going back to deferred shading. I had actually come across Adrian's post before when implemented pre-pass lighting, but never read it carefully. I guess it would not had made me stop then since I wanted to check it out myself, but it is interesting to see how one can convince oneself that something is correct, to the point of avoid contradictory sources. This is a very important lesson to learn and one should always be prepared to reconsider and "kill your darlings".
Right now I have fully implemented the deferred shader again and even updated it a bit too. For one thing, I fixed so the decals support all the feature I had in the pre-pass lighting shader. Since we are aiming for a little higher specs (shader model 3 or 4) for our next game, I took that into account and was able to add some other fun stuff. Examples are colored specular and saving the emission in the g-buffer (allowing to cheaply to a variety of effects).
I am really happy to back to the old renderer and now that I am adding new features things are going a lot smoother. The pre-pass renderer was not all in vain though. I cleaned up the rendering code a lot and it also made me rethink how some features could be added. Last but not least, it also reminded me that I should never get too attached to an idea.
I am dumping pre-pass lighting.
A couple of weeks ago I started to remaking the renderer from a deferred shader to a pre-pass lighting one. Directly after implementing it, I wrote this post. At first, pre-pass lighting sounded great: faster light rendering and more variation in materials. Having seen that companies such as Crytek and Insomniac Games used it, I thought it would be the next logical step to take.
However, even as implemented it, the problems began. The first one was that specular lighting has to be made through hacks or something that makes it closer to deferred lighting. The next was that implementation become more messy. I suddenly needed to redraw all objects in two separate passes and this made the material and shader code harder to maintain. Normal deferred shading has this nice design where all material info is rendered in one pass to one buffer. But in pre-pass lighting, this spread out and makes more annoying to add new stuff and to update existing.
Still, I stuck to it, because I was sure that the speed and material variety would make up for it. One of the features I was looking forward to was making more interesting decals, with normals and such. Since only the light data is written to an accumulation buffer I thought this would allow me to easily put more effects to the decals. However, I quickly realized that I had been quite foolish and not considered that pretty much every interesting part of a materials is added when lighting it. The surface normals, specular, etc are all baked into the light data. So I ended up doing tricks that I could actually work with normal deferred shading.
So what ended up with was lighting of worse quality, compared deferred shading, and with no more room for special effects. Still, this rendering is much faster right? Well, I did some checks which I collected in this post. It turns out that pre-pass is actually slower unless in very specific situations. None of the improvements I was hoping for turned out to be true.
Still, I stuck to it. I am not sure why, but I guess I did not want to face the truth after having put so much time and effort into it. Going back to the old renderer was something I did not want to consider.
Then last week, as I was starting making undergrowth for the terrain, it suddenly happened. I realized that I had to render the vegetation twice, creating more overdraw and making it a lot more cumbersome to implement. At this point I decided that I should seriously consider going back to the old deferred renderer. What I was most worried about about was that it would exclude us from consoles, but I found out that games like Burnout Paradise used a deferred shader too, and assuring me that consoles would still be possible to do.
This post by Adrian Stone, with an in-depth discussion on the subject, sealed the deal for me and I got to work with going back to deferred shading. I had actually come across Adrian's post before when implemented pre-pass lighting, but never read it carefully. I guess it would not had made me stop then since I wanted to check it out myself, but it is interesting to see how one can convince oneself that something is correct, to the point of avoid contradictory sources. This is a very important lesson to learn and one should always be prepared to reconsider and "kill your darlings".
Right now I have fully implemented the deferred shader again and even updated it a bit too. For one thing, I fixed so the decals support all the feature I had in the pre-pass lighting shader. Since we are aiming for a little higher specs (shader model 3 or 4) for our next game, I took that into account and was able to add some other fun stuff. Examples are colored specular and saving the emission in the g-buffer (allowing to cheaply to a variety of effects).
I am really happy to back to the old renderer and now that I am adding new features things are going a lot smoother. The pre-pass renderer was not all in vain though. I cleaned up the rendering code a lot and it also made me rethink how some features could be added. Last but not least, it also reminded me that I should never get too attached to an idea.
Subscribe to:
Posts (Atom)