Forums

Project: Chu Chu Rocket GG
Repo: https://github.com/the60ftatomicman/ChuChuGG
----------

Why:
This is my first project with the SMS/GG platform. I got bitten by the z80 bug when I was debugging the arcade game Arkanoid and needed to slightly learn the instruction for purposes of finding where rom hack logic checks were inserted (https://github.com/the60ftatomicman/Artanoid if you want to try the app!)

Chu Chu Rocket is a game I'm fond of, it's rather simple (puzzle mode at least) and there's already 100 predesigned levels. Seems like a natural fit for a first game to try and port! There isn't a ton of logic regarding input -- it's mostly an exercise in animation.

----------

Refresher on the OG Game:
It's similar to Lemmings. The user is presented with a 12H x 9V grid filled with walls; chu chu's; cats; rockets; and holes.
The goal is to put arrows down on specific tiles which will redirect the chu chus to the rockets. Level Complete!
Losing conditions are - If a cat hits a chu chu; if a chu chu falls in a hole; or if a cat hits a rocket.
Anytime a creature hits a wall (cat/chuchu) they turn right(? cat my turn left!) and thats it. There's your logic. There's 100 levels of this.

----------

Overall Architecture Design:
GG and SMS only allow 8 sprites per line; which has lead to the biggest design aspect for this whole exercise. At times we can have more than 8 chuchu's on a line as well as cat; therefore this must all be done with tiles. The basic loop whilst in a level will be

--
Update each individual board tile in RAM
Do a palette swap (for animation)
Update VRAM addresses that correlate with the BOARD tiles only
Repeat until a lose condition is met
--

I've been spending a TON of time to demo and see if this is viable given the timing restraints and so far... it is!

----------

Constraints:

8x8 tiles only - Sadly there isn't enough visible screen to show groups of 4 as a tile to really get nice looking sprites.

Non-Alternating floor colors - in the OG game the floors are often alternating colors. I don't have enough tilespace to handle this due too....

Limited Animation - I originally envisied the alternating tile floors AND having 6 frames of animation per "movement" to each tile.
This would encompass the chu chu walking 1 pixel each frame. The math just. doesn't. work. I'd need like 1000+ tiles I believe it worked out to?
This is including using flags to reduce unnecessary tiles (which... in a moment I'll discuss may NOT be feasible as well).

Limited VBlank time - To jump on the back of the limited animation comments; I also just don't have efficent enough code / ambitions here.
I have to spread the updates to the board over 9 frames before I trigger a redraw of the board.
This leads to some choppy looking animation;

Unable to really use sprites - since I need 12+ characters on a single line I cant use the foremost characters as sprites. This has a ripple effect that I need to make lots of tiles to
handle every condition that could possibly exist in a tile.

----------

Goals:

I want to get one (just One!) Level demo built. Sans a title screen. If I can get a single puzzle level built I'll be happy and possibly pick this back up and see what compression and efficiency methods
I can implement for a better experience.

----------

Art coming soon once I get it looking prettier. I just ported over to using BMP2Tile for generating graphics so things are all out of whack on my local build

Where I am 5/15

1) Tile Generation (aka how's the art?)
- Placeholders exist!
- They work for the development process; they could absolutely be refrined
- I'm moving on from this since it is easily my biggest time sync for least amount of gain
- Need to generate CAT tiles; worried about space.

2) Level Loading Logic
- Rough but works!
- Need to develop a compression method

3) Character Animation
- it's just palette Swapping
- I could better this function and gain more VBLank if I didnt reload the entire pallet EACH redraw.
- Realistically I'm just swapping 2 different palettes.
- Have not

4) User Controls
- nothing yet, focusing on....

5) Gameplay Logic
- Reminder: Chu Chu rocket is akin to setting up dominoes and watching them fall.
- The parsing of the tile levels is slower than I realistically want but at least setup to be improved with a single .define modification
- I'm running into data model issues
---- I store my level in RAM at C200 (current state) and C2E0 (intial state)
---- Each RAM location just contains a tile IDX.
---- I keep 2 copies when a ChuChu,Cat, or Arrow leaves a tile I know what it should look like unoccupied
---- I'm going to need a new section of ram to keep a state of the FUTURE row values it seems
-------- This is because in theory a chu chu train (ha!) moving right will continually keep generating chuchus
---- I could in theory rewrite the update logic to be more precise and possibly track each object in RAM
-------- I am currently updating every tile, this would be more complex but possibly more efficient?
- I haven't incorporated ANY collision detection but don't expect this to be hard.
---- If tile is X and we want to update it to Y (so think if chu chu and we want to update it to cat) we have an end game
---- If tile is a chu chu combined with specific wall type, update to this NEW chu chu and wall type
---- I am thinking of having what i'd call a transform table handle this. Basically if you are tile X we know no matter what you should be tile Y next.
-------- IDK if I have the RAM for this but in theory I think I do?

6) Screenshotless
- I switched to using BMP2Tile for artwork (was just using windows calculator than a static webpage I built for single tile generation) so now my palette is off
- my tile indexes are off from where I originally wrote them as well. Ah well, ill get it back to where it was and screenshot it.

the60ftatomicman wrote

GG and SMS only allow 8 sprites per line; which has lead to the biggest design aspect for this whole exercise. At times we can have more than 8 chuchu's on a line as well as cat; therefore this must all be done with tiles.

I would say - it depends. If you <sometimes> have more than 8 sprites on the same scanlines, then it's fine to have them flicker a bit - that is make sure that those disappearing aren't always the same ones, which -if done correctly- will ensure up to 16 sprites will be VERY visible (drawn on 50% of the frames at least)...

Interesting! If tiles seem to go the way of the dodo and I hate the overall look I might go back and investigate how much I could potentially squeeze out of the sprites per line view.

In theory I counted like 12 chuchus + cats on a screenshot.

I really like your project idea. My very first game was on Game Gear too. It is a great hardware to try and learn.

Here is a suggestion. If you are going for a MS/Game Gear game, why not design the game/port around the limitations of the console ?

For sure, you can try to stick with the original as close as possible, because your first intent is to create a port.

But there is another approach, that is to think around the limitations of the console and adapt the game-design according to it.

This means having level layouts that fit specifically in 160x144, maybe ? Limiting mice to a smaller number. Designing levels so having more that 8 sprites aligned is impossible ? If you know exactly how your cats behave, you can for example make sure to never have more than 7 mice and 1 cat on a line at any moment.

Sure this means creating brand new stages, but it would be more of a "perfect fit" for the console. This would remove any flickering and make for a much more enjoyable experience in terms of visuals. Otherwise you absolutely need to implement a solution as suggested by sverx to rotate your sprites in memory so that some of them don't totally disappear.

This is only a suggestion of course, something that I would have done if I had pursued such a project myself. Don't let me influence you ! Haha :)

Note : anything that moves will look much better with sprites for sure.

Best of luck with your project !

In BMPtoTile there is an option to check : always generate 16 colors.

Images of Progress
-- some mock tiles just for developments sake put together
-- Yes I know they aren't mirroed (thus saving space!) but the non-mirrored tiles may actually factor into a performance boost. Without mirroring I may be able to build a sort of lookup table in which you loop to find your index value than increment by 1 to become the "new" value. IDK still working on it

-- movement demo attached, It's the best I can get sans flickering atm. Looking to improve the performance.

test.png (1.95 KB)

movement.gif (82.38 KB)

Suggestions noted and I think adapting to the limitations of the hardware was (as always) the winner.

Screenshot below was after spending time figuring out how to marry using GIMP as my tile editor with BMP2Tile.

I was able to fit in shadows, get my alternating floor back...all sorts of stuff.

Is there gameplay? No. That's going to be reworked but I plan on writing up a "GIMP -> Tiles" tutorial pipeline since it's anything but intuitive which imo is par for the course with GIMP.

Let me know how it looks!

update_5172024.png (7.36 KB)

It looks good indeed. You are not forced to make a rectangle layout though. You can keep a larger level, you simply need to make sure that it is not possible to have more than 8 sprites on a single line at a given time. Makes designing more challenging !

Very interested to see how this develops!

Author	Message
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	[WIP] Chu Chu Rocket for the Game Gear Posted: Wed May 15, 2024 3:00 pm
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Project: Chu Chu Rocket GG Repo: https://github.com/the60ftatomicman/ChuChuGG ---------- Why: This is my first project with the SMS/GG platform. I got bitten by the z80 bug when I was debugging the arcade game Arkanoid and needed to slightly learn the instruction for purposes of finding where rom hack logic checks were inserted (https://github.com/the60ftatomicman/Artanoid if you want to try the app!) Chu Chu Rocket is a game I'm fond of, it's rather simple (puzzle mode at least) and there's already 100 predesigned levels. Seems like a natural fit for a first game to try and port! There isn't a ton of logic regarding input -- it's mostly an exercise in animation. ---------- Refresher on the OG Game: It's similar to Lemmings. The user is presented with a 12H x 9V grid filled with walls; chu chu's; cats; rockets; and holes. The goal is to put arrows down on specific tiles which will redirect the chu chus to the rockets. Level Complete! Losing conditions are - If a cat hits a chu chu; if a chu chu falls in a hole; or if a cat hits a rocket. Anytime a creature hits a wall (cat/chuchu) they turn right(? cat my turn left!) and thats it. There's your logic. There's 100 levels of this. ---------- Overall Architecture Design: GG and SMS only allow 8 sprites per line; which has lead to the biggest design aspect for this whole exercise. At times we can have more than 8 chuchu's on a line as well as cat; therefore this must all be done with tiles. The basic loop whilst in a level will be -- Update each individual board tile in RAM Do a palette swap (for animation) Update VRAM addresses that correlate with the BOARD tiles only Repeat until a lose condition is met -- I've been spending a TON of time to demo and see if this is viable given the timing restraints and so far... it is! ---------- Constraints: 8x8 tiles only - Sadly there isn't enough visible screen to show groups of 4 as a tile to really get nice looking sprites. Non-Alternating floor colors - in the OG game the floors are often alternating colors. I don't have enough tilespace to handle this due too.... Limited Animation - I originally envisied the alternating tile floors AND having 6 frames of animation per "movement" to each tile. This would encompass the chu chu walking 1 pixel each frame. The math just. doesn't. work. I'd need like 1000+ tiles I believe it worked out to? This is including using flags to reduce unnecessary tiles (which... in a moment I'll discuss may NOT be feasible as well). Limited VBlank time - To jump on the back of the limited animation comments; I also just don't have efficent enough code / ambitions here. I have to spread the updates to the board over 9 frames before I trigger a redraw of the board. This leads to some choppy looking animation; Unable to really use sprites - since I need 12+ characters on a single line I cant use the foremost characters as sprites. This has a ripple effect that I need to make lots of tiles to handle every condition that could possibly exist in a tile. ---------- Goals: I want to get one (just One!) Level demo built. Sans a title screen. If I can get a single puzzle level built I'll be happy and possibly pick this back up and see what compression and efficiency methods I can implement for a better experience. ---------- Art coming soon once I get it looking prettier. I just ported over to using BMP2Tile for generating graphics so things are all out of whack on my local build

the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Posted: Wed May 15, 2024 3:16 pm
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Where I am 5/15 1) Tile Generation (aka how's the art?) - Placeholders exist! - They work for the development process; they could absolutely be refrined - I'm moving on from this since it is easily my biggest time sync for least amount of gain - Need to generate CAT tiles; worried about space. 2) Level Loading Logic - Rough but works! - Need to develop a compression method 3) Character Animation - it's just palette Swapping - I could better this function and gain more VBLank if I didnt reload the entire pallet EACH redraw. - Realistically I'm just swapping 2 different palettes. - Have not 4) User Controls - nothing yet, focusing on.... 5) Gameplay Logic - Reminder: Chu Chu rocket is akin to setting up dominoes and watching them fall. - The parsing of the tile levels is slower than I realistically want but at least setup to be improved with a single .define modification - I'm running into data model issues ---- I store my level in RAM at C200 (current state) and C2E0 (intial state) ---- Each RAM location just contains a tile IDX. ---- I keep 2 copies when a ChuChu,Cat, or Arrow leaves a tile I know what it should look like unoccupied ---- I'm going to need a new section of ram to keep a state of the FUTURE row values it seems -------- This is because in theory a chu chu train (ha!) moving right will continually keep generating chuchus ---- I could in theory rewrite the update logic to be more precise and possibly track each object in RAM -------- I am currently updating every tile, this would be more complex but possibly more efficient? - I haven't incorporated ANY collision detection but don't expect this to be hard. ---- If tile is X and we want to update it to Y (so think if chu chu and we want to update it to cat) we have an end game ---- If tile is a chu chu combined with specific wall type, update to this NEW chu chu and wall type ---- I am thinking of having what i'd call a transform table handle this. Basically if you are tile X we know no matter what you should be tile Y next. -------- IDK if I have the RAM for this but in theory I think I do? 6) Screenshotless - I switched to using BMP2Tile for artwork (was just using windows calculator than a static webpage I built for single tile generation) so now my palette is off - my tile indexes are off from where I originally wrote them as well. Ah well, ill get it back to where it was and screenshot it.

sverx Joined: 05 Sep 2013 Posts: 3859 Location: Stockholm, Sweden	Posted: Wed May 15, 2024 3:23 pm
	the60ftatomicman wrote GG and SMS only allow 8 sprites per line; which has lead to the biggest design aspect for this whole exercise. At times we can have more than 8 chuchu's on a line as well as cat; therefore this must all be done with tiles. I would say - it depends. If you <sometimes> have more than 8 sprites on the same scanlines, then it's fine to have them flicker a bit - that is make sure that those disappearing aren't always the same ones, which -if done correctly- will ensure up to 16 sprites will be VERY visible (drawn on 50% of the frames at least)...

the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Posted: Wed May 15, 2024 5:46 pm
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Interesting! If tiles seem to go the way of the dodo and I hate the overall look I might go back and investigate how much I could potentially squeeze out of the sprites per line view. In theory I counted like 12 chuchus + cats on a screenshot.

cireza Joined: 27 Feb 2023 Posts: 140 Location: France	Posted: Wed May 15, 2024 6:24 pm
cireza Joined: 27 Feb 2023 Posts: 140 Location: France	I really like your project idea. My very first game was on Game Gear too. It is a great hardware to try and learn. Here is a suggestion. If you are going for a MS/Game Gear game, why not design the game/port around the limitations of the console ? For sure, you can try to stick with the original as close as possible, because your first intent is to create a port. But there is another approach, that is to think around the limitations of the console and adapt the game-design according to it. This means having level layouts that fit specifically in 160x144, maybe ? Limiting mice to a smaller number. Designing levels so having more that 8 sprites aligned is impossible ? If you know exactly how your cats behave, you can for example make sure to never have more than 7 mice and 1 cat on a line at any moment. Sure this means creating brand new stages, but it would be more of a "perfect fit" for the console. This would remove any flickering and make for a much more enjoyable experience in terms of visuals. Otherwise you absolutely need to implement a solution as suggested by sverx to rotate your sprites in memory so that some of them don't totally disappear. This is only a suggestion of course, something that I would have done if I had pursued such a project myself. Don't let me influence you ! Haha :) Note : anything that moves will look much better with sprites for sure. Best of luck with your project ! In BMPtoTile there is an option to check : always generate 16 colors.

the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Posted: Wed May 15, 2024 8:11 pm
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Images of Progress -- some mock tiles just for developments sake put together -- Yes I know they aren't mirroed (thus saving space!) but the non-mirrored tiles may actually factor into a performance boost. Without mirroring I may be able to build a sort of lookup table in which you loop to find your index value than increment by 1 to become the "new" value. IDK still working on it -- movement demo attached, It's the best I can get sans flickering atm. Looking to improve the performance. test.png (1.95 KB) movement.gif (82.38 KB)

the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Posted: Fri May 17, 2024 12:57 pm
the60ftatomicman Joined: 30 Apr 2024 Posts: 16	Suggestions noted and I think adapting to the limitations of the hardware was (as always) the winner. Screenshot below was after spending time figuring out how to marry using GIMP as my tile editor with BMP2Tile. I was able to fit in shadows, get my alternating floor back...all sorts of stuff. Is there gameplay? No. That's going to be reworked but I plan on writing up a "GIMP -> Tiles" tutorial pipeline since it's anything but intuitive which imo is par for the course with GIMP. Let me know how it looks! update_5172024.png (7.36 KB)

cireza Joined: 27 Feb 2023 Posts: 140 Location: France	Posted: Fri May 17, 2024 5:25 pm
cireza Joined: 27 Feb 2023 Posts: 140 Location: France	It looks good indeed. You are not forced to make a rectangle layout though. You can keep a larger level, you simply need to make sure that it is not possible to have more than 8 sprites on a single line at a given time. Makes designing more challenging !

S.F Joined: 08 Apr 2005 Posts: 475 Location: Netherlands	Posted: Mon May 20, 2024 9:13 pm
S.F Joined: 08 Apr 2005 Posts: 475 Location: Netherlands	Very interested to see how this develops!

Forums

View topic - [WIP] Chu Chu Rocket for the Game Gear