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.
Showing posts with label yoyo. Show all posts
Showing posts with label yoyo. Show all posts
Sunday, February 27, 2011
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.
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.
Friday, December 31, 2010
Goodbye 2010. Hello 2011.
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!!
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!!
Sunday, November 14, 2010
Language features...
So at what point do language features become a hindrance? Well having learnt using BASIC, I know what the features of other languages has allowed me to do. SO lets have a little lookie and see what these features have added.
First up: TYPES.
I remember coding on a ZX Spectrum and being incredibly jealous of the BBC as they had INTEGER variable types. This option allowed your code to run MUCH faster than using the standard floating point number variable. Now, back then ALL floating point code was done through emulation and so was much, much slower. Nowadays, doubles (which is what Game Maker uses) is all done in hardware, so why do we care? Well first, it's not always done in hardware, so we're back to the CPU doing emulation and that's really bad. In fact, even is we're doing this on a machine with hardware for doubles, integer computation is simply faster, what with the multiple execution pipes and single cycle execution on most hardware, if you can do it in integers, you should at least have the option. After all, how many FOR loops really need floating point? Lastly... How much would this really affect folk who don't care? I'd argue not much. For example...
compare that to something like...
I'd say if you don't want to use them, it's not exactly going to bother you, but if you want to declare the variable (with INT, DIM, VAR or whatever we end up using), then you will not only get a speed boost, but it'll help you debug your code because you KNOW it can't be a fraction! That can be a valuable bit of info.
Second: STRUCTS
I'm wondering how I can even begin to say how important this is. Lets give a couple of examples. (this isn't proper code, so don't jump on errors please!)
Now, in this little sample, we need multiple arrays to deal with storing all the bits of information I need for processing later. This is pretty common when coding and having multiple, dynamically resizing arrays is a nasty thing. So what can we do to improve this? Welcome to the world of structures.
(I'm deliberately avoiding adding any types here... but you can do)
Now... how I'd hook all this up is unclear, but having a single object (much like a standard, but very lightweight Game Maker object) with variables you can access can mean you can contain data in a single packet. This means you no longer have lots of dynamically resizing arrays (which is always a good thing), but if we are to expand what can be passed into functions, it also allows you to pass a lot of data in a single blob, removing lots of parameter stacking. This is all good, not only from a performance standpoint, but simplifies your think about about variables you're dealing with. No longer are you thinking about lots of individual variables, remembering which ones do what, you now have a single variable with all the information you need and this again simplifies your work.
Structures are good. Structures are VERY good.
Third: FUNCTIONS.
Being able to breakup large functions into smaller common parts is nice, not just from a readability standpoint, but for allowing you to reuse code better. It's a very good skill to learn; making code general so you can use the same function over and over again. This not only teaches coding flexibility, but allows you to start to make an API for certain features. Good APIs are a real skill, and one thats vital to learn if you ever want to progress as a coder. All that said, if you don't really care about coding and it's simply a means to an end, then being able to break your functions up does make code just simpler. Having a function that is pages and pages long is horrible to maintain, and will introduce bugs, so this would also help you reduce bugs as each function is smaller, and easer to think about. So again, its another good one.
Fourth: CONSTANTS
Simple one. PROPER constants. This is mainly an internal thing... but allowing you to define them in code would be great.
Now... I'd also say there are features that would just confuse most folk so we should just avoid them. Things like anonymous delegates, the C++ << style operator, operator overloading, templates, and even to some extent #defines; these are all simply not required inside GML. While I do like #defines, I think they can be so badly used, I'd simply avoid them.
EDIT: Oh... and the other thing I'd LOVE to add; argument passing to the instance_create(x,y,obj) function. This would be brilliant. This would allow you to do stuff like this...
I could have used this quite a few times already....
First up: TYPES.
I remember coding on a ZX Spectrum and being incredibly jealous of the BBC as they had INTEGER variable types. This option allowed your code to run MUCH faster than using the standard floating point number variable. Now, back then ALL floating point code was done through emulation and so was much, much slower. Nowadays, doubles (which is what Game Maker uses) is all done in hardware, so why do we care? Well first, it's not always done in hardware, so we're back to the CPU doing emulation and that's really bad. In fact, even is we're doing this on a machine with hardware for doubles, integer computation is simply faster, what with the multiple execution pipes and single cycle execution on most hardware, if you can do it in integers, you should at least have the option. After all, how many FOR loops really need floating point? Lastly... How much would this really affect folk who don't care? I'd argue not much. For example...
i = 1.12;
b = 12;
compare that to something like...
INT b;
i = 1.12;
b = 12;
I'd say if you don't want to use them, it's not exactly going to bother you, but if you want to declare the variable (with INT, DIM, VAR or whatever we end up using), then you will not only get a speed boost, but it'll help you debug your code because you KNOW it can't be a fraction! That can be a valuable bit of info.
Second: STRUCTS
I'm wondering how I can even begin to say how important this is. Lets give a couple of examples. (this isn't proper code, so don't jump on errors please!)
BaddieID[i] = id
BaddieGridX[i] = round( id.x/16);
BaddieGridY[i] = round( id.y/16);
BaddieType[i] = enemytype;
BaddieParent[i] = id.parent;
Now, in this little sample, we need multiple arrays to deal with storing all the bits of information I need for processing later. This is pretty common when coding and having multiple, dynamically resizing arrays is a nasty thing. So what can we do to improve this? Welcome to the world of structures.
struct SBaddie{
id,
gridx,
gridy,
type
parent
};
baddie.id = id
baddie.x = round( id.x/16);
baddie.y = round( id.y/16);
baddie.type = enemytype
baddie.parent = parent;
Baddies[i] = baddie;
(I'm deliberately avoiding adding any types here... but you can do)
Now... how I'd hook all this up is unclear, but having a single object (much like a standard, but very lightweight Game Maker object) with variables you can access can mean you can contain data in a single packet. This means you no longer have lots of dynamically resizing arrays (which is always a good thing), but if we are to expand what can be passed into functions, it also allows you to pass a lot of data in a single blob, removing lots of parameter stacking. This is all good, not only from a performance standpoint, but simplifies your think about about variables you're dealing with. No longer are you thinking about lots of individual variables, remembering which ones do what, you now have a single variable with all the information you need and this again simplifies your work.
Structures are good. Structures are VERY good.
Third: FUNCTIONS.
Being able to breakup large functions into smaller common parts is nice, not just from a readability standpoint, but for allowing you to reuse code better. It's a very good skill to learn; making code general so you can use the same function over and over again. This not only teaches coding flexibility, but allows you to start to make an API for certain features. Good APIs are a real skill, and one thats vital to learn if you ever want to progress as a coder. All that said, if you don't really care about coding and it's simply a means to an end, then being able to break your functions up does make code just simpler. Having a function that is pages and pages long is horrible to maintain, and will introduce bugs, so this would also help you reduce bugs as each function is smaller, and easer to think about. So again, its another good one.
Fourth: CONSTANTS
Simple one. PROPER constants. This is mainly an internal thing... but allowing you to define them in code would be great.
Now... I'd also say there are features that would just confuse most folk so we should just avoid them. Things like anonymous delegates, the C++ << style operator, operator overloading, templates, and even to some extent #defines; these are all simply not required inside GML. While I do like #defines, I think they can be so badly used, I'd simply avoid them.
EDIT: Oh... and the other thing I'd LOVE to add; argument passing to the instance_create(x,y,obj) function. This would be brilliant. This would allow you to do stuff like this...
w = instance_create( 10, 10, cBullet, "smallbang.wav", false, sSprite );
I could have used this quite a few times already....
Monday, October 11, 2010
Writing cross platform code...
You know, it occurred to me that some folk may find it interesting to see how we manage to port the Game Maker runner to other platforms, so I thought... Let's write about it. I then thought, well... it's not specific to the runner, Russell and I have been doing this for almost 20 years. I'll use the runner as the example, but the method holds true no matter what you do.
So the first thing you have to get into the habit of doing is abstraction. This doesn't mean layer upon layer of code and calls, but a very thin level that can remove any real platform dependence. Now, since I'm a graphics guy at heart, I'll talk about abstracting graphics code, but the theory is the same be it networking, audio or a basic file system. So here goes...
When we got the C++ runner it was all tangled up with windows specific code, from DirectX to MFC (Windows Foundation Classes), so the first thing we had to do was remove all the specifics, well... as much as we could. We spent months removing MFC and started using a simple WIN32 interface as this is much simpler and gave us control over the main loop which was vital to actually running on other platforms. We also started to add a thin layer between Game Maker, and DirectX. This meant that instead of calling D3D directly, it now called one of our functions, and we called D3D. This was done throughout the code, from creating textures and surfaces, to rendering lines and triangles.
The first thing we did was takeover the screen/canvas creation. This means we're now creating the device and have access to all the normal D3D functions inside our little world, and as far as Game Maker knows, it's simply asked to OpenWindow().
Next, we want to get something drawn, so we change all the rendering calls to a call to our triangle rendering instead so we now have access to all the vertices and can draw flat/coloured triangles where all the sprites would be. Most of these changes are pretty straight forward, and are a simple search/replace. Change DrawPrimitive() into a DrawArray(). Once that's done, we can start to change ALL the primitive types from being D3D specific, into our own custom values. So rather than using D3DPT_TRIANGLELIST, we now use our own ePrimType_TRILIST. So far so good.
Now there's lots of drawing code inside Game Maker, fonts, sprites, tiles and backgrounds and so on, and we really don't want to have to rewrite these every time. However, now that we have something that will render triangles in an abstracted way, we can rewrite them once, into OUR format. So the font rendering will now make vertices into our buffers, and use an ePrimType_TRILIST to draw them. Hay-Presto! The font code no longer needs D3D to render things. But what about the textures it uses?
Well, we created a new CreateTexture() call as well, which returns a simple void* which then allowed the internals of texture management to do whatever it liked. It also has the advantage that the texture system can now resize/resample textures if it liked, as Game Maker will never know; very handy when memory is tight! After all, Game Maker doesn't really care what the call is, as long as it can set the texture, so this works well.
So now we have the ability to render primitives, and create/change textures, so what else? Well there are lots of render states to do, so we'll need to abstract them as well. This means things like the D3D culling renderstate (i.e. D3DCULL_CW) now changes to eCull_CounterClockwise and so on, until every state, every D3D call has been abstracted away into a new interface. But why bother? Well, for a start it means that we don't have to include the D3D headers on other platforms! D3D obviously has windows specific includes internally and that would end up being a nightmare, but my abstracting things a little, the other platforms have become much simpler to port to.
And, although it seems odd... D3D is in effect our first port. Game Maker now runs using YoYo's interface and API, which then has a set of classes which translate things into D3D calls (which has been upgraded to DX9 BTW). Theres lots of other functions which we abstracted, matrix operations, viewports, grabbing screens, surfaces and render targets and the like, but at the end of it, we have a clean, non-D3D interface. And we can now port it easily.
Now, this method is true of any platform specific API you care to mention. We also changed the Audio system on windows to XAudio2 (the latest DirectX audio system), and we did this by simply having calls to Load a sample and return a void* which Game Maker can then use as a handle to the sound,midi or MP3.
Now... the real trick here is to get most of the code to be platform independent. Although things like fonts draw to the screen, they don't have to know anything about the underlying API. All it wants to do is set a texture, some blend modes, and then give you some vertex data. The interface then handles the rest.
Once you have a set of files that ARE platform dependent, you can then port these to any system you like. The real win for this, is that any new feature you add to Game Maker, will usually appear on all the platforms at once. Only the most obscure thing like grabbing screen rects without using the CPU (the PSP needs this) will have to be hand crafted. But other things like optimising font rendering will be the same on all platforms, and only require to be written once.
So, for the record.... we now have a Win32 DirectX 9 render, and PSP render, and an iOS OpenGL ES render. Making a Mac OpenGL render would now be trivial as the OpenGL ES is actually a subset of it, so we can actually ADD features!
As you can see, making a true platform independent bit of code is fairly simple, as long as you think ahead and don't try to be too clever. It also means that all systems benefit from any core changes, and porting to another system can sometimes be achieved rapidly if required.
Now, porting to something like iOS is interesting because your supposed to use Objective C, but in reality... anything that can call C++, can use the whole runner. We use Objective C to create the display, flip the screen and get the touch input, but everything else is done in the normal way using the C++ runner. Any system that allows C++ code, can be done like that making it a trivial port (i.e. simple to do, but takes a little time). If a platform doesn't allow calls to C++ (like XNA), then this means you have to write directly in the provided language, and that then becomes a monster task to rewrite the whole engine. It also means any improvements to the C++ code must then be replicated to the new system, which isn't very nice.
The Game Maker C++ Runner is now very portable thanks to the abstraction it's received, and we also know it's very hardware independent as it runs on Intel, MIPS and ARM cpus. Different CPUs can also give some headaches as byte order can flip, and many systems don't let you access INTs on non-INT boundaries and so on. We've now been through all of that, and now have a very portable engine which is looking good for the future.
So there you go... This is how we ported the runner over, and how other platforms suddenly seem to spring up. All that's really missing from it are some of the features we removed initially to get it all working, and they will come back in time, and one day, the C++ runner will be THE way to run Game Maker games.
So the first thing you have to get into the habit of doing is abstraction. This doesn't mean layer upon layer of code and calls, but a very thin level that can remove any real platform dependence. Now, since I'm a graphics guy at heart, I'll talk about abstracting graphics code, but the theory is the same be it networking, audio or a basic file system. So here goes...
When we got the C++ runner it was all tangled up with windows specific code, from DirectX to MFC (Windows Foundation Classes), so the first thing we had to do was remove all the specifics, well... as much as we could. We spent months removing MFC and started using a simple WIN32 interface as this is much simpler and gave us control over the main loop which was vital to actually running on other platforms. We also started to add a thin layer between Game Maker, and DirectX. This meant that instead of calling D3D directly, it now called one of our functions, and we called D3D. This was done throughout the code, from creating textures and surfaces, to rendering lines and triangles.
The first thing we did was takeover the screen/canvas creation. This means we're now creating the device and have access to all the normal D3D functions inside our little world, and as far as Game Maker knows, it's simply asked to OpenWindow().
Next, we want to get something drawn, so we change all the rendering calls to a call to our triangle rendering instead so we now have access to all the vertices and can draw flat/coloured triangles where all the sprites would be. Most of these changes are pretty straight forward, and are a simple search/replace. Change DrawPrimitive() into a DrawArray(). Once that's done, we can start to change ALL the primitive types from being D3D specific, into our own custom values. So rather than using D3DPT_TRIANGLELIST, we now use our own ePrimType_TRILIST. So far so good.
Now there's lots of drawing code inside Game Maker, fonts, sprites, tiles and backgrounds and so on, and we really don't want to have to rewrite these every time. However, now that we have something that will render triangles in an abstracted way, we can rewrite them once, into OUR format. So the font rendering will now make vertices into our buffers, and use an ePrimType_TRILIST to draw them. Hay-Presto! The font code no longer needs D3D to render things. But what about the textures it uses?
Well, we created a new CreateTexture() call as well, which returns a simple void* which then allowed the internals of texture management to do whatever it liked. It also has the advantage that the texture system can now resize/resample textures if it liked, as Game Maker will never know; very handy when memory is tight! After all, Game Maker doesn't really care what the call is, as long as it can set the texture, so this works well.
So now we have the ability to render primitives, and create/change textures, so what else? Well there are lots of render states to do, so we'll need to abstract them as well. This means things like the D3D culling renderstate (i.e. D3DCULL_CW) now changes to eCull_CounterClockwise and so on, until every state, every D3D call has been abstracted away into a new interface. But why bother? Well, for a start it means that we don't have to include the D3D headers on other platforms! D3D obviously has windows specific includes internally and that would end up being a nightmare, but my abstracting things a little, the other platforms have become much simpler to port to.
And, although it seems odd... D3D is in effect our first port. Game Maker now runs using YoYo's interface and API, which then has a set of classes which translate things into D3D calls (which has been upgraded to DX9 BTW). Theres lots of other functions which we abstracted, matrix operations, viewports, grabbing screens, surfaces and render targets and the like, but at the end of it, we have a clean, non-D3D interface. And we can now port it easily.
Now, this method is true of any platform specific API you care to mention. We also changed the Audio system on windows to XAudio2 (the latest DirectX audio system), and we did this by simply having calls to Load a sample and return a void* which Game Maker can then use as a handle to the sound,midi or MP3.
Now... the real trick here is to get most of the code to be platform independent. Although things like fonts draw to the screen, they don't have to know anything about the underlying API. All it wants to do is set a texture, some blend modes, and then give you some vertex data. The interface then handles the rest.
Once you have a set of files that ARE platform dependent, you can then port these to any system you like. The real win for this, is that any new feature you add to Game Maker, will usually appear on all the platforms at once. Only the most obscure thing like grabbing screen rects without using the CPU (the PSP needs this) will have to be hand crafted. But other things like optimising font rendering will be the same on all platforms, and only require to be written once.
So, for the record.... we now have a Win32 DirectX 9 render, and PSP render, and an iOS OpenGL ES render. Making a Mac OpenGL render would now be trivial as the OpenGL ES is actually a subset of it, so we can actually ADD features!
As you can see, making a true platform independent bit of code is fairly simple, as long as you think ahead and don't try to be too clever. It also means that all systems benefit from any core changes, and porting to another system can sometimes be achieved rapidly if required.
Now, porting to something like iOS is interesting because your supposed to use Objective C, but in reality... anything that can call C++, can use the whole runner. We use Objective C to create the display, flip the screen and get the touch input, but everything else is done in the normal way using the C++ runner. Any system that allows C++ code, can be done like that making it a trivial port (i.e. simple to do, but takes a little time). If a platform doesn't allow calls to C++ (like XNA), then this means you have to write directly in the provided language, and that then becomes a monster task to rewrite the whole engine. It also means any improvements to the C++ code must then be replicated to the new system, which isn't very nice.
The Game Maker C++ Runner is now very portable thanks to the abstraction it's received, and we also know it's very hardware independent as it runs on Intel, MIPS and ARM cpus. Different CPUs can also give some headaches as byte order can flip, and many systems don't let you access INTs on non-INT boundaries and so on. We've now been through all of that, and now have a very portable engine which is looking good for the future.
So there you go... This is how we ported the runner over, and how other platforms suddenly seem to spring up. All that's really missing from it are some of the features we removed initially to get it all working, and they will come back in time, and one day, the C++ runner will be THE way to run Game Maker games.
Friday, October 1, 2010
Runner/Progress follow up...
So... a quick reply to a what's been said so far, both here and on the GMC.
(Sorry... another long one)
First and foremost, please remember that while we plan to do great things with GM, it WILL take time. Lots of time. It's not something that will happen overnight, or even over a few months. Some of the "big" improvements may take a year or so to appear. Now this might seem drastic, but let me explain a little... First, YoYo is a reasonably small team, we don't have the 50 developers some games companies have, and that means we have other things to do as well as improve Game Maker itself. If we can get the runner onto lots of platforms we can make more money (for us and the developer), and that lets us hire more folk to do more with Game Maker. So first off we've take a long time to get the runner into a very portable format, and while that meant cutting it back, it also means we can start getting games out on many other platforms.
While doing this, we've obviously noticed many performance issues, some we've fixed, some we've addressed in a small way, and some require extensive rewrites and reorganisation on the code. Let's take the GML interpreter. The original by Mark was a pretty mean beast, functional, but unwieldy. Russell has taken some of the work Mark did and converted it into a virtual machine. This was a massive step, but at the same time a really small one. So instead of having lots of nested C++ code calling code blocks, calling loops, calling functions, calling code blocks and so on, we now have a very simple virtual machine loop. This opens up massive speed ups for the future, but also opens up full script level debugging. Allowing you, for the 1st time to stick a breakpoint on a script line, and then step through the code when the breakpoint is hit. Now... we don't have all the fancy GUI stuff. We have some VERY simple stepping code. Adding the rest into Game Maker will take huge amounts of work. And this is only the beginning of what's needed.
The problem with the current Virtual Machine is that it doesn't really give us the massive speed up we needed. This us because of the way variables and constants are currently handled inside Game Maker. The next monster task for Russell and the VM is to identify the correct "types" and link them with the correct functions. This would stop every Game Maker function having to check to see that the argument it's just been passed is of the right type. Very simple Virtual Machine opcodes like ADD should be a few lines long, but due to the way its arranged just now, it's pretty huge, and every opcode is like that. Over time, this will all be addressed, and GML will sped up massively, way beyond what is currently achieved.
Now, I only explain all this to show just how much work we have to do in the runner to get it up to the speed WE want, never mind the improvements that everyone else wants. Make no mistake, the VM will be huge, but it will take a long time to implement and make the changes to the rest of the runner so that it works the way it should. Now while Russell's doing that, I'll probably be doing other performance stuff, or even just adding functionality back in; as I said, the runner has been stripped bare.
All this means Game Maker won't change overnight. But it will change. Now, none of these things have been prioritised, meaning we may well do some Game Maker stuff well before the huge VM changes, so don't worry too much, but don't expect everything to come at once.
Now as to some of the other issues... Screen Tearing. This is usually done because it allows the game to "flip" screens quicker, it doesn't have to wait for a vertical blank and will present a more even game experience. When you're in a window, you don't really have a lot of say in how flipping is handled, but when you're in full-screen mode you can tell it not to tear. However... if your game drops from 60fps to 59, then you don't get 59, you get 30. It's pretty harsh. Now all this said... We can fix the tearing in future versions; preferably as an option. The ports don't "rip", because we modify each game we tune it to a specific (manageable) frame rate, and then it's tied to that. so 60fps or 30fps. In fact, it's a TRC failure on the PSP to flip outside a Vertical Blank.
Full screen BLUR. This is tricky. Many drivers override whatever you select. But we can see the need so will try.
Win98... sorry, it's dead. I loved Win98 se (MUST be the SE edition!), but then I also loved the Amiga, but both are dead, time to move on. :)
File size... It's not a huge concern in today's broadband world, but we'll always try and reduce when we can. But when most games are hundreds of Mbs in size, GM games are tiny by comparison, so it's not a worry.
OGG. Yes, when we have time to do it, OGG will be built in.
The rendering inside the C++ runner has been updated to DirectX9, not DirectX8. Audio has been totally rewritten, although it needs completed. Many functions no longer work and have to be re-implemented.
Networking has been removed from the C++ runner. It was an old dated monster that was in there (Direct Play). We will get round to doing a totally new networking system, but it's pretty low on the list.
No one asked about this, but it's actually important. point/texel sampling has been unified. The original code added little hacks to every sprite drawn to get correct texel selection. This slowed everything down and was a nightmare across platform. This has all been removed and done properly.
There's two reasons we won't add backwards file saving. First, as a company we want people to buy the new version so we add lots of new features to encourage you to swap. And second, because we've added new features, you can't save as an old version because those features don't exist. Things fall apart pretty quickly from there...
Graphically linking objects...yes could do. Not high on the list... but could do.
Vector collision code. Again, yes... could do. But there's lots of other stuff to "fix", so again, not high on the list.
External DLL's. While I'd love it so you didn't NEED external DLL's, we'd be stupid to assume we knew everything and thought we'd added all you'd ever needed. There's too many "what-ifs". We WILL incorporate some of the features of the most popular ones (one day.... over the rainbow), as that just makes sense... but what if you wanted to make a 3D glasses version for that new toaster that has a screen and windows Windows? Well... we won't be supporting that unless 100million people buy that toaster, until then use an external DLL.
Please stop calling me "Dailly", you're not my old school teacher and I've not been "bad". It's rude. :)
Lastly... remember that Russell and I have only really been part of YoYo for a short time, and as Sandy said at the time we're still a limited resource. We've had other priorities, some of which you know about and some you don't (and we're not about to tell you yet!), We can't do everything overnight. It's getting better, but it'll take time to get everything the way we want it.
Okay...REALLY lastly. We do read the GMC when we can, but there's simply too much there for us to keep track of everything, but when something "big" comes to light we will try and respond if we have time.
Now... as it's almost 10pm. I'm off to have my tea if you don't mind! Don't say we don't work hard here! :)
(Sorry... another long one)
First and foremost, please remember that while we plan to do great things with GM, it WILL take time. Lots of time. It's not something that will happen overnight, or even over a few months. Some of the "big" improvements may take a year or so to appear. Now this might seem drastic, but let me explain a little... First, YoYo is a reasonably small team, we don't have the 50 developers some games companies have, and that means we have other things to do as well as improve Game Maker itself. If we can get the runner onto lots of platforms we can make more money (for us and the developer), and that lets us hire more folk to do more with Game Maker. So first off we've take a long time to get the runner into a very portable format, and while that meant cutting it back, it also means we can start getting games out on many other platforms.
While doing this, we've obviously noticed many performance issues, some we've fixed, some we've addressed in a small way, and some require extensive rewrites and reorganisation on the code. Let's take the GML interpreter. The original by Mark was a pretty mean beast, functional, but unwieldy. Russell has taken some of the work Mark did and converted it into a virtual machine. This was a massive step, but at the same time a really small one. So instead of having lots of nested C++ code calling code blocks, calling loops, calling functions, calling code blocks and so on, we now have a very simple virtual machine loop. This opens up massive speed ups for the future, but also opens up full script level debugging. Allowing you, for the 1st time to stick a breakpoint on a script line, and then step through the code when the breakpoint is hit. Now... we don't have all the fancy GUI stuff. We have some VERY simple stepping code. Adding the rest into Game Maker will take huge amounts of work. And this is only the beginning of what's needed.
The problem with the current Virtual Machine is that it doesn't really give us the massive speed up we needed. This us because of the way variables and constants are currently handled inside Game Maker. The next monster task for Russell and the VM is to identify the correct "types" and link them with the correct functions. This would stop every Game Maker function having to check to see that the argument it's just been passed is of the right type. Very simple Virtual Machine opcodes like ADD should be a few lines long, but due to the way its arranged just now, it's pretty huge, and every opcode is like that. Over time, this will all be addressed, and GML will sped up massively, way beyond what is currently achieved.
Now, I only explain all this to show just how much work we have to do in the runner to get it up to the speed WE want, never mind the improvements that everyone else wants. Make no mistake, the VM will be huge, but it will take a long time to implement and make the changes to the rest of the runner so that it works the way it should. Now while Russell's doing that, I'll probably be doing other performance stuff, or even just adding functionality back in; as I said, the runner has been stripped bare.
All this means Game Maker won't change overnight. But it will change. Now, none of these things have been prioritised, meaning we may well do some Game Maker stuff well before the huge VM changes, so don't worry too much, but don't expect everything to come at once.
Now as to some of the other issues... Screen Tearing. This is usually done because it allows the game to "flip" screens quicker, it doesn't have to wait for a vertical blank and will present a more even game experience. When you're in a window, you don't really have a lot of say in how flipping is handled, but when you're in full-screen mode you can tell it not to tear. However... if your game drops from 60fps to 59, then you don't get 59, you get 30. It's pretty harsh. Now all this said... We can fix the tearing in future versions; preferably as an option. The ports don't "rip", because we modify each game we tune it to a specific (manageable) frame rate, and then it's tied to that. so 60fps or 30fps. In fact, it's a TRC failure on the PSP to flip outside a Vertical Blank.
Full screen BLUR. This is tricky. Many drivers override whatever you select. But we can see the need so will try.
Win98... sorry, it's dead. I loved Win98 se (MUST be the SE edition!), but then I also loved the Amiga, but both are dead, time to move on. :)
File size... It's not a huge concern in today's broadband world, but we'll always try and reduce when we can. But when most games are hundreds of Mbs in size, GM games are tiny by comparison, so it's not a worry.
OGG. Yes, when we have time to do it, OGG will be built in.
The rendering inside the C++ runner has been updated to DirectX9, not DirectX8. Audio has been totally rewritten, although it needs completed. Many functions no longer work and have to be re-implemented.
Networking has been removed from the C++ runner. It was an old dated monster that was in there (Direct Play). We will get round to doing a totally new networking system, but it's pretty low on the list.
No one asked about this, but it's actually important. point/texel sampling has been unified. The original code added little hacks to every sprite drawn to get correct texel selection. This slowed everything down and was a nightmare across platform. This has all been removed and done properly.
There's two reasons we won't add backwards file saving. First, as a company we want people to buy the new version so we add lots of new features to encourage you to swap. And second, because we've added new features, you can't save as an old version because those features don't exist. Things fall apart pretty quickly from there...
Graphically linking objects...yes could do. Not high on the list... but could do.
Vector collision code. Again, yes... could do. But there's lots of other stuff to "fix", so again, not high on the list.
External DLL's. While I'd love it so you didn't NEED external DLL's, we'd be stupid to assume we knew everything and thought we'd added all you'd ever needed. There's too many "what-ifs". We WILL incorporate some of the features of the most popular ones (one day.... over the rainbow), as that just makes sense... but what if you wanted to make a 3D glasses version for that new toaster that has a screen and windows Windows? Well... we won't be supporting that unless 100million people buy that toaster, until then use an external DLL.
Please stop calling me "Dailly", you're not my old school teacher and I've not been "bad". It's rude. :)
Lastly... remember that Russell and I have only really been part of YoYo for a short time, and as Sandy said at the time we're still a limited resource. We've had other priorities, some of which you know about and some you don't (and we're not about to tell you yet!), We can't do everything overnight. It's getting better, but it'll take time to get everything the way we want it.
Okay...REALLY lastly. We do read the GMC when we can, but there's simply too much there for us to keep track of everything, but when something "big" comes to light we will try and respond if we have time.
Now... as it's almost 10pm. I'm off to have my tea if you don't mind! Don't say we don't work hard here! :)
Wednesday, September 29, 2010
Game Maker runner performance
I’d like to briefly address some of the concerns as to performance and what exactly we’re doing for the future of Game Maker.
First there have been several posts about the current Delphi runner and how bad it is. While this is a little exaggerated there are indeed several problems with it. The first thing any developer has to realise is that a platform will never be fully to his liking, ever. DirectX has lots of things I really hate about it, stuff that slows me down and makes my code ugly, but I don’t just sit back and complain about it, or simply demand Microsoft do something about their “core gaming tech” or I’ll swap to OpenGL, I work with and around the problem to get what I need. All good coders do this because every platform is flawed.
That said… there are some short comings inside Game Maker’s API, some of them I consider fairly nasty. Aragon1029 posted some tests on the GMC so I’m going to start out by looking at these. I’m not completely sure what “some” of them are about, but I’ll address them as best I can.
The fact that .EXE’s are made read-only (I think this is what he means) is something we can look at, but you really shouldn’t be changing the .exe so I’m not sure why this is an issue to anyone, and it’s certainly something you can get round easily for now.
The decompiler. We will look at it in the next version, but anything we do is fundamentally crackable; eventually. We’ll see what we can come up with.
Crashes. We need reproducible tests and bug reports. We have a bug reporting system, if something’s causing problems, use it. Mac users will tell you that there are regular updates for them, and once we get the same system in place for windows, you’ll get that too!
File access. While I’ve no idea why you would want to read/write very large files in GM, I can see that it’s slow. The main reason for this is reading/writing to any file system a byte at a time is ALWAYS slow, no matter what language you’re using. It needs a “block” read/write badly. This will be added in later versions. What we’ll probably do is some sort of very simple memory allocation with peek/poke access, and then let you save “blocks” from this. This would allow fast access to data and allow nice reading/writing of “types” from files, particularly if we allow something like Peek_Float(memory_handle,offset), Peek_String(memory_handle, offset) etc… Oh, and no... the program hasn't crashed when it's "not responding", it's simply not responding because it's taking a long time. Leave it for a while and it will eventually come back. This is what happens if you sit in a large loop without letting windows in.
The Format. Not sure what he means about this one…??? We do want to make some changes to allow it to be source controlled however.
Dragging the window = frozen game “while” dragging the window.. This is a windows issue. It doesn’t give you messages while it’s being dragged. So the timing stops. All windows apps experience this… *shrug*
The “varied” parsing of GML ( a=0 or a:=0 etc..). Okay, this is a feature of GML. It’s primarily a learning language so is very forgiving of these, kinds of things. In some respects I’d love to make it much stricter, in another, we don’t want to hinder beginners by making it hard to get up and running. However it IS possible to have a “PRO” parsing mode, so that when you want strict parsing, you can have it. But this is something we will think long and hard about so that we don’t affect beginners. At the end of the day, a lot of our customers are schools and universities that teach to non-technical students, so we have to be very careful about what we do with this.
C/Delphi string handling. [0] or [1]…. Being a programmer, everything starts at 0 for me. I suspect we’ll standardise this in the future, one way or another. Outside of that should throw an error. It’s hardly a show stopper though….
Font rendering. First the example given isn’t terribly realistic, just printing row upon row of outline text isn’t exactly common in games, and if it was slow, you’d simply do it a different way. That said, font rendering is definitely slow. We have already seriously sped this up inside the C++ runner, and I expect this to get faster in the future when formatting is all done on the fly. However… a full screen of “outlined” text will always be slow, but we might be able to speed it up more by giving dedicated GML commands to actually draw a full outlined font making it faster yet. So there’s several things we can do here, although the main culprit has been changed in the C++ one already. Speaking of fonts, there was actually a very good talk at SigGraph a few years back that allows smooth, crisp font scaling. This means we can reduce the number of fonts you actually have to include in your game, having a single font you simply scale, rather than having 5 different levels. We’ve used this before and the results were superb.
Runtime memory. We have addressed a lot of the memory issues, with some games using a fraction of the previous amount. This was caused by the runner creating every room and every instance at start up. So any game with many rooms had a huge overhead. We simply now create them from the “reduced” source asset when needed. This gave a huge memory boost. We’ll continue to address this as time goes on.
Now, there are plenty of other areas we really need to improve. The Code editor really needs to stay open, even if this means losing the external text editor I think this is a price worth paying. As long as the code editor is good enough, losing the external “text” editor option isn’t really an issue, but it’s one we’ll evaluate closer the time.
We also really need to revamp the room editor and there’s some very cool ideas for this, in fact I’ll probably do a whole post describing what we’re planning for this so everyone can read it in detail; some of the new features will be very cool. To give you a rough idea…. We’re planning on adding zooming, and allowing you to put down sprites/text as well as objects. This means you can decorate your level without creating loads of objects. The new tile system is still under discussion but will likely include multiple playfields with each “whole” playfield being at a single user defined depth, this will speed up the room drawing hugely. More on this later.
On top of all this, there are some internal operations that could just be done better. They work fine, but we can speed many of them up quite a bit. Collision for example, can be sped up a lot by simply being sneakier about how we handle it. Also precise collision is pretty slow, but as that only happens when things actually hit, it’s not the end of the world.
I’ve said this before, you write for the platform as best you can, and you work around issues you have to. All development is about doing that. If not, then I could draw 20,000,000 particles for a candle sitting on a table and not care. It’s about doing as little as you can to achieve the desired effect. Yes, we can and will speed things up in future versions. Yes, the C++ runner is much faster than the Delphi one, and is getting faster and more efficient all the time, and yes, windows/mac versions will get it at some point in the future instead of the Pascal runner. These things take time, a long time.
So there you go. I plan on doing another post to actually discuss the runner. Where it’s at, changes made, and discuss the benefits over the Delphi runner, and why the C++ one will be much quicker overall. So stay tuned.
First there have been several posts about the current Delphi runner and how bad it is. While this is a little exaggerated there are indeed several problems with it. The first thing any developer has to realise is that a platform will never be fully to his liking, ever. DirectX has lots of things I really hate about it, stuff that slows me down and makes my code ugly, but I don’t just sit back and complain about it, or simply demand Microsoft do something about their “core gaming tech” or I’ll swap to OpenGL, I work with and around the problem to get what I need. All good coders do this because every platform is flawed.
That said… there are some short comings inside Game Maker’s API, some of them I consider fairly nasty. Aragon1029 posted some tests on the GMC so I’m going to start out by looking at these. I’m not completely sure what “some” of them are about, but I’ll address them as best I can.
The fact that .EXE’s are made read-only (I think this is what he means) is something we can look at, but you really shouldn’t be changing the .exe so I’m not sure why this is an issue to anyone, and it’s certainly something you can get round easily for now.
The decompiler. We will look at it in the next version, but anything we do is fundamentally crackable; eventually. We’ll see what we can come up with.
Crashes. We need reproducible tests and bug reports. We have a bug reporting system, if something’s causing problems, use it. Mac users will tell you that there are regular updates for them, and once we get the same system in place for windows, you’ll get that too!
File access. While I’ve no idea why you would want to read/write very large files in GM, I can see that it’s slow. The main reason for this is reading/writing to any file system a byte at a time is ALWAYS slow, no matter what language you’re using. It needs a “block” read/write badly. This will be added in later versions. What we’ll probably do is some sort of very simple memory allocation with peek/poke access, and then let you save “blocks” from this. This would allow fast access to data and allow nice reading/writing of “types” from files, particularly if we allow something like Peek_Float(memory_handle,offset), Peek_String(memory_handle, offset) etc… Oh, and no... the program hasn't crashed when it's "not responding", it's simply not responding because it's taking a long time. Leave it for a while and it will eventually come back. This is what happens if you sit in a large loop without letting windows in.
The Format. Not sure what he means about this one…??? We do want to make some changes to allow it to be source controlled however.
Dragging the window = frozen game “while” dragging the window.. This is a windows issue. It doesn’t give you messages while it’s being dragged. So the timing stops. All windows apps experience this… *shrug*
The “varied” parsing of GML ( a=0 or a:=0 etc..). Okay, this is a feature of GML. It’s primarily a learning language so is very forgiving of these, kinds of things. In some respects I’d love to make it much stricter, in another, we don’t want to hinder beginners by making it hard to get up and running. However it IS possible to have a “PRO” parsing mode, so that when you want strict parsing, you can have it. But this is something we will think long and hard about so that we don’t affect beginners. At the end of the day, a lot of our customers are schools and universities that teach to non-technical students, so we have to be very careful about what we do with this.
C/Delphi string handling. [0] or [1]…. Being a programmer, everything starts at 0 for me. I suspect we’ll standardise this in the future, one way or another. Outside of that should throw an error. It’s hardly a show stopper though….
Font rendering. First the example given isn’t terribly realistic, just printing row upon row of outline text isn’t exactly common in games, and if it was slow, you’d simply do it a different way. That said, font rendering is definitely slow. We have already seriously sped this up inside the C++ runner, and I expect this to get faster in the future when formatting is all done on the fly. However… a full screen of “outlined” text will always be slow, but we might be able to speed it up more by giving dedicated GML commands to actually draw a full outlined font making it faster yet. So there’s several things we can do here, although the main culprit has been changed in the C++ one already. Speaking of fonts, there was actually a very good talk at SigGraph a few years back that allows smooth, crisp font scaling. This means we can reduce the number of fonts you actually have to include in your game, having a single font you simply scale, rather than having 5 different levels. We’ve used this before and the results were superb.
Runtime memory. We have addressed a lot of the memory issues, with some games using a fraction of the previous amount. This was caused by the runner creating every room and every instance at start up. So any game with many rooms had a huge overhead. We simply now create them from the “reduced” source asset when needed. This gave a huge memory boost. We’ll continue to address this as time goes on.
Now, there are plenty of other areas we really need to improve. The Code editor really needs to stay open, even if this means losing the external text editor I think this is a price worth paying. As long as the code editor is good enough, losing the external “text” editor option isn’t really an issue, but it’s one we’ll evaluate closer the time.
We also really need to revamp the room editor and there’s some very cool ideas for this, in fact I’ll probably do a whole post describing what we’re planning for this so everyone can read it in detail; some of the new features will be very cool. To give you a rough idea…. We’re planning on adding zooming, and allowing you to put down sprites/text as well as objects. This means you can decorate your level without creating loads of objects. The new tile system is still under discussion but will likely include multiple playfields with each “whole” playfield being at a single user defined depth, this will speed up the room drawing hugely. More on this later.
On top of all this, there are some internal operations that could just be done better. They work fine, but we can speed many of them up quite a bit. Collision for example, can be sped up a lot by simply being sneakier about how we handle it. Also precise collision is pretty slow, but as that only happens when things actually hit, it’s not the end of the world.
I’ve said this before, you write for the platform as best you can, and you work around issues you have to. All development is about doing that. If not, then I could draw 20,000,000 particles for a candle sitting on a table and not care. It’s about doing as little as you can to achieve the desired effect. Yes, we can and will speed things up in future versions. Yes, the C++ runner is much faster than the Delphi one, and is getting faster and more efficient all the time, and yes, windows/mac versions will get it at some point in the future instead of the Pascal runner. These things take time, a long time.
So there you go. I plan on doing another post to actually discuss the runner. Where it’s at, changes made, and discuss the benefits over the Delphi runner, and why the C++ one will be much quicker overall. So stay tuned.
Wednesday, May 12, 2010
YoYo Games - Competition05
We've just finished the judging on YoYo's latest competition, and overall I think it was a great one. Some of the entries were outstanding, some were innovative, and some pretty, some were amazingly well presented, and yes...some were poor. But as this was the 1st competition I've helped judge here I was keen to look at every entry, and it was hard going at times. We had so many games just to get through, never mind trying to narrow down the number to an acceptable level.
However, we finally came up with the winners and most notable selections. However, it's worth saying that there were a good 60+ more that were notable, and even some that never got past the 1st round were still pretty good, but I knew there simply weren't going to progress past round 2, so there was no point in adding them to the list. On the whole, I think there were around 100-150 games which were extremely well done, with the rest being on average; pretty good. Very few were actually bad. For a community like this, that's staggering. Almost 500 games that were at LEAST okay.
We particularly loved some of the retro or simple styles, and while the winners were of a more standard fair, there were many games like Switch which displayed a simple, clean style, but great gameplay.
I don't want to go on about the list we posted which was a group decision, and one were we all agreed on, but I did want to give a shout to some of the others that I personally enjoyed... (not in any particular order)
The Scribbling - A pretty game, nice style and with a little more work, could spawn a few imitators. Although gameplay was a little clunky, it has a lot of promise.
Extinction 3D - This was quite impressive and looked very pretty as well, however it was lacking a certain "something", it felt a little repetitive and that meant it didn't have the longevity that other games could have. But another one which shows promise.
Ninja Penguin - I loved this, great little story and very well presented. I particularly loved the way it had a split story! Brilliant! Initial battles were a little too tricky though, but with a little T.L.C., it could be a real winner.
Sonneillon - This game surprised me with its presentation, and in-depth gameplay. It's amazing that there was such a variety of games types, and that they were so well done. I enjoyed playing this one, and it looked fabulous, but it was a little too slow (as many RPGs are) to really capture your attention. I think if the story was refocused a little at the start, so that it was a little more engaging, it could also do well.
Western Shootout - Great little "fun" game. Nothing more... nothing less. A great quicky, and I'm all for them.
Ne Touchez Pas IV - Unusual game, but I really enjoyed the way you could select a different vehicle, and then have the whole feel of the level change; very interesting indeed. I think it was a little too simple looking overall and would benefit from a stronger art style; perhaps even the old Star Wars vector arcade machine style.
two-sides-of-a-one-square - Great art style here... rough but consistent. Holds together well. Another one that needs a little love in terms of gameplay, but one to watch.
The Core - Another game which has great style, amazingly well presented. Game was okay too, but being a simple breakout style game (really..), it was only going to get so far in a contest which has such a depth of gameplay from other entries.
Pinball Panda Ultimate Toybox - I'm just listing this one because I love these games. Great fun, fits the format well. :)
Fate Elaments Intro - Nice little effect. I'm a big fan of "2D" platforms with a little depth, I think they look great. Gameplay on this one was a little flaky, but has some nice possibilities.
Now... again these are just a few that stand out from a crowd of great games, there are many more in there that I enjoyed that for one reason or another, just never made the cut. I think the whole community should be pretty proud of itself and the overall level of quality they managed to achieve.
For those that didn't make it, well there's another competition coming soon, so you've another chance to show us what you can do. One thing I will say; while stunning graphics and sound aren't everything, presentation, handling and a good difficulty curve is, so you should take a little time to try and make these are slick as possible. After all, you can always replace graphics and sound, but if you replace gameplay... then it's a different game altogether.
However, we finally came up with the winners and most notable selections. However, it's worth saying that there were a good 60+ more that were notable, and even some that never got past the 1st round were still pretty good, but I knew there simply weren't going to progress past round 2, so there was no point in adding them to the list. On the whole, I think there were around 100-150 games which were extremely well done, with the rest being on average; pretty good. Very few were actually bad. For a community like this, that's staggering. Almost 500 games that were at LEAST okay.
We particularly loved some of the retro or simple styles, and while the winners were of a more standard fair, there were many games like Switch which displayed a simple, clean style, but great gameplay.
I don't want to go on about the list we posted which was a group decision, and one were we all agreed on, but I did want to give a shout to some of the others that I personally enjoyed... (not in any particular order)
The Scribbling - A pretty game, nice style and with a little more work, could spawn a few imitators. Although gameplay was a little clunky, it has a lot of promise.
Extinction 3D - This was quite impressive and looked very pretty as well, however it was lacking a certain "something", it felt a little repetitive and that meant it didn't have the longevity that other games could have. But another one which shows promise.
Ninja Penguin - I loved this, great little story and very well presented. I particularly loved the way it had a split story! Brilliant! Initial battles were a little too tricky though, but with a little T.L.C., it could be a real winner.
Sonneillon - This game surprised me with its presentation, and in-depth gameplay. It's amazing that there was such a variety of games types, and that they were so well done. I enjoyed playing this one, and it looked fabulous, but it was a little too slow (as many RPGs are) to really capture your attention. I think if the story was refocused a little at the start, so that it was a little more engaging, it could also do well.
Western Shootout - Great little "fun" game. Nothing more... nothing less. A great quicky, and I'm all for them.
Ne Touchez Pas IV - Unusual game, but I really enjoyed the way you could select a different vehicle, and then have the whole feel of the level change; very interesting indeed. I think it was a little too simple looking overall and would benefit from a stronger art style; perhaps even the old Star Wars vector arcade machine style.
two-sides-of-a-one-square - Great art style here... rough but consistent. Holds together well. Another one that needs a little love in terms of gameplay, but one to watch.
The Core - Another game which has great style, amazingly well presented. Game was okay too, but being a simple breakout style game (really..), it was only going to get so far in a contest which has such a depth of gameplay from other entries.
Pinball Panda Ultimate Toybox - I'm just listing this one because I love these games. Great fun, fits the format well. :)
Fate Elaments Intro - Nice little effect. I'm a big fan of "2D" platforms with a little depth, I think they look great. Gameplay on this one was a little flaky, but has some nice possibilities.
Now... again these are just a few that stand out from a crowd of great games, there are many more in there that I enjoyed that for one reason or another, just never made the cut. I think the whole community should be pretty proud of itself and the overall level of quality they managed to achieve.
For those that didn't make it, well there's another competition coming soon, so you've another chance to show us what you can do. One thing I will say; while stunning graphics and sound aren't everything, presentation, handling and a good difficulty curve is, so you should take a little time to try and make these are slick as possible. After all, you can always replace graphics and sound, but if you replace gameplay... then it's a different game altogether.
Monday, April 26, 2010
YoYo Games Ltd...
Well, a little later than advertised.. but here we go. After leaving Realtime Words at the end of February, I can now announce that I'm now working full time as Head of Development for YoYo Games Ltd. YoYo have an amazing product called Game Maker which, to put it simply, allows you to make games without being a hard core programmer; or in fact a programmer at all. This is really neat. Russell Kay (who you may remember is doing the ZX Spectrum port of XeO3) and I have been working for some time to port the runner part of Game Maker onto the PSP, so that we can put some of the amazing games into the Playstation Network, as well as other console or mobile targets. In fact you can see a work in progress shown here..
This is a month or so old now, and we've made some real progress in speeding it all up, so Sky Diver hardly ever slows down now, which is great.
I've been having great fun doing this and hope to blog some more as time goes on about the problems, and internals of Game Maker, and what we hope to do in the future - so exciting times ahead! I'm also really excited to be part of the massive development scene at YoYoGame.com and hope we can deliver some really cool updates for them to play with.
I had to laugh... I've already been caught out by saying the PSP was uncool, so I thought I should at least attempt to clarify! :)
The cool wall isn't about what's good, or even what's popular, but what's perceived as being cool. Now, the PSP from a techie point of view, is very cool. Great colour screen, MIPS cpu (which I love), and good graphics through-put. But from a cool point of view.. well, the UMD isn't nice, it drains power too much and that kills it. When it first came out I was very excited about it, I loved the idea of playing movies on that very cool screen. But the battery let it down with the UMD drive, and the movies were too expensive; particularly for ones I already owned! One thing that really excites me with YoYo and Sony's NEW mini games, is this removes the UMD from the equation. Your battery life goes up, and the newer slimline PSP's are actually quite nice and pretty light.
The PSP Go is definitely heading in the right direction, but pricing is a little silly. If they can get the price down, the PSP Go could be a real winner; but cool? We'll have to wait and see!
Of course on top of this, you also have the minis being playable on the PS3, which is really cool. This means we should be able to get Game Maker games onto the PS3 as well, although perhaps one day... a real PS3 Game Maker HD might even be on the cards... only time will tell - now how cool would that be?
This is a month or so old now, and we've made some real progress in speeding it all up, so Sky Diver hardly ever slows down now, which is great.
I've been having great fun doing this and hope to blog some more as time goes on about the problems, and internals of Game Maker, and what we hope to do in the future - so exciting times ahead! I'm also really excited to be part of the massive development scene at YoYoGame.com and hope we can deliver some really cool updates for them to play with.
I had to laugh... I've already been caught out by saying the PSP was uncool, so I thought I should at least attempt to clarify! :)
The cool wall isn't about what's good, or even what's popular, but what's perceived as being cool. Now, the PSP from a techie point of view, is very cool. Great colour screen, MIPS cpu (which I love), and good graphics through-put. But from a cool point of view.. well, the UMD isn't nice, it drains power too much and that kills it. When it first came out I was very excited about it, I loved the idea of playing movies on that very cool screen. But the battery let it down with the UMD drive, and the movies were too expensive; particularly for ones I already owned! One thing that really excites me with YoYo and Sony's NEW mini games, is this removes the UMD from the equation. Your battery life goes up, and the newer slimline PSP's are actually quite nice and pretty light.
The PSP Go is definitely heading in the right direction, but pricing is a little silly. If they can get the price down, the PSP Go could be a real winner; but cool? We'll have to wait and see!
Of course on top of this, you also have the minis being playable on the PS3, which is really cool. This means we should be able to get Game Maker games onto the PS3 as well, although perhaps one day... a real PS3 Game Maker HD might even be on the cards... only time will tell - now how cool would that be?
Subscribe to:
Posts (Atom)