RISC OS Gaming in FocusBy Peter Naulls. Published: 21st Apr 2003, 15:23:07 | Permalink | Printable
Neil my-one-game-a-week-addiction White shows how easy it is.In a recent article, we mentioned Convey one of Neil White's games. We've tarted up his description of how it was done, and thrown some of own stuff in for good luck. Enjoy.
The actual concept for the game was inspired by a dot matrix display sub game on the Data East pinball table Batman Forever, in which you guide the Batcar up the side of buildings, smashing ten million point bonuses and across roof tops. All the while avoiding air ventilation units using the flipper buttons to move on a three wide path.
1 - The grid
I had a 10x10 isometric grid from some previous tests for an isometric shemozzle. This had never gooe much further than being a 10x10 grid of tiles, so I decided to use this as a template for the beginnings of the Convey game. After deciding on using a conveyer belt device of 6 player widths, I altered my 10x10 grid so it was a 6 wide and fit nicely on the screen.
The original grid was an array containing a number read from a data line of the sprite to be plotted, the rest of the work done using FOR NEXT loops. So I altered my data lines from 10 wide to 6 wide and added several more data lines underneath and altered the two loops that collected and plotted the data appropriately, giving me a template for the actual belt.
2 - Referencing points on the grid
Running my program gave me a 6 wide line of little tiles going from the edge of the screen, so to make it display only part of the conveyer belt I created the variable 'jug' (always name your variables appropriately kids, so when you come back to your code you understand it!). I then used 'jug' as a marker for the start point of a 24 tile section of conveyer belt, running a loop from 'jug' to 'jug+24', which plotted a 24 tile section of the conveyer belt so by increasing 'jug' by one I moved the conveyer belt by one tile.
The next step was to create a loop that altered the (x,y) point of the line of tiles, and after the line had moved one tile increase 'jug' by one giving the illusion of smooth conveyer belt movement. Well, it doesn't look so smooth without the pink bits covering each end which hide the jump back of the (x,y) positions. I now had a nice looking conveyer belt.
3 - The hero
The next step was to add our hero, the green sphere, so I set up an array for his position on the conveyer belt and arrays for his x and y plot points in each of those positions. I could now use key presses to move him left and right on the conveyer belt and compare his position with the sprite number array of the conveyer belt, so his position is 1 to 6 (the width of the convey belt) and 'jug + 6' (he's always 6 tiles from the end of the conveyer belt).
4 - Collison detection
Next I simply used his position to tell if he was over a hole, the hole sprite being 2 and a 'safe tile' being 1 so he plummets to his doom if he hits a hole tile, and you start again. The same system was used for detecting if he was collecting a red blob - if his position reads a sprite 3 in the conveyer belt array the number of red blobs he has collected goes up by one until he has collected the total on the conveyer belt, which is counted as the belt data is collected, and if all the red blobs have been collected and he lands on the finish square: level complete.
5 - Jumping
After play testing a little I decided to add a jump feature, which just changes the blob sprite so he looks higher up and switches off checking what tile he is under until he has gone the length of two tiles, at which point he crashes back down and checking is reactivated. Then I added the jump tiles that simply activate the jump, added left and right shift tiles which add
or subtract one to the position of our hero forcing his move, then I added the cracked tile which has the same effect as a hole but isn't so obvious.
6 - Evaluation
After making sure our hero couldn't be guided off the edge of the conveyer belt and adding things like score, lives, the title screens and making the data read from a text file; I had made a quality little game in which the levels can be created simply by editing an ASCII file. Not bad going for a couple of days watching the TV and typing the odd line of code.
There are a few minor bugs in the game, one of which is the way I plot the tiles: they are plotted form the bottom row on the screen up to the top row on the right. This means I can't have anything on the tile higher than the back of the tile, because the next row up is plotted over it. Also the same kind of problem occurs because I am plotting the character after the entire level has been plotted, meaning he won't go behind stuff, but all these problems will be solved in Convey 2, or I might call it 'jug'.
7 - Tools
Generally the software I use is just Zap, a Basic file cruncher called BC, Paint and the fast sprite part of Andy Southgate's game suite. Occasionally for graphics I pull out Artworks and Photodesk.
Convey, along with several other games can be fetched from Neil's site: www.cloudsprinter.com/software/
For more information, you can find the source code to Neil's Convey here.
Neil himself admits to being scared that he's now the most prolific RISC OS games developer. It can take the right attitude to write games, and Neil's mix of enthusiasm and heady classic satire gets the job done.
But what else is going on? As we mentioned in another article covering Neil's games, Popcorn, a games engine for RISC OS, is being improved by Rik Griffin and can be found on his website.
eQRD's SDL port although somewhat unstable and not yet 32-bit, provides a promising start, as an increasing number of potentially portable programs use it, including several games. There are a few people looking at this, and we'll see what happens.
My own Unix Porting Project sports a few games, including FreeCiv, although they remain somewhat academic until more work is done to support X in RISC OS. This may open the way for many more ported games on RISC OS.
Want to write a RISC OS game? I suggest you start small. And use something like Popcorn to do all the fiddly bits. This is the last thing you want to be messing round with when doing a small game.
Both C and Basic have advantages for game development, but if you want to do big things or use something like SDL, you're probably going to have to use C.
I very much doubt we're going to start a RISC OS games Renaissance, but it's still nice to see these developments.
Previous: New releases touted as Wakefield prizes
Next: Easter Round Up - Don't put your chocolate bunnies in the sun
DiscussionViewing threaded comments | View comments unthreaded, listed by date | Skip to the end
Please login before posting a comment. Use the form on the right to do so or create a free account.
Search the archives
Today's featured article
Using SDL natively
Neil White makes his move
2 comments, latest by nex on 17/10/04 10:52AM. Published: 6 Oct 2004
How the BBC Micro led to the iPod
From a humble 8-bit world to Apple's market domination, all via ARM
Discuss this. Published: 6 Apr 2008
News and media:
RISCOS Ltd •
RISC OS Open •
MW Software •
Advantage Six •
CJE Micros •
Liquid Silicon •
Chris Why's Acorn/RISC OS collection •
The Register •
The Inquirer •
Apple Insider •
BBC News •
Sky News •
Google News •