|
ISSUE #27 - 2008-11-05
 |
 |
...Heroes Quest Competition Results...
The Heroes Quest competition closed about the same time as the electrical impulses of new letter #26 were landing in your inbox. This year, only three brave souls were tenacious and proud enough to bring their creations to the competition. For this, we give our sincere thanks, finishing a game is a real achievement. But enough with the formalities, who won?
This year it was very close between Never Dawn and Who Stole Waldo?, both really captured the spirit of the competition. You know, some Fun old school platformers. It was hard splitting them in the end, never the less Never Dawn got home by a nose. Congratulations to its developers.
Heroes Quest - 2008 Game Making Competition Results
1st Place - Never Dawn by Frozen Turtle [105.0 Points]
 -  - 
Judges Comment: From the moment you launch Never Dawn, it just drips with that almost indefinable quality of a well crafted game. For me, it's Possibly the best game we've ever had submitted. Everything seems well thought out and purposely put together, from the menus, the game mechanics and the level design. Giving the player a very enjoyable and rounded gaming experience.
2nd Place - Who stole Waldo? by Tommy Haaks [ 94.5 Points]
 -  - 
Judges Comment: Who Stole Waldo? is a very interesting contribution to this year's competition. While nice and solid, it doesn't quite feel complete at the moment. However what's presented, is done so with enough polish to make it all come together very well. From a technology stand point, it includes some features that other competitors haven't, such as exploiting Alpha Channels with sprites and including hardware independent game play.
3rd Place - The Lost Kingdom by Christian Ang [ 48.5 Points]
 - 
Judges Comment: The first thing you notice upon running The Lost Kingdom, is that it's a little fresh in its life cycle. However, while it's easy to speculate how it might turn out in the future, we can only review what's presented at the time of writing. From a strictly technology point of view, the developer has certainly upped the ante on the other competitors, by including a built in custom scripting engine as well using vector/shape based collision.
Downloads
View Full results, Downloads and Players Poll
Competition Sponsors
ColdSteelEngine.com
Back To Index
>> Read More ... |
|
 |
|
 |
...Get Physical With BOX 2D - Physics for PlayBasic...
by Christian Ang a.k.a Slayer93
Box2D is a fantastic library for C++ that lets you easily implement 2D physics for your applications. It has been in development for a few years by Erin Catto ( http://box2d.org/) and is still in development. Furthermore, it is a fully featured physics library including collision detection, raycasting, rigid bodies, forces, impulses, torque, gravity, friction, any type of joint you could imagine, and so much more that it's a little to much to list in here. When I saw this it got me to thinking Box2D would go perfect with PlayBasic, a language that does its job best when making 2D games.
So what am I doing? I'm creating, what I hope to be, a fully featured wrapper including everything Box2D can do and will do. Development has only just started, but in due time it can turn into something great, along with feedback from you. Currently it can create a Box2D world (basically a container for your physics objects), create static/dynamic rigid bodies, and set additional properties for them including gravity, mass, friction, and density. All to create a realistic simulation you can update with one command.
You can check the status of the project on the Underware Design forums, where you can also download the latest version of the wrapper. There may not be much now but I'm just getting started!
Back To Index
>> Read More ... |
|
|
|
 |
...PlayBasic SEP/OCT Round Up...
By Kevin Picone
Since the last new letter, a couple of months ago, we've been working on back end of the PlayBasic, known as the VM, trying to get the second generation of it ready to officially take over. I get a lot of questions about what is the VM, why replace it etc, So the following couple of blog entry's takes you through what it is, and what it's being replaces and how the progress is going. Sadly, this is pretty boring stuff, even for me. So if you don't want to scratch your eyes out with a blunt object, look away now ! :)
September
The Big VM2 Mystery
There's no getting around it, discussions about programming languages are often laden with lots of jargon. So it's no big surprise that readers (in particular those fresh to programming) get lost in a sea of acronyms. So to try and counter this, I wanted to quickly take you through what VM2 is and how the new model all fits together..
PlayBasic, like most programming languages is built around a three stage process. During the first stage, the programmer enters and refines their program code using the editing environment, also known as the IDE. Stage two is the compilation process. This stage takes the source code, (the text the programmer entered during stage one) and translates it from something that's meaningful to us humans, and converts it into something that's easier for the computer to understand. This translation is often referred to as "creating a binary". The final stage is execution. Execution in PlayBasic is handled by what's called a Virtual Machine. Alert - jargon Ahead!
What's a Virtual Machine ? While there's a number of different flavours, the PlayBasic Virtual Machine is what executes the binary presentation of your program. So it takes the information that the compiler outputs, and deciphers it, in order to act the program out.
While this is a pretty broad view, hopefully you can see that the VM is the underlying heart and soul behind the PlayBasic language. Now given the VM is what actually executes our programs, then it stands to reason that any improvements to the VM's performance, will in turn make our programs perform better also. This is exactly what's been happening over the years with the original VM, whereas today's edition is some 4->5 times faster than it originally was. But there's only so far the old VM design can bend, before it becomes clear we need to start afresh. Introducing VM number 2, otherwise referred to as VM2. What is it? It's simply our second generation of the PlayBasic execution technology.
Those following the growth of PlayBasic over the years will know that VM2 is not a new idea, we realized early on that VM1 wasn't going to cut it in the long term vision, therefore we started writing & designing a replacement some two years ago. The plan was to introduce VM2 with our second generation of PlayBasic, known as PlayBasicFX. However with obligations to continue PlayBasic support, development of VM2 just wasn't a priority. However, over time many of the new design ideas from VM2, have in fact been retro fitted back into VM1, which is a big reason why we're able to improve it's performance. In fact current editions of the PlayBasic run on a hybrid of the two editions. But not any more.
With the move from PlayBasic towards PlayBasicFX starting Earlier this year, moving to the new VM2 clearly became a priority again. However it's not a matter of just including the new runtime and off it goes; VM2 uses a completely different instruction model to its baby brother. As such, in order to use it with any current edition of PlayBasic, the compiler and command libraries all need to be changed. To do this there's two basic approaches, we could either start totally afresh, or migrate (section by section) from one to the other. We chose the latter, while it's a bit messier in the short term, it does mean we can build versions that include the old command sets today. Registered users of PlayBasic can download these from our PlayBasic maintenance forum at UnderwareDesign.com by the way.
So what new features does VM2 offer that we can't already do? Well, without getting into specifics, the primary goal is to provide a smaller base that includes faster execution and more flexibility. We'll get to the execution speed in a second, but in terms of flexibility, we're referring not only to how we build the PlayBasic Products, but being able to build your own projects in a more modular friendly way. If you think back to the 3 stage process that PlayBasic follows, which can be summarized as
Editing -> Compilation -> Execution
What modules will allow us to do, is keep common parts of our programs in a pre-compiled format. These compiled parts could then be distributed separately, or you can use them to further accelerate your own development time. The approach also makes the maintenance and expansion of the PlayBasic virtually infinite. You'll be able to attach any graphics engine you want to it. For example, you could use ColdSteelEngine.com or even LeadWorks Engine.
Ok, so the big question is how much faster is VM2 execution? Well, given that (at the time of writing) we're just about above 80% of the way through its official introduction, it's becoming clear that VM2 is on average another 2-3 times faster than the most optimal VM1 edition, found in PlayBasicV1.64 for example. This is all lovely, but without some type of context that's a pretty abstract value. In comparison to a number of compiled Basic languages, it is now matching and sometimes outperforming them under certain circumstances. I should point out the benchmarks are designed to be a real world representation rather than the standard brute force for variable=variable+1 type loops you'll see as the compiler selling point, although that's included also.
If you're wondering how that's possible, it's simple. While VM2 uses a much better instruction set model, the real reason is that most basic compilers tend to focus on the structural code performance and ignore the speed of the command set. So they're often pretty good at brute force operations, but when you peel away the hype and check them running some real world code, they're often slower than you might expect. So things tend to balance out. That's not to suggest VM2 has anywhere near the brute force performance of native machine code, it isn't ! Just that the gap to our main competitors in a real world sense, is closing.
October
Continuing The Big VM2 Story
Last month, we looked into mystery behind the very building blocks of the PlayBasic language. Mainly focusing on the component known as the Virtual Machine or VM for short. This is programmer jargon for the part of the product the actually runs your program code. So it's the very the heart the soul in fact, without it nothing happens. As outlined previously, PlayBasic has been undergoing a transformation in recent times. The bulk of this transformation has been to underlying VM technology. Moving from the original version, known as VM1, to its creatively titled replacement called VM2. Changing VMs is a big job, but the benefit when it's complete will be faster execution, smaller executables and much greater flexibility on the whole.
Progress-wise, things have unfortunately slowed, since October hasn't been a purely code crunch month. However, the light at the end of the tunnel is fast approaching, with virtually all of the major components and support libraries now being in place. The VMs use a custom instruction set, all commands that you use in the PlayBasic language are translated into this low level instruction set (also known as opcodes) during compilation/optimization process. The instruction set has various banks of instruction types. In other words they're all grouped into collections. At the time of writing, all but one collection have made their way across to VM2 safely, if I had to estimate we're about 90% of the way there. It might not sound like much progress from last month, but at that time there was a mountain of support libraries that needed to be updated also. Those have since been translated, making it a nice easy down hill from glide from here.
The goal for the coming month (November) is to knock over the remaining parts of the instruction set, then release another stepping stone build of the PlayBasicFX base product. Meaning that the next edition PBFX will be running upon VM2 in combination with the Direct3D engine, giving it a distinct advantage over standard PlayBasic. This will not be the final migration mind you, we're still another few updates before it's all complete, but it's getting closer.
If you're curious about our VM2 progress, then wander over to the VM2 translation thread and make sure you read my private blog for the nitty gritty.
PlayBasicFX VM2 translation WIP/BLOG
Back To Index
>> Read More ... |
|
|
|
 |
...Postmortem for 'Who stole Waldo?'...
by Tommy Haaks
So the competition entry is finished, the competition itself has ended, I made second place and the prizes are coming in ;-)
That's a very good time to tell you about the development in general, what went wrong or right and what to expect for the future.
General:
I always wanted to code a platformer, just to learn the basics how this type of games work. So the competition theme got me hooked immediately. I had an idea in mind where the game played in a pyramid with lots of rooms connected to each other and our hero had to collect treasures, fight mummies and rescue some egyptian princess or something in that style ;-)
This game never had a chance. And it's all BlinkOk's guilt! He posted mockup screenshots of his georgeous graphics and I couldn't resist and volunteered (begged on my knees but in a cool way) to use his sprites and backgrounds. And not knowing what I was doing I even asked for the "purdy" (meaning pretty and anti aliased) version of his sprites.
So I had to learn quite a lot about different image types, anti aliasing sprites and their effects on game speed and clever game loops...Additionally the graphics were in a format that made them unusable for any of PlayBasic's builtin map routines and I ended up coding my own tool to create description files in some XML like format to create my levels and animations.
But it was all worth it and I am convinced that BlinkOk's cool graphics helped me a lot to stay motivated to finish the game and also impressed the judges to make me win the second prize!
- -
What went wrong:
- It took too long to code my own helper tools (PBAnimMapper).
- It took too long to come up with a good design of map and animation description files.
- I started too late with ingame functionality. Coding map loaders and image slicers isn't fun.
- Debugging sessions ate too much time. The debugger of PlayBasic was too restricted for me, being a professional Java coder using Eclipse day by day.
- Language limitations (types inside types, arrays inside types not working as I wanted them to work) required work arounds. After the competition was finished I saw a very smart way of using the builtin PlayBasic Animation library. This would have solved all those limitations (and those features I wanted to have aren't existing in any other Basic either that I know of...).
What went right:
- The decision not to create my own awkward graphics but to use BlinkOk's stuff. Nobody would have loved jumping triangles hunted by squares or killed by circles. Although I might have chosen bearable colors (not guaranteed).
- Choosing BlinkOk's graphics gave a huge motivation push forward for me to finish the game.
- Overall PlayBasic is really powerful and getting used to it sped up my development time after a while.
- SFXR is a great tool to create sounds and those improve the overall atmosphere of the game.
- Joining the competition got me in contact with some cool and nice people!
What to expect:
I am already working on an improved version of "Who stole Waldo?". Many things just didn't make it into the competition version due to time constraints. Other enhancements will be based on the feedback I got from the judges.
What's on the plate?
- Options screen (Fullscreen/Windowed switch, volume control, settings loaded on startup and saved when leaving the Options screen) (already complete),
- an Intro explaining the story,
- more levels,
- more animations and more graphics,
- more enemies with smarter behavior,
- the kid can defend himself,
- UI improvements,
- joypad support,
- a level editor (preferably built into the game to immediately test the levels),
and finally
- more games from me coded with PlayBasic!
Thanks for reading,
Tommy Haaks
Back To Index
>> Read More ... |
|
|
You receive this because you subscribed to the UW.com
Newsletter.
To be removed from this list, please click THIS LINK !
|
