Jump to content

Photo

Entry 2018: MazezaM

intellivision intybasic MazezaM

14 replies to this topic

#1 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • 6 posts

Posted Tue Apr 3, 2018 10:29 AM

Hey, first-time AtariAge poster here.  I came across this contest over the weekend and decided to give IntyBASIC a try.  I found it to be well documented and also very easy to use, and I was surprised at how quickly that games can be prototyped with it.  (In contrast, I have previously tried my hand at writing NES games, and found it to be much more difficult to get set up.)  So thank you to the creators of IntyBASIC and this contest for getting me started on something that I had been wanting to try for quite some time!   This is also my first time looking into the Intellivision and find the system to be quite fun to work with.

 

For my first program prototype I chose to port the puzzle game MazezaM which was invented by Malcolm Tyrrell.  The game is similar to Sokoban in the sense that you push boxes and cannot pull them.  However, there are several differences:

  • The goal is to escape the maze (as opposed to putting the boxes in particular locations).
  • The boxes cannot be moved vertically.
  • Horizontal pushes causes all boxes in that row to move simultaneously

Malcolm first implemented the game for the ZX Spectrum in 2002 and released it under the GPL.  Since then it has been ported to over 30 platforms by various programmers.  This includes commercial releases on the ColecoVision and SNES (and on Android under the name 'Rote'), but as far as I can tell it has never appeared on the Intellivision.  The following link includes an overview of the previous releases, and a link to a version of the game that you can play online in HTML5 using the PuzzleScript game engine: https://sites.google...zezam-home-page

 

This first draft includes the 30 levels that shipped with Malcolm's 2010 release of the game.  Overall, these puzzles are very challenging, and don't be surprised if you get stuck on one of the early levels for 10 minutes or more.  You can restart a level by pressing any button (at least that is what the implementation is supposed to do).

 

I have attached the .rom file and also a .zip file containing the source code (which is quite rough at this point).

 

As mentioned above this has just been a weekend project thus far, so there are many ways in which I'd like to improve the game before the contest ends.  However, I'd also like to hear your thoughts.

 

Thank you for reading this somewhat long post and please enjoy!

 

 

 

 

Attached Thumbnails

  • Level_01_First_Principles.png
  • Level_01_Finished.png
  • Level_30_The_Beast.png

Attached Files



#2 nanochess OFFLINE  

nanochess

    Processorus Polyglotus

  • 5,477 posts
  • Coding something good
  • Location:Mexico City

Posted Tue Apr 3, 2018 10:59 AM

For being your first game is pretty impressive and slick :) well done! :thumbsup:

From a first glance I've the following suggestions:

* Center level in screen.
* Add a level indicator (it could be before the level with level title like in the HTML5 puzzle you linked)
* Add a title screen.
* You could animate the arms to look like pushing.
* Add a background music or music when having success.
* Maybe a sound effect for walking with option to turn it on/off.
* A count of steps
* Draw bitmaps for blocks and walls.
* Maybe a 16x16 tiled background like a curtain behind small levels.

#3 emerson OFFLINE  

emerson

    Chopper Commander

  • 105 posts
  • Location:Northeast Ohio

Posted Tue Apr 3, 2018 11:36 AM

Man this is fun! Here are a few ideas I had while playing your game:

 

- A count up timer. It doesn't have to be real time, but something that lets the player keep track of personal bests. Good for speedrun competitions too!

- Limited restarts. Since the game is pretty hard, you could set the value high. This combined with the timer would add some extra difficulty.

- Easy/Hard mode, Practice/Tournament mode, something to that effect.

- Background story. Are you playing hide and seek with your friend in a warehouse? Did your pet get lost on a mountain? This could help set a theme for your gameplay (and border graphics assuming you center your game).

- Cutscenes. Maybe a little animation or story development every few levels. This would split up the gameplay so things don't get too monotonous.

 

Every once in a while it looked like the player movement lagged behind block movement for a frame or two, so that's something you might look into. I'm excited to see your progress!



#4 Steve Jones OFFLINE  

Steve Jones

    Dragonstomper

  • 827 posts
  • Location:Toronto Canada

Posted Sat Apr 28, 2018 1:50 PM

I agree with the above comments, the game mechanics work well, now it's all about polishing and adding options and dressing it up a bit now, storyline/fancy up bg gfx, sound effects etc.

look forward to seeing your next revision.



#5 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Mon Jun 11, 2018 3:44 AM

Any update on this game?



#6 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • Topic Starter
  • 6 posts

Posted Mon Jun 18, 2018 4:06 PM

Thank you all for your feedback.  I am in agreement with almost all of the suggestions that were made, and I will do my best to implement them.  One exception is the addition of a timer or 'lives'.  Some implementations of MazezaM do include these types of constraints, but I find these puzzles to be hard enough on their own.  One implementation with 'lives' is available on Rockbox, which is an alternate operating system for mp3 players that some of you may enjoy checking out.

 

In response to DZ-Jay: Yes, there is an update!  Version 3 is now ready.   The main additions are the following:

  • Level selection screen (using color squares mode ;-)  :-D ).
  • Levels are now centered on screen.
  • There are sprites for walking and pushing.
  • There is a basic storyline involving the character HannaH.

An image of the level selection menu is attached.  This version of the game allows you to select any of the 30 levels from that menu.  However, that feature will eventually be removed, and you will need to clear levels in order to unlock future ones.  

 

In the next version I'm hoping to add undo, the ability to save your progress, the minimum number of moves per level, and better navigation between the various menus.  I'll also add as much in the way of graphics, sound, and story as I can. 

 

This version of the game also has a main menu stub for a new 'quest' with new levels, but I haven't designed any yet, so that may not come to fruition.  I will mention that it is fairly easy to add new levels to the game, so if anyone feels like trying out their level design skills, then I can post a version of the game with those levels included.

 

Thank you again for your feedback and keep it coming!

 

PS  In case you are wondering about the version numbering, I didn't post Version 2 of the game since it was mostly a code rewrite without any external features.

Attached Thumbnails

  • LevelSelectScreen.png

Attached Files



#7 PuzZLeR OFFLINE  

PuzZLeR

    Chopper Commander

  • 148 posts
  • WiLd CaRd
  • Location:Toronto Canada

Posted Tue Jul 10, 2018 1:41 PM

I like this! A good puzzle game can really score high on the addictiveness meter. :)



#8 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Wed Jul 11, 2018 5:25 AM

Hi, postpostdoc,

 

I have just given this game a whirl and I have to admit that it is quite nice!  I will be honest, at first glance at the screenshots above, I thought it was an excessively simple game with really blocky graphics, more of a prototype than a real game.  However, those blocky graphics mask a depth of gameplay which is surprisingly interesting.  So, kudos for the great implementation of an even greater concept. :thumbsup:

 

I really like this game, it is very challenging and intriguing.  In particular, I like the idea of the character HannaH attempting to become the Madam Of Mazezam.  As others may know, I believe that character- and story-driven games lend themselves to a tighter grip on the player's imagination, and by extension, to their attention.

 

So here's a bit of feedback from my perspective on how to improve your game.  I'll keep these to the most critical, since there is a bit over two weeks left for the contest.  Remember that even if you do not complete any of these for the contest, you can always continue polishing the game afterwards.

  • I do not think you need "undo" mechanics.  Retry should be sufficient and avoids trivializing the player's move:  every move must be carefully considered to avoid getting stuck and having to restart the level.
  • I agree that you do not need lives or a timer.  The game is actually quite challenging as is.  (I got stuck on level 5 for a while before I was able to pass it.)
  • Needs a deeper story.  You do not need to write an essay, the few words you put on the screen already do a great job at constructing a world in the player's imagination:  there's the Mazezam, there's our hero Hannah, there's some sort of challenge to the labyrinths that our hero is trying to overcome in order to achieve the ultimate title.  What I think is missing is a bit of motivation.  Is she stuck inside the Mazezam?  Is it something others have tried but failed?  Is there a prize at the end of the labyrinths?  Does her life depend on it?  Is she doing it just for bragging rights?  Perhaps one more line in your brief story could give even more depth.
  • Needs more sound effects.  The Mazezam is a fascinating world but, damn, is it quiet in there.  Something as simple as a tinny "blip" whenever HannaH moves would do.  Always remember to keep your sounds -- especially those repetitive ones -- pleasant, musical, and harmonious (proper notes on the same key, if possible) to avoid annoying the player.
  • Needs more animations.  The character HannaH looks great, but her jerky motion could be smoothed over by a few more frames of animation whenever she moves in any direction.
  • Needs more detail.  I get it that it's a simple maze with huge cubes that move around, but nothing says they have to be completely bland 8x8 color blocks.  You could add some texture by judiciously drawing your 8x8 blocks.  There are 64 card slots in the GRAM for you to get creative with. ;)  Different mazes could have different themes by employing various sets of tiles: bricks, rocks, bubbles, etc.
  • Needs more moving objects.  The Intellivision hardware gives you 8 MOBs and it looks like you're using at most 4 on HannaH.  The extra ones could be used as "accents" whenever she moves a block, or for additional detail in the motion of the blocks.
  • Needs a HUD.  Even if you jazz up the MazezaM with some textures and additional details, it is still just a tiny portion of the screen.  Of course, all that empty space serves to focus the player's attention on the really important thing: the maze itself; but there's enough space to add a bit of state information to guide the player in his journey.  You could add a simple "status bar" or some fancy presentation for it, since there's plenty of space.  Among the important information you could provide is:
    • Current level vs. maximum to give the player a sense of his progress
    • Retry counter
    • Actual moves vs. par
    • Time spent in the MazezaM
    • Score (if there is such a thing in the MazezaM world)
  • Along with some sort of HUD, perhaps you could spruce up the screen by putting up some textured tiles instead of a sea of black.  Give the screen a bit more visual polish and interest.
  • Needs a fancier title screen.  The current title screen is perfectly serviceable, of course.  However, with 64 custom cards available and 8 hardware sprites, why not go the extra mile and build a nice attractive face for the game?  You could use the IntyColor companion application to transform bitmaps into IntyBASIC screen data structures.

 

Some of the above may seem trivial, and most of it is; but do not underestimate the impact visual presentation has on players.  You've nailed the game-play and the challenge difficulty -- now it's time to get fancy with a bit of spit-n'-polish. :)

 

Great job, and a great addition to the Intellivision canon! :thumbsup:

 

    -dZ.



#9 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • Topic Starter
  • 6 posts

Posted Wed Aug 1, 2018 4:46 AM

Thank you DZ-Jay for the thorough and thoughtful evaluation! 

 

I agree that MazezaM is a deeper and more difficult game than it initially looks.  But you are also correct that appearances can be very important in a game.  So in this update I have improved the graphics in several ways. 

  • There are now tiles for the boxes that you push, and a stone brick pattern surrounding the levels.  The tiles use different background colors, so this addition was a nice way for me to wrap my head around the color stack, so it was worth it just for that education.
  • As you suggested I used IntyColor (thanks @nanochess!) to spruce up the title screen.  I positioned the letters carefully to promote tile reuse, so it is currently only using 39 / 64 bitmaps, so there is more room for improvement there as well.

HannaH also has some new animations for running into each level, as well as a small celebration animation when she finishes a level.  Those things seem to give the game some more personality, so thank you for that suggestion.  On the other hand, I don't plan to further address the "jerky motion" that you mentioned.  When HannaH is inside of an individual level, it is important that she has discrete card-by-card movements.  Why?  There are two different reasons.  

  1. Notice that if HannaH moves partway through a card, then the boxes in the row that she is pushing will also need to move partway through a card.  Since entire rows move at the same time, it probably isn't possible to do this type of movement with the limited number of sprites (e.g. HannaH uses four MOBs and the remaining four MOBs can't create a box pattern that spans the width of the screen.)  The effect could be accomplished with some additional programming by creating shifted versions of the background cards.
  2. The more important reason is that this change could actually make the game play much worse.  The puzzles are played on a card-by-card grid and if gets confusing if the animations make it look like the rows can be pushed in smaller increments.  In other words, the player can see the rows being moved outside of the grid, but they can't actually get the rows to stop there.  For an illustration of this issue, take a look at the ColecoVision port of the game (here is a clip from Gamester81's video on it https://youtu.be/ofKYW2mAYD0?t=3m30s).  Overall, it is a really beautiful port by alekmaul and they managed to make it look just as good as their SNES port (which won a retro coding contest back in 2012).  But for me, the game play is ruined due to the additional animation.

So there are good reasons for the "jerky motion" and hopefully they are explained well enough above.

 

I also appreciated your comments about adding a deeper story.  I have a great idea for a small but significant addition to the classic MazezaM formula that would really play well into a more detailed story.  A lot of the code rewriting I have been doing is in preparation for this upgrade (called "MazezaM SOS").  I hope to be able to get it working before the new deadline. 

 

I had also intended to add some sound effects and a HUD to this version, but ran into a couple of big development issues, which I'll mention in a separate post.

Attached Thumbnails

  • TitleScreen.png
  • ToAndFro.png

Attached Files



#10 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • Topic Starter
  • 6 posts

Posted Wed Aug 1, 2018 5:30 AM

The biggest bug that I created for myself on this project was related to the size of the .rom.  I didn't realize that I was pushing up against the size limit (of the first segment) and at various points in development the game wouldn't load into the jzintv emulator.  I say "load" now, but at the time I thought that the .rom was "crashing" the emulator, so I was looking in all the wrong places for the bug.  I spent many hours adding and removing and rewriting and moving code around, but I was always thinking about what the code was doing, rather than how big the code was. 

 

I have definitely learned my lesson now, and in retrospect I should have paid more attention to the discussion of "asm org" in the contest rules.  But I also think that other developers could run into this issue without realizing what their problem is.  Would it be possible for future versions of IntyBASIC to issue a "size warning" to the programmer when the .rom won't work due to segment size issues?



#11 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Wed Aug 1, 2018 5:30 AM

Hi, postpostdoc,

 

I haven't had a chance to play the new version yet but I wanted to say that those screenshots look great.  I also wanted to address your comments on the "jerky motion," and explain better what I meant.

 

I understand about keeping HannaH and the blocks in a discrete grid.  However, what I meant was two things:  First, to give HannaH a bit more flair by employing several animation frames to transition her from looking forward to looking sideways, rather than just switch orientations abruptly.  This animation should not take more than a fraction of a second.

 

Second, you could smooth the movements of HannaH by adding a short (three or four frames) walking animation and have her sprite slide over onto her target position on the grid.  This merely provides a transition between her current position and her destination.  Moreover, as with the orientation animation above, this should not take more than a fraction of a second and should not give any impression of free-movement to the player.

 

This is a technique used in any number of games from the past, where movements were constrained to grids precisely for the reasons you mentioned.  Even if you do not add an animation and just smoothly move the sprite over, one card-length at a time, it would still be an improvement from just the skip it does right now.

 

Just to be clear, I am not advocating continuous smooth movement over the background, but discrete motion across the length of a card. That is, if the player wants to continue moving across, the sprite still moves only eight pixels and stops before continuing.  It is up to you if you wish to force the player to release the control and press again to continue, or if you wish to accept a continued press.

 

Either way, the ultimate effect is that the sprite moves essentially in discrete 8-pixel steps, except that there is a smooth transition between them.  Consider as an example Boulder Dash, which does precisely this.

 


In contrast, the ColecoVision version of MazezaM you referenced does not do this well (as you suggested):  The animation and the movements are too slow, enough to give the impression of free-movement rather than discrete steps.  I agree that it is a bad implementation, or at least a particular visual style which may not fit this type of games that well.  The trick is to find the proper balance.
 

For another example take a look at the yellow bar that highlights the menu selection in this video:

Attached File  Menu Test.mov   1.88MB   109 downloads

 

Notice how it seems to "jump" from selection to selection?  I actually experimented with various speeds to get what I felt was the most natural look.  It turns out that there is a very slight but perceivable difference between moving the bar completely from one line to the next in one step, and smoothly getting it there over a few frames.  I couldn't even tell you what it was, only that it "felt" different, and it "seemed" better.

 

In the end, the final version you see in the video completes the transition in about three steps (you can see it in action if you step through it one frame at a time).

 

My personal opinion (and I know I am very opinionated :grin:) is that it is those little tiny touches that push the quality of a game to greatness.  It may seem inconsequential, and the differences may seem invisible on the surface, but they are actually quite perceivable even if at a very subtle level.   :)

 

    -dZ.


Edited by DZ-Jay, Wed Aug 1, 2018 7:11 AM.


#12 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • Topic Starter
  • 6 posts

Posted Wed Aug 1, 2018 5:38 AM

Thank you for explaining in more detail.  Yes, I can see how the yellow bar has a nice balance between discrete steps and quick continuous motion between them.  The Boulder Dash run cycle is also quite nuanced despite staying within the grid boundaries.  Thank you for those examples and I'll see what I can do for the next update!



#13 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Wed Aug 1, 2018 6:10 AM

Thank you for explaining in more detail.  Yes, I can see how the yellow bar has a nice balance between discrete steps and quick continuous motion between them.  The Boulder Dash run cycle is also quite nuanced despite staying within the grid boundaries.  Thank you for those examples and I'll see what I can do for the next update!

 

No worries.  In any case, it is your game and it should follow your vision.  I just wanted it to be clear that there shouldn't be any technical constraints to implementation, and that we are all here to help if you need assistance.

 

I'm looking forward to playing the newer version later today. :thumbsup:

 

   -dZ.



#14 postpostdoc OFFLINE  

postpostdoc

    Combat Commando

  • Topic Starter
  • 6 posts

Posted Wed Aug 1, 2018 8:23 AM

Just a quick note that the game play will be pretty similar to the previous version.  So if you are constrained for time, then feel free to save some for the next version.  Thanks again!



#15 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 11,066 posts
  • The P-Machinery AGE is almost here!
  • Location:NC, USA

Posted Sun Aug 5, 2018 10:49 AM

Thank you DZ-Jay for the thorough and thoughtful evaluation! 

 

I agree that MazezaM is a deeper and more difficult game than it initially looks.  But you are also correct that appearances can be very important in a game.  So in this update I have improved the graphics in several ways. 

  • There are now tiles for the boxes that you push, and a stone brick pattern surrounding the levels.  The tiles use different background colors, so this addition was a nice way for me to wrap my head around the color stack, so it was worth it just for that education.
  • As you suggested I used IntyColor (thanks @nanochess!) to spruce up the title screen.  I positioned the letters carefully to promote tile reuse, so it is currently only using 39 / 64 bitmaps, so there is more room for improvement there as well.

HannaH also has some new animations for running into each level, as well as a small celebration animation when she finishes a level.  Those things seem to give the game some more personality, so thank you for that suggestion.  On the other hand, I don't plan to further address the "jerky motion" that you mentioned.  When HannaH is inside of an individual level, it is important that she has discrete card-by-card movements.  Why?  There are two different reasons.  

  1. Notice that if HannaH moves partway through a card, then the boxes in the row that she is pushing will also need to move partway through a card.  Since entire rows move at the same time, it probably isn't possible to do this type of movement with the limited number of sprites (e.g. HannaH uses four MOBs and the remaining four MOBs can't create a box pattern that spans the width of the screen.)  The effect could be accomplished with some additional programming by creating shifted versions of the background cards.
  2. The more important reason is that this change could actually make the game play much worse.  The puzzles are played on a card-by-card grid and if gets confusing if the animations make it look like the rows can be pushed in smaller increments.  In other words, the player can see the rows being moved outside of the grid, but they can't actually get the rows to stop there.  For an illustration of this issue, take a look at the ColecoVision port of the game (here is a clip from Gamester81's video on it https://youtu.be/ofKYW2mAYD0?t=3m30s).  Overall, it is a really beautiful port by alekmaul and they managed to make it look just as good as their SNES port (which won a retro coding contest back in 2012).  But for me, the game play is ruined due to the additional animation.

So there are good reasons for the "jerky motion" and hopefully they are explained well enough above.

 

I also appreciated your comments about adding a deeper story.  I have a great idea for a small but significant addition to the classic MazezaM formula that would really play well into a more detailed story.  A lot of the code rewriting I have been doing is in preparation for this upgrade (called "MazezaM SOS").  I hope to be able to get it working before the new deadline. 

 

I had also intended to add some sound effects and a HUD to this version, but ran into a couple of big development issues, which I'll mention in a separate post.

 

I played the new version and the game is still an immense amount of fun!  This time I made it to level #10 and got stuck there.  (Wow! Some of those levels are quite challenging! :o)

 

Here's some feedback on your latest changes:

  • The title screen is very nice, certainly an improvement from the previous one.  Maybe in the future you could add some additional pizzazz with some animations, perhaps some colour cycling on the letters, or whatever.  However, this is just presentation stuff that is not really important right now; I'm just a big sucker for cool "attract" screens. :)
  • The walking sequence of HannaH looks much better than before but could use more than two frames. (I'm also a sucker for smooth and fancy sprite animations. :))
  • I love the little victory dance HannaH does when completing a level.  That adds a great deal of charm to the character. :thumbsup:
  • The brick pattern on the levels is a great improvement, but I wonder if it would work better by circumscribing it to a smaller area.  I mean, Leaving some space at the top for the level title (perhaps etched in the brick, since you obviously have plenty of GRAM cards left to play with), and some at the bottom for a HUD.  I like that there are tunnels on each size marking the entrance & exit; it makes it look like HannaH is traversing through a larger underground complex.  (Simple yet clever "world building" like that is, in my opinion, what gives these games great depth.  Kudos for that seemingly trivial, yet effective cue.)
  • Also, employing different brick patterns as she goes deeper could add more visual variety and keep the game interesting as it advances.
  • I suppose that score/penalties/retries would become apparent once you implement the HUD, but just in case it's not there, I think you should track:
    • Number of moves (and how many are left, if there's a limit)
    • Time spent in level 
    • Number of retries (and how many are left, if there's a limit)
    • Level number and how many are left in the entire MazezaM complex.

That's it for now.  Great job so far! :thumbsup:

 

 

 

I have definitely learned my lesson now, and in retrospect I should have paid more attention to the discussion of "asm org" in the contest rules.  But I also think that other developers could run into this issue without realizing what their problem is.  Would it be possible for future versions of IntyBASIC to issue a "size warning" to the programmer when the .rom won't work due to segment size issues?

 

This has been discussed many times before and it's not a trivial problem.  I believe nanochess (the creator and developer of IntyBASIC) is working on a future feature for it, but I do not know if it will be ready any time soon.

 

The problem is that the IntyBASIC compiler has no knowledge of the size of the program since all it does is transform the IntyBASIC source into Assembly Language and hand it off to the as1600 assembler.  It is possible for IntyBASIC to do this, but it would have to keep track of the size of each instruction and data structure as it generates its Assembly code, which has been at least heretofore the job of the assembler.

 

At that point, it may as well assemble the source itself and generate object-code instead.  This may be the ultimate ideal solution, but it is miles away from what IntyBASIC does today.

 

By the way, you mentioned you had some problems or questions related to the Color Stack.  Maybe we can help with that?

 

   -dZ.







Also tagged with one or more of these keywords: intellivision, intybasic, MazezaM

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users