Rockbox

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Patches
  • Category Games
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by syn4pse - 2008-02-26

FS#8647 - Amaze - 3D maze game plugin

This is a 3D maze done in vector graphics. I ported David Leonard’s program, which was done with the curses library. Initially, I wrapped the curses functions he used in order to draw the maze with putsxy().
This code is not used at the moment, as the vector graphics are easily scaled and more pleasing. The only issue I see is with the user map, which may be harder to draw on a smaller screen. I developed this on the iPod Video.

This is my first attempt at an open source project, and is a refresher in C for me. I apologize for style. I have tried to make the code as clear as possible.

Major changes.

Amaze now works on the suggested platforms (simulated) on the Rockbox Wiki (HowToVerifyPlugins page) and on my iPod Video.
Some extraneous code (ncurses porting) was removed.
The map screen now scrolls if the screen is not large enough to accommodate it.
There is a new option to use smaller map tiles (7x7) versus the regular map tiles (9x9).

TO DO:
- Clean up menus
- Clean up or remove //comments
- Convert tabs→spaces to conform with standards
- Find willing testers!

I'd like to test this for my Gigabeat F, but my laptop (where my build environment is) is having hardware problems. Since I can't compile it myself, could you post some screenshots or pictures so that others can know what it looks like? It sounds interesting.

Fixed: Added a lcd_update for 1bpp platforms.

Attached are fmrecorder/Gigabeat main and map view screenshots.

TO DO:
- Implement walked path highlighting on 1bpp, probably by highlighting select pixels

I have no idea whatsoever how the walls/floors/ceiling are rendered, but would it be possible to allow user defined pictures for them? In the Windows screensaver, I once made a forest by changing the wall pic to trees, the ceiling to green, and the floor to brown. It'd be neat to be able to do that here. Of course, it's just a thought. I like it as it is right now, so that added feature would be unnecessary. I just thought I'd bring it up.

A friend built this for me, so now I have some user-info to provide. It looks like all the options are given as "1" or "0." Might I suggest you instead use "Yes" or "No?" It'd make usability a little better. Also, for the Gigabeat, how do I access the map? I pushed all the buttons, but I could never figure out how to access it. Because everything is identical, it makes it a little difficult to get unlost. The "walked" pathway (brown for traveled, black for untraveled) helps, but a map would be quite useful. And what does the arrow point toward? I assume it points toward the end/finish, but when I found a red floor piece, the arrow was pointing away from it. I assume the red floor piece is the end/finish, since it said "You Win" when I stood on it.

In regards to my above idea/request, perhaps a directory could be made in .rockbox where the pictures are stored. "/amaze" for example. Floor.bmp, wall.bmp, and ceiling.bmp or something wouild be inside this directory. Perhaps even multiple directories could be inside the amaze directory, to allow for multiple settings. Example: "/forest" would contain floor, wall, and ceiling pictures that resemble trees; "/city" would have pics that resemble buildings, sky, and a street. From the "main menu" of amaze, you could have a setting like "Use custom walls" and inside there, people would be able to select the directories they've made in "/amaze." Again, just ideas. Since I'm not familiar with the engine in use, this might not even be possible. I just thought I'd throw in my 2 cents while it's still in development.

One last idea I had is to throw in random items throughout the maze to liven things up. If the maze is randomly generated, then randomly generate locations for objects to go, be they pictures on the wall, objects in the "halls" or whatever. Maybe that'd be easier than allowing for custom textures?

I am rendering the walls by drawing rectangles and triangles (line by line). It took me a while to figure out the trigonometry :D but it has been a fun ride…

I do want to have true/false instead of 0/1. I'm still figuring out the menu API.

I would love to render bitmaps instead or optionally – that's a great idea, and having a user-defined one would be key. I have to figure that one out, possibly by drawing tiles? I'll look into it.

Pictures/posters are a good idea. The walls can get a tad boring - you should have seen them before the stripes… I'm going to jazz up the floor, and probably throw a .bmp of a sky (for players which support 16bpp).

I also haven't thrown in documentation. The arrow is a compass that always points north (up). I used a plugin_actionlib.h which defines all of the target buttons at once….

UP → forward (main view), scroll up (map view) *
DOWN → back (main view), scroll down (map view) *
LEFT → rotate left (main view), scroll left (map view) *
RIGHT → rotate right (main view), scroll right (map view) *
EXIT/QUIT → pause menu (main view), quit map (map view)
DOWN (REPEAT/HELD DOWN) → map view

*if screen is smaller than map

I don't know how feasible this is, but if a LONG-press is used on the directional buttons (in map mode or otherwise), then it will go in whatever direction is pushed until the user lets go. For accessing the map, could you put it on a different button? The Gigabeat has at least 3 unused bottons, and I'm sure that most (all?) other targets have at least 1 unused button that the map could be put on.

Since pictures aren't currently possible, perhaps an option to alter the colors used? As for a "sky," I like it the way it is. I feel like I'm on some sort of dungeon crawler game, minus the baddies, traps, and multiple levels. Also, maybe you can have an option where people can specify the size of the map to work with. On the Gigabeat, I've had to scroll left or right, but never up and down (I realize the Gigabeat has a "tall" screen, so this isn't a big surprise). It'd be nifty to allow people to specify just how large, or small, the map's dimensions are. Perhaps a Length→list-1-9 and a Width→list-1-9 (or larger?) or something? Perhaps someone will disagree with me, but I actually find it fun to get lost (and try to find my way) in the larger maps.

In truth, if you were to listen to and implement all the ideas I get when I see this, you'd end up expanding it into a (possibly) immersive dungeon crawler, with bad guys to fight, multiple levels to wade through, experience points for your "character" and perhaps more… So yah, while I think that'd be great, I think that for now it'd be best to leave it as a maze game. Custom textures, colors, and map sizes would be nice. Right now, the custom map sizes would probably be the easiest to implement (I have no idea how the colors you've chosen work in the code). Perhaps instead of numbers, difficulty settings could be use? "Easy" is small, "Normal" is medium, and "Hard" would be large? Perhaps a "Super Hard" for really big maps?

As for documentation (for anyone else trying this out), I'll add some things I noticed with the map:

# == an unexplored opening. If you look down a corridor, and there's branches off of it, you'll see "#" at those branches.
+ == the path you've traveled.
→ == compass, always points "north"
:) == Goal (It's a smiley. It was the best I could do with text)
house == Start

I think that's everything from me for now. I like it, and I can see me wasting much time wandering aimlessly through these mazes. Good luck on getting it commited!

I just realized I said "then it will go in whatever direction is pushed until the user lets go" when what I meant was "then could it go in whatever direction is pushed until the user lets go?"

TO DO:
- Implement LONG presses as Mouser X described (omitting LONG presses for Left/Right in main view mode – who wants to get dizzy?)
- Add a Help menu option to main menu to give directions. (thanks Mouser X again)
- Change 0/1 to False/True, 7x7/9x9 tiles, Small/Medium/Large/Insaaane etc. I don't know the syntax of the Menu yet (and would WELCOME input on this – I am sure it's a simple change).

On the /map/, Mouser X, just to clarify, the wedge points to where you are /facing/. It only points north on the main display.

A choice of colors would be nice… i had a heck of a time picking the right colors, using web pages to grab the color codes. The bitmaps were easy but the actual maze drawing colors – they didn't come out like I planned. If you come up with better colors, there are only like six to change in the code (COLOR_PERP, COLOR_PARA, COLOR_GROUND, COLOR_VISITED, COLOR_SKY, COLOR_COMPASS, I may be missing one) and you plug in the HTML codes (converted to decimal from HEX). I'm open for suggestions. Of course, this become irrelevant for displays < 16bpp.

Also, in the QUIT menu, the save game functions well, if one needs to eat lunch (mazes make you hungry). It dumps a small text file to your device, about half the size of a standard vt100 terminal (43? x 23). This is from the original code which had to fit on one screen.

One thing – drop all of the bitmaps in apps/plugins/bitmaps/native before you compile. (thanks Adam). I should probably add a folder structure to the bitmap .zip archive to help clarify this.

I'm glad you enjoy the mazes, Mouser X. I used to play games like this when the Apple ][ was around… a simple concept but a tough game, especially with no map.

I'll have to take a look at the map generation routines. Currently, the map is generated by 'digging' a path through solid walls with an array of pointers. I have to figure out how to scale the size of the array non-wastefully depending on the size of the map. I don't believe a slightly larger array would cause any memory issues, but I ran into stack problems at first. I believe it could be done fairly easily, by just changing a few numbers in the code… i'll experiment a bit.

This project is a port of Amaze (http://www.adaptive-enterprises.com.au/~d/software/amaze/) – a public domain maze game which I ported, having to rewrite the drawing routines. I believe it could be done fairly easily, by just changing a few numbers… i'll experiment a bit. I've written to David Leonard and he's happy I'm porting his program. Take a look at it – it's a seriously cool game, done using the ncurses library so you can run it in a terminal. The original port I did was done with his character rendering and it looked very retro, but I couldn't scale the character cell code to smaller lcds (partly because I had trouble understanding his logic and partly b/c the small screens are just too small to make a fake terminal window).

Izzeh commented on 2008-03-21 08:21

Hmm the images file doesn't appear to work.. it just extracts it as a 2kb FILE… maybe it's my fault but I tried 7-zip, winzip and winrar… could someone possibly upload it to another site? www.savefile.com for example?

More TO DO:
- Let the user put a small mark on the floor where he is standing… either with an unlimited number of marks, or just ten… easily implemented. These would be visible as dots or X's on the ground.

Isaac - use the updated images file from the comments… the first one only has one image… they get extracted to apps/plugins/bitmaps/native (see above comment).

Izzeh commented on 2008-03-21 08:29

Whoa thanks for the fast answer.. but yeah.. I did.. and when I extract it it just creates an extensionless file named amaze_bmps .. I've had it happen a few times using flyspray so maybe its the site…

Izzeh commented on 2008-03-21 08:32

Nevermind.. I managed to get it working by browsing into the FILE through winrar and extracting the images… really weird :S

No problem. I hang around my computer all day waiting for comments… yeah right! :D

Anyway… put a .zip extension on it. It's a zip archive… see if that works?

In regards to placing a mark on the floor, perhaps it could be an arrow that points in the direction you're facing when you place the mark? I'd use it to designate which direction I need to go, in case I need to backtrack. Since I don't know how you'd be storing it, perhaps that's not possible?

A directional mark is a great idea. Basically, each cell in the grid has a character associated with it, to indicate what kind of mark it is (visited (+), obscured (#), etc), so since the cell the user wishes to mark has to be visited (he's standing on it), the + could be changed to N, S, E, or W. Good call.

Thanks for all of your input… I can implement most of your suggestions the next time I address the code.

One thing, though… I think I'll have to add the option to turn off the compass from the in-maze menu (and remove it from the initialization menu), as it would obscure a directional mark on smaller displays. It would be hard to show both the compass and yet another arrow on the same square.

CHANGED:
Added option to mark floor. (FIRE button, Select on iPod). The mark can be seen from a distance as a small 2x2 square.
Added option to erase mark on 'pause menu'
Compass can be briefly displayed by hitting FIRE + DOWN.
Maze size is now chosen in initial menu (Easy – 20x20, Medium – 40x40, Hard – 60x60, Expert – 80x80).
Load map/save map were changed to handle new maze sizes and chalk marks.
Changed boolean menu options to Yes/No instead of 0/1.
Long presses of Up/Down in the main view repeat movement forward/backward. A long press in map view will repeatedly scroll the map in the direction pressed.
Changed color of floor.

TO DO:
Instruction page
Remove old commented code if no rain is in sight
Make colors more appealing

You left some odd cruft in the patch, here's a cleaned one.

* Sync to SVN r17527
* Optimize use of lcd_drawline and use lcd_vline instead where possible.

Admin
fg commented on 2008-10-10 19:39

* typedef struct… is against the rockbox coding style
* you should at least provide some text to put in the manual, or (if you know LaTeX) a full manual patch
* It uses PLA for button definitions. depending on the controls, they can cause issues
* void\n foo\n (int bar)\n is definitely not common
* c++ style comments have to go
* put { on an new line at the beginning of functions

Rewrote map storage handling. Map is now stored in a one dimensional array.
typedef struct was removed to conform to rockbox coding style.
c++ style comments have been removed and cosmetic changes have been made to conform to rockbox coding style.

Added a Show Solution option to the in-game menu.
Still using PLA for button definitions (to be changed). Changed all instances of button_get(true) to button_get(false).
Various bug fixes.

Preferences are now saved to disk.

Synched to SVN r19869.

Someone want to resync this?

Synched to r22382.

Moved floor marking command to the game menu.
Fixed small bug with the end game messages.

Oh good I've wanted to try this. Thanks!

Fixed a major bug with the movement keys. Keys should now be correctly defined for all platforms.

Whoops, had some extra stuff at the end of the patch. Here's the cleaned up version.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing