Jump to content

Photo

Entry 2018: MazezaM

intellivision intybasic MazezaM

32 replies to this topic

#1 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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,573 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

  • 110 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

  • 895 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,269 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

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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

  • 161 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,269 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

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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,269 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   117 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

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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,269 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

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

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,269 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.



#16 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Tue Aug 28, 2018 8:40 AM

I have been working pretty consistently on the game for the past week and have two big updates.

  1. The level unlocking and achievements are now implemented.  The player earns 0, 1, 2, or 3 stars on each level depending on how many moves they make.  Move counters have been added to the heads-up display. 
  2. A password system that saves your achievements is now implemented.

You can also press one of the top buttons (i.e. B0) during any level to bring up a "pause" screen.  This screen will give you information on the achievement requirements for the given level, and your current password for all of your achievements.  You current password can also be found in the new Password option off of the main menu.

 

To navigate through the various screens you can generally use the bottom-right button (i.e. B2) to move forward and the bottom-left button (i.e. B1) to move backwards on either controller.  On my installation of jzintv this means Ctrl to move forward and Alt to move backward with Shift to access the pause menu.  And you can use the keypad for entering the passwords, where the B0 button toggles between numbers 0-9 and letters A-J.

 

I have a couple of other big ideas that I'd love to implement.  Most notably I've done some planning for an "SOS" mode where you rescue another playable character.  However, due to the time constraints, I'll probably switch into polishing mode now (e.g. sound, nicer graphics on the various screens, more consistent controls, etc).  And more importantly I need to catch up on playing the other entries!

 

Attached Thumbnails

  • LevelSelectStars.png
  • Pause.png
  • Password.png

Attached Files



#17 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

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

Posted Wed Aug 29, 2018 3:32 AM

Hi, postpostdoc,

 

It's getting better and better!  Below is some feedback after a quick play session:

  • It seems you removed the one-page story introducing the character. :(
  • I like the "Level Select" menu screen with the stars and the locked levels, but I can't seem to find a way to return to that screen.
  • The "Pause" screen seems to take its place, but it seems oddly disconnected in that it only gives you the "par" information for the current screen, not your progress.
  • There should be a way to see the stars earned for each level completed -- perhaps a way to return to the "Level Select" menu.
  • It took me a while to figure out what the numbers in the HUD were, and that one of them reset multiple times, and then started counting up at some point.  I know now what they mean, but perhaps there's a better way to convey what they are?  There's plenty of space around the maze, so there's no reason to be stingy with information. :)
  • May I suggest using different colours for the HUD text instead of just plain ol' black?  it just blends too much into the background.  The "heads-up display" should be easily noticed at a glance. ;)
  • I know it's a bit late and you're pressed for time, but... how about a short musical ditty for the title screen?  On a pinch, you could pick up one of the many songs tracked already and available around these parts.
  • If I try to select a "locked" level from the "Level Select" screen, it should buzz me with a raspberry or some other "you can't do that!" sound effect. :grin:

Other than that, it's still a very solid and interesting puzzle game and it is getting better and better.  Still has some ways to go in terms of polish, just a little bit; the main elements are there, they just need a bit of cohesion to elevate the experience.

 

You got two more days... make it happen! :grin: :thumbsup: :thumbsup:

 

    -dZ.



#18 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Wed Aug 29, 2018 6:13 AM

re: controls.  When you are playing a level you can reset your progress with the bottom-left button (i.e. B1).  Then if you press the same bottom-left button again (i.e. B1 again) then you are returned back to the Level Select screen that you mentioned.  I should have explained that in my previous post, so thank you for mentioning the issue! 



#19 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Wed Aug 29, 2018 6:33 AM

re: HUD.  I agree that the count-down counter is not the most intuitive, but I do like the general idea of showing the number of moves remaining for each accomplishment.  The HUD could be easier to parse if I remove the stone pattern from the top row, so I may end up doing that.

 

Although it looks like there is a lot of empty space on the screen, this actually isn't true on the later levels. 

  • Some of the later levels are quite tall.  For example, Level 17 has 11 rows.  If you add the bottom and top rows of the wall, then that puts you at 13 rows which is one too many since my graphics are all card-based (except on the Level Select screen which uses color squares mode).  On Level 17 I don't display the bottom wall, and the top wall is covered by the HUD.
  • Some of the later levels are quite wide.  The maximum width is 16 columns.  If you add the left and right walls, then that puts you at 18 columns which only leaves two blank ones.


#20 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Wed Aug 29, 2018 6:35 AM

re: sound.  Yes, I definitely intend to add some sound.

 

re: story.  Stay-tuned!   ;)

 

Thank you for your continued feedback!



#21 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

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

Posted Wed Aug 29, 2018 6:47 AM

re: controls.  When you are playing a level you can reset your progress with the bottom-left button (i.e. B1).  Then if you press the same bottom-left button again (i.e. B1 again) then you are returned back to the Level Select screen that you mentioned.  I should have explained that in my previous post, so thank you for mentioning the issue!

 
Ah!  I didn't really noticed that pressing it twice would return.  Sounds good, but I wonder if you should also offer a Key Pad entry.  You could have certain buttons on the Key Pad represent "Reset," "Return To Menu," and "Pause."
 
That's typically the "Intellivision Way" (even if you don't create an overlay), while the action buttons are usually intended for, well, "actions." :)
 
 

re: HUD.  I agree that the count-down counter is not the most intuitive, but I do like the general idea of showing the number of moves remaining for each accomplishment.  The HUD could be easier to parse if I remove the stone pattern from the top row, so I may end up doing that.

 
That may help.  I do like the count-down.  Once I figured it out I went, "aaaaah!" and from then on it was very natural.  Perhaps it'll help if you added an icon next to it representing the one, two, and three stars par; and change it as the player moves from one to the next.
 
 

Although it looks like there is a lot of empty space on the screen, this actually isn't true on the later levels.

  • Some of the later levels are quite tall.  For example, Level 17 has 11 rows.  If you add the bottom and top rows of the wall, then that puts you at 13 rows which is one too many since my graphics are all card-based (except on the Level Select screen which uses color squares mode).  On Level 17 I don't display the bottom wall, and the top wall is covered by the HUD.
  • Some of the later levels are quite wide.  The maximum width is 16 columns.  If you add the left and right walls, then that puts you at 18 columns which only leaves two blank ones.

 
Point taken.  I haven't made it to the later levels yet.
 
Still, you are not hard-pressed for carving out space for your HUD and status information.  For instance, two columns at either side is more than most games reserve. ;)
 
Now, don't get me wrong, I am not saying you need to carve out the space; just that it's there if you want it.  Also, don't be afraid of offsetting the mazes flushed to one side and leaving 4 columns on the other for status.  The (screen) world is your oyster.

 

re: sound.  Yes, I definitely intend to add some sound.
 
re: story.  Stay-tuned!   ;)
 
Thank you for your continued feedback!

 

It's truly my pleasure.  I'm excited to see what else comes! :thumbsup: :thumbsup:

 

    -dZ.
 


Edited by DZ-Jay, Wed Aug 29, 2018 6:49 AM.


#22 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Fri Aug 31, 2018 4:22 PM

Before the deadline I was able to add a twist that I had been planning for a little while. 

 

In a "MazezaM SOS" level the player must rescue another player who is trapped inside of maze.  Then the player must bring themselves and the rescued party to the exit.  In these levels you control the trapped player using the keypad, so it takes advantage of the Intellivision controller.  In total I added 5 SOS levels to go along with the original set of 30 Classic levels.

 

The motivation for SOS levels came from everyone's comments on developing a story.  I tried to think of a theme that could fit an abstract puzzle like MazezaM, and search and rescue seemed appropriate.  The fact that "SOS" is a palindrome was an added bonus  ;)

 

To go along with the SOS theme I added a more complete story to the game.  Every 6 levels you will confront an SOS level and more of the story will be revealed.  I'm not particularly pleased by the presentation of the story, but I ran out of time.  

 

Speaking of time, there were still a number of things that I wished I was able to do before the deadline (e.g. sound!), but I'm sure that is true for all of the other contestants too.

 

Thank you for a great contest!  

 

PS  The source code for my submission can be found at https://src-code.sim...ams/MazezaM_SOS (click on Releases and then Version 0.9 for the version submitted via email).

Attached Thumbnails

  • MazezaM_SOS.png
  • Aja.png
  • Otto.png

Attached Files



#23 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Tue Sep 4, 2018 9:47 AM

Here is a slightly squished version of the MazezaM.rom file down to 34kb from 42kb.  This is related to a post about .rom size I just made on the IntyBASIC compiler v1.2.9: The good things are now better! thread.  I also took the opportunity to fix a few small bugs and make a few small improvements.

 

Attached Files



#24 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Tue Sep 4, 2018 2:40 PM

You can also find the update under V0.10 in the Releases tab of the corresponding git repository https://src-code.sim...ams/MazezaM_SOS.



#25 postpostdoc OFFLINE  

postpostdoc

    Space Invader

  • Topic Starter
  • 21 posts
  • @PRGE
  • Location:somewhere near the Canadian-USA border

Posted Wed Sep 5, 2018 11:03 AM

A manual is attached below as manual.txt.  If you visit the git repository then the manual will be rendered nicely as a markdown file.  A screen capture of the main controls is also given as an image below for convenience.  The latest rom is Version 1.1 and it has a few minor fixes.

 

The manual includes the basics that you would expect (e.g. story and controls) as well as some less likely material, including the history of MazezaM and its computational complexity.  At the risk of getting too nerdy (maybe not an issue on this subforum?!?) the puzzle is PSPACE-complete.  PSPACE is a complexity class of decision problems that are "solvable in a polynomial amount of space with respect to the size of the input" and PSPACE-complete means MazezaM is among the hardest problems in this complexity class.  In particular, it is likely to be harder than all puzzle games that are NP-complete, where NP means "solvable in polynomial-time using non-determinism".  Links to a couple of papers on the subject are included, and feel free to post here or send me a message if you have any questions about that.  In particular, this paper will help anyone stuck on the later SOS levels  :grin:

 

As some personal background, I teach courses in theoretical computer science at a small college, and MazezaM is a puzzle that I had previously studied before implementing it for this contest.  I should also mention that I haven't finished at least 10 of the puzzles in this game, so kudos if you do!

 

And my apologies for not including a manual earlier -- the game is already hard enough!   ;)

Attached Thumbnails

  • controls.png

Attached Files


Edited by postpostdoc, Wed Sep 5, 2018 11:17 AM.






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