It’s really quite simple – I always wanted to make a game where the aliens come diving at you and you pump some lasers at them such that they “splat” in glorious fashion all over the screen.
So that’s what I did and since it takes its lead from my Galactians game I call it Galactians 2.
The premise is very retro and very simple. It’s also fast becoming my signature style of game. Aliens line up in rows above you and you sit beneath them with a ship / tank of some kind blasting them all to kingdom come.
I should add that when writing down a high concept for this game I considered the following 3 things: Galaxians, Starship Troopers and the classic 8-bit Defender clone Dropzone.
Galaxians for its format, Starship Troopers for its relentless bug invasion and super splatting and finally Dropzone for its visual style.
Here’s how it currently looks.
To create the moonbase I took a long look at Dropzone and got a feel for how the developer used just 3 or 4 colours to create the effect. It’s far from finished but let me tell you there’s quite a thrill for an aging Atari nerd such as myself to have Photoshop and Wacom open in one window and an Atari emulator running the aforementioned game in another.
I would quite like to blog the creation of the moonbase at some point in the future. I haven’t kept each stage of the drawing on file but I could probably get around that by starting a new, smaller graphic and employing the same principles.
It’s a real thrill to be making good old arcade games again. I know I’m not always very adventurous with my games but who cares. It’s great fun :-)
Incidentally the game will work on desktop and mobile. Depending on how you start the game (mouse click, fire button, touch screen) determines how the game is controlled.
In an ideal world I would develop all of my games at a fixed resolution. That resolution just now would be something like 320 x 460. Largely because according to my analytics data from Google the majority of people playing the games do so on an Apple device such as iPhone or iPod Touch.
Of course the problem here is that for every 10 Apple players there is going to be at least 1 Android player equipped with an HTC Desire or possibly a Galaxy Tablet or… the list is endless.
Fixing the canvas size is also great for knowing where items can initialise on screen. You are able to set an accurate scale to your games, you know just how big the sprites are and just how much freedom of movement they can have.
With more fluid dimensions you run in to the territory of working with relative positioning – which is no bad thing and certainly not a difficult thing to work with if you are able to consider it from the outset.
A quick glance at my analytics title sends a shiver down my spine:
48,552 visits used 730 screen resolutions + operating systems
730 different screen resolutions !
So I delve a little deeper to see just what has been viewing these games.
So at this point I start to wonder about a few things. What exactly are my options ?
- Just fix the canvas width and height to the available width and height of the browser window
- Ignore it and continue to force dimensions to 320 x 460
- Take the window dimensions and try to calculate some kind of a scalable dimension based on height / width ratio
- Take the window dimensions and offer canvas dimensions based on a number of presets. e.g. 320 x 460, 480, 690, 640 x 920 – possibly centering the content with CSS
Considering each of these options of course introduces other questions.
For starters at the point when you grab the window dimensions how has the player got the handset held ? Landscape or Portrait ?
For example, if the screen dimensions come back as 640 x 480 is that just because the handset is on its side ? Or is it a desktop resolution.
We can of course check window.orientation for this.
Generally a value of 0 (zero) indicates a default orientation of portrait.
90 and -90 indicate the alternative orientation of landscape.
However, I notice that the Samsung Galaxy Tablet 10.1 sets its default to 0 in a landscape orientation. Very useful indeed. Not.
If, in the case of option 4, I decide to continue fixing dimensions do I need to offer multiple sized sprite sets to avoid sprite scaling ? Most probably. Scaling is a performance dog just now and can yield unwanted visual effects.
So how do you solve a problem like this ?
What exactly can you do to give the player a good full screen experience AND ensure that you are catering for all devices ?
Does anyone have their own experiences / solutions that they might wish to share ?
I ask this question deliberately since I have coded a number of solutions, none that I am truly happy with. Please let me know your thoughts. If comments close (after 7 days to restrict spammers) please mail me. You can find the address in the about page. I will publish your comments if you so wish.
I noticed something interesting earlier whilst trying to improve the performance of Dragons that I thought I should share. When I first considered how the game would look I settled on a full screen scene. I blogged how excited I was about this and that I could finally sit back and create full screen renderings in Photoshop. I’m using .png files for the backdrops. I tend to use that format for everything these days.
The theory was simple in that I would run through setLevel() once per level and set everything up. One of the things to set up is the current stage backdrop. For this I set the backgroundImage property of the canvas’ style to be whatever background I choose.
Something like this:
g.canvas.style.backgroundImage = “url(‘…’);”;
Very basic CSS stuff. g is my global namespace.
I figured that this would save me a hefty drawImage() call during the main game loop and therefore preserve some frame rate.
This was a poor assumption. At least on iOS. And even then it appears more so on iPhone 4.
I scratched my head as to why first gen iPod Touch could render the game at roughly 20FPS and iPhone 4 struggled along at around 6FPS.
So I played around with it a bit and took stuff out. I also killed shadows on text and cut back on the number of sprites on screen. None of it made a difference.
Meanwhile over on Android the game was flying along like a train.
I then decided to take a closer look at the “big” stuff. By big stuff I mean the operations that involve the most pixels. I use drawImage for everything so I reduced the size of the sprites and took out sprite scaling and rotation. No real difference was recorded. So I put it all back in.
I then took a look at the CSS call to paint the backgroundImage of the canvas in what I thought was a one-time-per-level operation that exists outside of the loop.
I stripped out the CSS bit and rendered the full screen scene on every game tick. To try and help it along a bit I also reduced the file size of the .png files from 43k to 3k. I also ignored diffusion since this doubles the file size even at 8bits.
I uploaded the new game code and assets and refreshed Safari on the iPhone4.
To my amazement the frame rate had more than doubled to (a still poor but more acceptable) 16-20FPS. Android was, to be frank, no different. It still motored on beautifully.
So the valuable lesson that I’ve learned here is that the best course of action on iPhone (at least it is right now before iOS5 arrives) is to do all full screen drawing with drawImage and not rely on CSS. Alternatively of course don’t do ANY full screen drawing.
One of the smoother games I’ve completed, Galactians, works against a plain black backdrop a la the arcade games of the early 1980s. Perhaps there’s something in this.
I’d love to hear some thoughts on this. I really am not a great coder so muddling through this stuff is often mesmerising at best. Be interesting to hear what other HTML5 game developers are doing to steal back some FPS.
Now that Dragons is finally complete I’m going to have a bit of fun in returning to my first love – the retro style shoot ’em up.
Note: Dragons suffers some terrible performance on iOS and I intend to look in to this. When iOS5 is released to the masses next month I hope to see vastly improved CANVAS performance.
So I took the Galactians code and sprite sheets and started to look at how I might achieve the effect of a moving pseudo 3D landscape.
Initially I started to play with around 8 stripes tumbling down the screen. On setup each stripe was either dark blue or light blue and I’d resize them based on their y position on screen.
But I then realised that it was pointless and I could half my drawing by simply colouring the background with CSS as the “off” stripe colour. The effect is the same. So now I just have to deal with 4 stripes hurtling down the screen at pace.
I looked long and hard at Stealth and its use of positioning and terrain handling and decided to break with the style a little. I wanted my fighter to sweep left and right and also to bank the nearer it was to the screen’s edge. Stealth moves the distant mountains and alters the way the terrain comes whizzing under your fighter. I didn’t want to do that. Not yet anyway. Not until I’ve exhausted my preferred method. We’ll see.
So just now I have some rotation going on with the main fighter sprite. I also go to the trouble of resizing the shadow that is beneath the fighter. When the fighter is banking at its sharpest angle I shrink the shadow to be quite tiny.
Once I was happy with terrain and fighter I added the lasers. For me the lasers needed to disappear to nothing and look as though they’re headed off to the distance. I shrink them based on their time on screen and then kill() them when they get to zero. The rest of it is just playing with numbers.
Finally, at least in terms of my initial tests, I spawned the aliens to emerge from the horizon, raise a little and then swoop off down the screen. They scale up as they descend – which in itself is an issue since we have some blurring to contend with – and then get kill()ed as they disappear off the bottom.
There’s so much work to be done here but I’m very happy with the initial tests. I suspect I will need to add a distance attribute to each alien and laser so that I can accurately gauge when and where any collision took place.
I do love these final stages of game development where everything you’ve had scribbled down from ideas to character designs to neat little effects comes together and you get a screen full of activity.
I am a huge fan of keeping the screen busy but not too busy. There is a fine line.
I’m also loving handing some of my game assets over to static Photoshop created images. It gives me the ability to better match and marry the colour schemes.
I have a wealth of sprite / tile art on my machine so it’s always a thrill to sift through some work that is years old to find a cool new starting point. Sometimes the work just fits. Sometimes it needs a little tweak to fit the style that I’m after for the game.
I think I’m pretty close to completing Dragons now. (I had played around with different game titles but realised in the end I rather like the simplicity of calling a game Dragons.)
I have balanced the attack vs defence vs goals to a decent level – certainly enough to provide a casual challenge.
Level times are at around 1 – 1.5 minutes on average. Plenty long enough for a casual game.
What I hope to complete before I publish the game is some balance in the scoring system. Just now there isn’t much variety in the scoring and I’m a believer in spreading the scoring based on how much skill / effort was required on the part of the player to actually achieve the score.
All in all a good development and a thrill to be working with lots of colour again.
I intend to write about the development process in a little more detail soon as well as providing a few pointers on how I create my 2D sprites / tiles.
For a long time I’ve wanted to create a game with a fire-breathing Dragon. I’d always imagined it would be a big, hulking monster that would stomp around a scrolling level laying waste to anything that came close to it. The more I thought about the idea the more I struggled to think of anything that would work as a decent challenge.
The trouble with hulking great fire-breathing monsters is that they are pretty much invincible. At least that’s where the fun lies. The fact that you can torch anything to the ground ought to be a lot of fun.
I guess there are some mechanics that would work in such a game; time limited destruction, for example, but I really didn’t want that. I generally don’t like games where you are pitched against the clock.
So I stepped back a little and thought of the game as a shoot ’em up (naturally !).
I sketched out some level ideas and realised that for my Dragon I wanted to have the fireballs tumbling down the screen. This I think is more aesthetically pleasing and also serves to reinforce the single finger / thumb control that I aim for in my games.
I started off having this floating, fire-breathing Dragon drifting across the screen. I played with it for a while to try and get a feel for what might be a fun thing to do with such a character.
Note: I generally don’t think in terms of challenges more in terms of what is fun. For me it is always fun to shoot > kill > explode so I aimed for that first off.
Naturally adversaries wouldn’t necessarily explode when hit by a fireball so I adapted the sprite sheet for the knights to include one where they are engulfed in flames.
So the game starts to take shape with the Dragon at the top of this ledge protecting “something” that the knights are clearly after. Just to mix it up a bit I also hurl spears and swords at the player to give him something else to think about.
Finally I introduce the overall aim of the game – collect and defend your treasure.
I have random treasure items bouncing down from the heavens that the Dragon (player) must collect. The advancing knights scaling the rockface are intent on stealing from the treasure chests so it is a constant battle to ensure that your treasure levels are high. Once you have enough treasure (indicated by the gold progress bar – not in the current screen shot) you progress to the next stage.
Something that I’ve done deliberately in this game is to hand over some of the artwork to a static PNG file that forms the CSS backgroundImage of the game screen. Ordinarily I might have been tempted to draw each treasure chest and the treasure icon separately and then animate them. But this just seemed like another 4 un-necessary drawImage calls. As it is I only ever call the function around a dozen times with each pass. This gives me a fairly acceptable performance across all devices.
I hope to have the game finished in the next few days so that I can move on to something new.
I still can’t think of a decent title for this game. I guess something will spring to mind.
About 10 years ago I worked on a small nGage title called Space Ranger. It was a simple affair of guiding your space hero around a maze with a rocket pack whilst shooting your laser pistol at bizarre cartoon-like aliens and monsters. Great fun and a blast to develop.
Luckily, I kept all the art work that I created for the game on disk and recently dug it all out.
The rocks (with slight Photoshop filtering going on) and grass ledge in the screenshot are from the Ranger game. Everything else I’ve drawn from scratch.
There’s also a snow level with an icy ledge at the top of the rock wall.
As you can see I’ve coded up the collision with the Dragon’s fireballs (which incidentally right now are the alien bombs from Galactians) so that I can hurl the Knights from the rock face in flames.
As with the last game I flash up multi-coloured text boxes to indicate the score for hitting each bad guy.
The other cool thing is the hovering Dragon sprite. The hovering is done in code but the tiny wing flutterings are done in the artwork. I like the effect a lot and hope to build on the spritesheet to include some other frames for celebratory sequences or the losing of a life / chance.
Enjoying developing this one.
I tend not to deal with design documents. I just like to scribble and sketch ideas and write down what I think would be cool.
Just now in my worklist.txt file I have the following:
> Make the Dragon fly rather than shuffle left and right.
> Increase the fireball fire rate to be more like a shoot ’em up.
> Use swipe movement rather than pin-point x co-ordinates. (Same as Galactians)
> Primary goal of defending treasure.
> When all treasure gone Game Over.
> Falling monsters / knights in flames collide with other assilants and score combo points.
> Change castle setting to a rocky mountain ledge with grass top.
> Arrows fired from assailants – vertical only no x shifting.
> Need to consider an alternative monster style – not just vertical only movement.
> Implement attack waves.
I also created a new attacking Knight sprite. Attacking in the sense that the Knight will scale the wall to steal the Dragon’s treasure.
It’s nice to be playing with a fantasy theme for a change.
Incidentally the game doesn’t have a proper title yet – hence “Dragon Game” :-)
Following on from yesterday’s post about seeking inspiration I took to MAME and played through a number of classic mid-1980s arcade games. A few in there were a lot of fun and yet lacked the colour depth that came a few years later when palettes were increased and screen resolutions improved.
I decided to try and knock up a few images for a game that sees the player controlling a baby Dragon atop a castle rampart. The Dragon is defending something (treasure probably) from marauding knights, rogues and critters. His only form of attack is, of course, fire. The player shifts the Dragon horizantally and aims to bump off the attackers who attempt to scale the castle walls below.
Creating the sprite sheet for the Dragon was fun. It’s by no means finished but gives me enough to start a game. I created the game’s backdrop as a single 320 x 480 png that is placed in to the canvas background using CSS. No full screen redrawing here !
Anyway, I’m still messing around with the concept but hope to have a game within a couple of weeks.