Christoph's Dev Blog

[chris_r]

Hi guys, as you probably don't know (unless you've been paying lots of attention on GP32X) I am attempting to code a game to be ready in time to be a launch game for the pandora. This is only my 2nd game I have written (after breakout) but I hope to be able to have the project released on schedule.

The game is a platformer, even though there are many already. My platformer will include levels created by me, but will also include a Level editor that will run on the pandora so that the community can also create and share their own levels.

At the moment it is only in its very basic form:
The player can be moved left/right and acts under gravity.
The player has very basic collision detection.
The map of the level is loaded from a file.
The graphics tiles are loaded from a file.

Todo (core features only, before additional features)
Design graphics.
Properly implement collision detection.
Remove hardcoded level values and add them into the loadable file format.
Load the level size from file (again instead of hardcoding)
Implement character actions (such as jumping)
Load multiple tile maps that layer on top of each other.
Add collision detection for certain tile types.
Decide on a better tile size (32x32 is way too small for pandora's high res screen)
Add level scrolling when the character reaches the edge of the screen.

Of course I have here the obligatory screenshot, although it doesn't show much at the moment.

This shows the tile engine running (loaded by a map that was randomly generated) and the player (the red box) has fallen from the top of the screen and can be moved left and right on the black tiles (collision is hardcoded at the moment, it will be changed later).

I welcome feature suggestions and assistance, but please be considerate to keep this thread tidy. If a feature is quite obvious then please don't suggest it. If the thread is kept tidy, then my updates will be less likely to get lost among posts.


This blog can also be found on http://christophsdevblog.blogspot.com in case people would like an RSS feed.

I have changed the level file now so that the tile size and level size are loaded from the file. This will mean less consistency between level designs (graphic styles, unless using the default tile map) from different designers, but allows for a bit more flexibility for level designers.

The FPS is now capped, instead of running at full whack like it used to, it runs at 30FPS.


Update #1 5/10/08
I have changed the level file now so that the tile size and level size are loaded from the file. This will mean less consistency between level designs (graphic styles, unless using the default tile map) from different designers, but allows for a bit more flexibility for level designers.

The FPS is now capped, instead of running at full whack like it used to, it runs at 30FPS.

I want to know if someone with experience could tell me the best tile resolution, for the pandora's screen. eg. How many tiles is it a good idea to have vertically/horizontally?

Update #2 08/10/08

The level can now scroll horizontally (Mario style) and the character now properly detects collisions between certain tiles.
All level details are now loaded from the level file.

Now I need to implement multiple level layers. I'm thinking 3 of them, but someone tell me if I'm wrong.
One in foreground (in front of character)
One in background (behind character)
One for scenery (parallax skys and stuff like that)

Update #3 13/10/08
The character now properly jumps and collides with tiles directionally. The character now properly reacts to tiles properly as well ie. acting under gravity. Not moving further if a tile is blocking the way etc.
Cleared up the last of the hardcoded code. All the level details are now loaded from the level file so that levels can be in a completely independant style from the original levels.
I removed all the debugging bits I had put in before to test, and cleaned up the code. (Probably doesn't actually make much of a difference in speed but it's good to keep code clean)
Fixed a bug where the tiles would only blit if an image was loaded.

I will likely upload a youtube video soon of the game in action (albeit still without proper graphics)


YouTube Video 13/10/08
You can see a short YouTube video of my progress here
Update #4 18/10/08

I've now implemented multiple drawing layers, including a parralaxed background. The background scrolls slower than the other layers (any number of layers can be used).
All that I've got at the moment is a bit of a tacky starry background.
At the moment though I'm having a bit of trouble calculating how fast the background should be scrolling because it's not a fixed value, but scrolls depending on the size of the background layer. I have been working on trying to get this working properly for days and it still doesn't. So I'm leaving it in a semi-finished state until I can get it working so I can work on other features.
If someone could give me a pointer with that it would be helpful. Drop me a PM or something.

I started working on graphics and then completely forgot that the pandora is at such a high res on a small screen. So I scrapped them and started again.
So I guess now I should tell everyone about my game.

MONSTER! is a game in which you play a young lost little monster, rampaging around town, eating people and doing it by jumping between/scaling buildings.

The only graphics I have so far after scrapping all the low-res graphics is one frame of the monster so I'll provide a screenshot of that at least.

 

[skeezix]

Best shmest, use whatever

Traditionally 'tiles' are 16px square (look at screenshots fro your SNES/ST/Amiga etc era) but you can use anything.

To make rendeing easier in my tile engine I allowed for definition of a object as a group of tiles, and then allowed peopel to drop in the object. ie: I'd lay out a house in a mini-tile-map, and allow people to re-use 'house' whenever the3wy wanted; made for more consistency, but might be too much work for you, and possibly no pay off.

In my engine I allow for variable size maps (As you just added), and variable gravity (why not?) and gravity in any of the 4 cardinal directions (why not?), .. can make things interesting

Go nab some graphics from Zelda or somethig (Easy to find), and at least your screenies will look good until you get your own artwork

jeff

 

[cosam]

In my engine I allow for variable size maps (As you just added), and variable gravity (why not?) and gravity in any of the 4 cardinal directions (why not?), .. can make things interesting

The gravity thing is incredibly handy if you want to make e.g. a space-/walking-on-the-moon-type level, simulate being underwater, side-wind, etc. Or set all gravities equal, add optional automatic scrolling, and you've got yourself a shoot 'em up ;-)

 

[chris_r]

Ok, well when I said 'best' I meant a good trade off between size and effort. Tiles too big will make the levels a bit too crowded, and tiles too small will make the levels more difficult to design

 

[skeezix]

Depends a lot on screen resolution; in my engine I also made the tile size #define (rather than truly dynamic) since it was trivial and very handy. ie: All calculations shoudl be by macros or functions (Depending n your language of choice, but a fast option. In C I used straight #define macros).. so I have essentially a tile-width and a tile-height macro (incase I wanted 16x32 or something), and then I use macros to figure out a tile (x,y) nased a pixel coord pair (px,py).

So a map (2d layer) is tx*ty tiles, where each tile is px*py size in pixels. (Plus things like gravity in each direction, lighting, and an actual map might be multiple layers with transparent tiles, so you can do overlays.. a house layer on top of a background of forest, or whatever.)

Since macros control the most basic tile stuff (very trivial, only a couple things), I can arbitrarily go from 16x16 [pixel tiles to 32x32, or 32x64 or whatever; the hard part is swapping in new artwork, but I also added a image scaler so if you happen to feed it 16x16 pixel tiles, gthen change the #defines to make them 32x32, and forget to swap in the new artwork, it'll stretchscale the source images to fit, so it at least renders.

All the work is at load time.. run time is blinding fast.

Tile engines are fun!

jeff

 

[fusion_power]

I'm always for tile based Platformers especialy with alot of Parallax Layers. So keep on going! ^_^
I had tested some graphics for myself a while ago, I used this "Scrolling game Development Kit" to make the graphics move like they should move (more or less).
I had to fight alot with the tiles itself, and because I'm lazy, I only made 32x32px Tiles for the foreground even if 16x16 tiles would be more flexible. (many Elements there are 16x16 but realized with 32x32px tiles - NOT recommended! ) For the big parallax layers in the Background I used 128x128 and 64x64px tiles but only because the BG was one big pic and the SGDK has the nice ability to use various tile sizes in one game. Even if the SGDK is so limited (only 45° slopes, to rough sprite collision detection, no permanent scrolling clouds, no real transparence) there can be done amazing things with some sprites and a good background, here some pix just for fun (the Sprite is not made by me of course! ):

older:.........................newer:


It looks good onto the GP2X (320x240) but I'm sure this would also fit into the Pandora. But I would recommend something like 400x240 and then hardware double the pixel to fullscreen to keep the retro look but I haven't a Pandora yet for testing.

I hope there will be a good bunch of Homebrew platformers for the Pandora, I would like so see someMetroid-Style Gameplay and Level-Design. (a overview Map, visit each place more than once, go forward and backward through the levels, Item-system and upgrades to reach new places, polished gameplay and polished movement etc...)

 

[Flat]

yay for custom sonic game :lol:

 

[skeezix]

Fusion -- wow, that looks stunning .. but I guess ripping commercial artwork will do that

nice

jeff

 

[fusion_power]

Fusion -- wow, that looks stunning .. but I guess ripping commercial artwork will do that

nice

jeff

You should see it moving, I love Parallax-Effects so I have 2 BG Parallax Layers and some more Parallaxing clouds. ^^

"ripping commercial artwork"? :lol: But the whole fun is pixeling all these graphics. OK I wouldn't do it again, the graphics costs me many weeks because I'm not that super-Graphic-Talent. I had to do a little cheating with rendering the first Parallax Layer with Blender (yes it was completely 3D! ) and then using Photoshop for pixelating the whole story. Some Elements from the forefground are also constructed with Blender (Metal beams and pipes etc.) because only skilled people can do all the Shadows and materials per hand.

I'm sure we have enough talented GFX Artists here for creating a great 2D game without using existing graphic tiles.

 

[Reesy]

@fusion_power: You did the graphics yourself!, nice work mate

 

[chris_r]

Update #2 08/10/08

The level can now scroll horizontally (Mario style) and the character now properly detects collisions between certain tiles.
All level details are now loaded from the level file.

Now I need to implement multiple level layers. I'm thinking 3 of them, but someone tell me if I'm wrong.
One in foreground (in front of character)
One in background (behind character)
One for scenery (parallax skys and stuff like that)

 

[kloplop321]

sounds like it is progressing, but there is a lot more to go if it is going to get there on time. I hope you the best of luck

 

[fusion_power]

@fusion_power: You did the graphics yourself!, nice work mate

Except Sonic of course. Oh, an I've used the hanging Iron-chains from SonicCD.

Now I need to implement multiple level layers. I'm thinking 3 of them, but someone tell me if I'm wrong.
One in foreground (in front of character)
One in background (behind character)
One for scenery (parallax skys and stuff like that)

If the clouds also scroll, you may need more than 3 Layers...maybe? ^_^ I know there can be done crazy things with "Line Scroll" and "Raster Effects" (AFAIK this costs very little processor power even with dozends of scrolling layers) but I have no clue how complicated it is to code this.

Oh, in the Scrolling Game Development Kit I've used you can skip one additional foreground layer. Every Tile in the foreground (Player-layer) without collision detection is automaticly behind the Player Sprite. So in my example I only needed one layer for the foreground and I covered also the foreground Graphics behind the Player.
So I only needed a additional foreground layer for things in front of the Player. maybe this could be a option to keep things more simple. 3 seperate Layers for the foreground can do more flexible things of course

 

[chris_r]

sounds like it is progressing, but there is a lot more to go if it is going to get there on time. I hope you the best of luck

Yes well I am fitting this around my Uni work so I'm trying. But I will likely need to enlist people's help for certain things like music that I can't do.

Oh, in the Scrolling Game Development Kit I've used you can skip one additional foreground layer. Every Tile in the foreground (Player-layer) without collision detection is automaticly behind the Player Sprite. So in my example I only needed one layer for the foreground and I covered also the foreground Graphics behind the Player.
So I only needed a additional foreground layer for things in front of the Player. maybe this could be a option to keep things more simple. 3 seperate Layers for the foreground can do more flexible things of course

Yep, I'm trying to make the code quite flexible. I don't want to completely exclude the front layer (Iook at the scaffolding in your old sonic screenshot) but it's better to include it and then not use it if a map for it is not found in the file.

 

[fusion_power]

Yep, I'm trying to make the code quite flexible. I don't want to completely exclude the front layer (Iook at the scaffolding in your old sonic screenshot) but it's better to include it and then not use it if a map for it is not found in the file.

The most flexible thing would be, if the engine can handle a flexible ammount of layers. If you need 3 layers, define 3 layers, if you need 5 layers, set 5 or if you don't need a foreground layer, completely disable it etc...
One layer is defined as player/sprite Layer and the rest is flexible. maybe 3 BG and 1 foreground layer or 2 foreground and 1 BG Layer? Who knows?
In the SGDK I've used ( http://gamedev.sourceforge.net/ ) this is solved this way. You simply define the scroll rate of each layer (speed) in x and y direction and add the layers in front or behind the player-layer. (my front-layer has the same scrolling rate like the sprite-layer so it looks like both are onto the same layer)

 

[chris_r]

The most flexible thing would be, if the engine can handle a flexible ammount of layers. If you need 3 layers, define 3 layers, if you need 5 layers, set 5 or if you don't need a foreground layer, completely disable it etc...
One layer is defined as player/sprite Layer and the rest is flexible. maybe 3 BG and 1 foreground layer or 2 foreground and 1 BG Layer? Who knows?
In the SGDK I've used ( http://gamedev.sourceforge.net/ ) this is solved this way. You simply define the scroll rate of each layer (speed) in x and y direction and add the layers in front or behind the player-layer. (my front-layer has the same scrolling rate like the sprite-layer so it looks like both are onto the same layer)




Well it's nice that you're offering suggestions and quite often quoting from the SGDK, but remember I have very little experience with C++, let alone SDL, so I'm learning as I go along.
For the time being it will be quite a bit easier to keep a hardcoded value and then deal with dynamically defining the game at a later date (if it is needed)

 

[OogyBoogy]

I find that 4 backgrounds is basicaly all you'll ever need for a retro style game. Any more backgrounds and you're just wasting time rendering seperate layers to the screen.

With my system though, everything is dynamic, from the number of backgrounds to the size of their tiles to the actual position on-screen.

 

[fusion_power]

It was just a suggestion, I have no noticable coding skills (even with over 2 Years of C and Turbo Pascal in school :lol: )

And yes, you can do great games even with only one BG (Parallax) Layer, look at Super Metroid or the GBA Metroids for Example. There is "just" one foreground layer (+ elements in front and behind Samus) and a BG Layer (sometimes parallax, sometimes not, or only in one direction parallax etc...) the black-fading when entering a door is only because the Engine changes the BG Layer and/or the scrolling method.

 

[chris_r]

Update #3 13/10/08
The character now properly jumps and collides with tiles directionally. The character now properly reacts to tiles properly as well ie. acting under gravity. Not moving further if a tile is blocking the way etc.
Cleared up the last of the hardcoded code. All the level details are now loaded from the level file so that levels can be in a completely independant style from the original levels.
I removed all the debugging bits I had put in before to test, and cleaned up the code. (Probably doesn't actually make much of a difference in speed but it's good to keep code clean)
Fixed a bug where the tiles would only blit if an image was loaded.

I will likely upload a youtube video soon of the game in action (albeit still without proper graphics)

 

[chris_r]

You can see a short YouTube video of my progress here