Sokoban World v1.0

[D3thAdd3r]

*Edit-
Version 1.0
+Game has been completed. Thanks to everyone who played, tested, and motivated.

Features:

+50 levels divided into 5 "worlds"
+5 sets of graphics and music, 1 for each world
+50 demo solutions, 1 for each level(for when you are frustrated )
+11 *different Ram Tile Effects for screen dissolves and colored text
+Achievement system for completed levels and least move "Par" solutions(try to beat the CPU's solutions!)
+Original Sokoban gameplay, test out your spatial reasoning
+Other little stuff

[paul]

The presentation is massively improved. I really like these puzzle games and the differently themed levels keeps it fresh. Playing a vs match on Uzenet would be a ton of fun. The only thing I'm not overly keen on is the sound effect when correctly placing a crate. But maybe that's how it sounded in the original - I'm not sure.

It's starting to look like one of the better Uzebox games we've seen. With some nice music and a bunch more levels, it'd be pretty close to done. Even if you can only save a single custom level, I think it's a nice feature. They don't take too long to build and you could prepare them for a friend to attempt to beat and then clear it and make another.

Lee, you have so many things on the boil; you must have a very busy mind. I hope you can finish this and Lolo because they're both looking very nice.

[uze6666]

Impressive! The graphics are stunningly crisp and vivid, animations are great and smooth...it looks damn good, nothing to envy vs. the PC engine version! I played a bit this morning and, somehow, I got late to work! I understand that this is a "beta" and you are looking for comments to improve it, so I'll play more tonight and give you my comments.

Very well done, definitively one of the best looking game on the Uzebox so far, that raises the bar...keep it up!

-Uze

ps: added a pic to your main post!

[paul]

The auto solve is very cool. I wonder if it will work for custom levels Do you use a lookup table or can the algorithm be made succinct enough to fit on the chip?

[D3thAdd3r]

@Paul Thanks! Yeah box sound is temp. I have the 5 original songs and they are great but only in HES(Pc Engine) format, banging my head on this...
Yeah 1 user level may be enough. User maps are 2 tiles per byte so as to be consistent size even under worst case, so (15*14)/2 = 105 bytes. Actual static game maps are being converted to RLE (4bit Run - 4bit Tile#) which works great for these maps. Depending on size of music I could see bootloader and 100+ levels but then theres demos, and "world cut-scenes"...it could go a few different ways. Need to make the tools to actually compress the data now. Do you think solutions for every level, but less levels, would be better than more levels but fewer solutions? Considering you can jump to any level, are cut-scenes even warranted?

@ Uze
Please Alec, do not put your career at risk Thanks for the all the positive reinforcement! Geez, why didn't I think of a picture in a topic about my game ?... haha. Any ideas for a title screen/intro? Just seems boring sitting there flashing "WORLD". Seems you cannot modify 30 ramtiles in 1 vsync

@Paul
Yeah solutions are just tables, impossible on chip(problem is NP Hard). Maybe a demo record in the editor? Demos take 1 byte for every 4 moves so I don't know. The tools I am making will convert XSokoban maps to the game format and will have one for demos too. If someone wanted to they could just convert, copy/past, rebuild, done. 1000's of XSokoban format maps on the net.

I will finish lolo also, I tend to multitask when I get I/O bound on one idea. I don't know why, but I tend to accomplish things erratically like this.

[paul]

Do you think solutions for every level, but less levels, would be better than more levels but fewer solutions?

I think it depends on the trade-off. If you have to halve the level count to include solutions, I wouldn't bother with full solutions. If it's only say a 20% penalty, then I'd go with it. I imagine some of the complex levels could result in a relatively large lookup table (compared to the 105 bytes map maximum). Still, at 2 bits per move (how is that stored?), many wouldn't be too expensive.

Considering you can jump to any level, are cut-scenes even warranted?

Do you mean the dissolving of a finished level? If so, I like the effect, but I guess it means you need 4x the number of tiles (or however many frames that animation has). It'd be something I would be cutting before other areas of presentation, but I'd keep it if possible. I think 100+ levels is admirable, but I wouldn't consider that 25 levels to be a let down. As you say, the community can use tools to create their own levels and release them easily. I think people will remember authenticity and presentation more so than the extra levels. You could release your own level packs, too. Maybe rated as easy, difficult or veteran. The fastest solutions could go on the Uzenet hi scores table

The '1284 may solve some of these problems, too.

[D3thAdd3r]

I guess I'll just get the tools working and when I start seeing what the actual size of everything really is I'll have a better idea. Moves are just stored 2 bits like 00-up 01-down 10-left 11-right so 00011011 would be 4 moves: UP,DOWN,LEFT,RIGHT. The fade out effects, colored text, text with different backgrounds, is all ram tile manipulation, there is only one copy of anything so the only thing it costs is a little code space. I started thinking of effects like that when you demonstrated sprite curtains Paul, I just copy all the tile data to ram tiles, give a vsync since it's slow, set vram to those indexes with the same tile data and modify the ram tiles step by step. Only 24 unique tiles per level so it works out easy for this game. Egypt may even get a little heat wave mirage effect if I can figure that out correctly. I could cut the character graphics needed down by a lot by replacing colors after a sprite blit lots of possibilities, most pretty slow but possible for this game.

Cut scenes just have flags of the country, guy walking up to the horizon,...some other one time stuff like camels for egypt, etc..if I remember. I think if they are retained I'll just do ram tile indexes in vram then modify them from the original tileset data or something to make them look different. Reusable code is pretty dense compared to static graphics especially for one shot stuff like that. Anyhow, definitely should get music and sfx in before I get into any of that though just seems empty without it.

[paul]

I guess I'll just get the tools working and when I start seeing what the actual size of everything really is I'll have a better idea. Moves are just stored 2 bits like 00-up 01-down 10-left 11-right so 00011011 would be 4 moves: UP,DOWN,LEFT,RIGHT. The fade out effects, colored text, text with different backgrounds, is all ram tile manipulation, there is only one copy of anything so the only thing it costs is a little code space. I started thinking of effects like that when you demonstrated sprite curtains Paul, I just copy all the tile data to ram tiles, give a vsync since it's slow, set vram to those indexes with the same tile data and modify the ram tiles step by step. Only 24 unique tiles per level so it works out easy for this game. Egypt may even get a little heat wave mirage effect if I can figure that out correctly. I could cut the character graphics needed down by a lot by replacing colors after a sprite blit lots of possibilities, most pretty slow but possible for this game.

Ahh, ok - I like how you've done that with the ram tiles. There's certainly a ton of possibilities in that. When you have to start dealing with sprite priority over those ram tiles, I find it gets a little messy; but that shouldn't be an issue for you. I think we'll see some new video modes coming out with the '1284 and I bet some will make the process much more flexible.

As for the move, I was thinking more along the lines of a series of start/end point pairs. Each end point would be the start point of the next move, so moves would cost 6 bits, but you'd have fewer of them. With 4 bits for distance you would have to cap moves at 16 tiles, but I don't think that's too bad of a constraint (you'd just split larger moves into pieces). The distance bits could be specified in a level header that would be optimized for each level (ie 2 distance bits for smaller levels). It'd really depend on the maps as to which one was cheaper.

[D3thAdd3r]

Yeah for this game I can't think of a need to put a sprite over a ram tile. I totally agree on the new chip, there's a lot of new options that would really be handy with all that extra ram coming. That's a lot of space to decompress stuff into. I would think Mode 8 could become very useful. If we could split that ram into 2 frame buffers, all of a sudden you go from racing vblank to avoid tearing, to having all the time in the world.

An interesting idea for the moves you have, 16 moves can't happen anyways in the current implementation with no scrolling so that wouldn't be a problem. I know it would pay off on some solutions, probably worth implementing. It would only require a bit smarter tool.

[uze6666]

@ Uze
Please Alec, do not put your career at risk Thanks for the all the positive reinforcement! Geez, why didn't I think of a picture in a topic about my game ?... haha. Any ideas for a title screen/intro? Just seems boring sitting there flashing "WORLD". Seems you cannot modify 30 ramtiles in 1 vsync

I played a couple levels and I didn't encounter any bugs (so far ). As Paul mentioned, some of the FXs would need to be tweaked. For the title screen, was the original game using those Super Mario World fonts??? If so, I'd use something else as they look rather awkward for this game. I like the level solutions, if you end up with not enough space, no big deal you could just have another "level pack" HEX as Paul proposed, "Sokoban World 2-- The Advanced Levels" or whatever?

For the ramtiles, yeah I know the current blitter is not fast enough for >30 ramtiles. More than that and everything crashes. That said, there's a couple ways to recover some cycles. Since you game does not need the full screen vertically, you could reduce the number of rendered tiles lines/video lines with something like -DSCREEN_TILES_V=26 and -DFIRST_RENDER_LINE=28. You'd recover about (1495*16)=24K cycles. Could also turn off some sound channels. There's some optimization I wanted to do for some time now is the sync code. That could allow us to recover ~5 scanlines worth of cycles.

What do you mean by "I can't think of a need to put a sprite over a ram tile"? Didn't you use sprites? Also, I guess you tweaked the kernel to be able to edit ramtiles directly?

-Uze