About Monsta, if you throw up exactly the same maze and tokens on all four screens, then you could let multiple players race to get the goal first. *Edit* What I mean is, the players would be playing separately, but all starting with the same situation. Obviously, that would require tracking four separate game states, but it should be doable within memory, though maybe to save memory you'd want to use bits instead of bytes to store the maze, if you're not doing so already. Using bytes is easier and more flexible, assuming there's memory, which there probably is, as I think it'd only take a couple KB (38x13x4=1976 bytes).
Interesting that you should suggest that. I was planning on doing exactly that tonight. The winner would be the player who completed the maze first.
FYI, the game state is in a structure. There aren't any global variables. That makes it very easy to have four game states. There is essentially nothing to be done, just have four instances of the state structure. The only thing that will require a tiny amount of work is having all of the game states share the same maze but even that should be 10 minutes work at most.
Yeah, it's a natural, isn't it. I mean, you don't have to do anything super complex to take advantage of the four screens, just have players compete "pinewood derby" style, all things being as equal as possible.
Now, for fun, you could possibly let each of the four players see each other's tokens, plotted in differing colors (with each player on top for his or her screen if occupying the same space, to keep it simple). Of course, that might be even more effective if you started competition with the walls visible. Then either all four players would start from the same tile, or you could randomly position them because, well, life isn't fair and some people are born with a silver spoon in their mouths and others are not.
If you used a purple background, you could use red, green, blue and yellow for the players' tokens. But a blue background is nice, so maybe you could go with red, green, yellow and purple. Or you could swap either yellow or green for white, if the contrast between them is not enough. That can be a bit of a problem for people like me who have one of the two or three kinds of red-green color deficiency, particular for small characters (as opposed to large areas). But given one is using the cursor keys to navigate, it probably would be okay.
Anyway, keeping everything separate would be just fine, and sometimes it's best to keep things simple. But maybe the screens of those that got the target could then show the locations of the other players, so that they wouldn't get bored. And scoring could be based on time, right? A game could consist of 10 rounds, for example, with the times being cumulative. *Edit* Well, there's probably no need to limit the number of rounds (unless the score indicators were going to wrap around/overflow).
That makes it very easy to have four game states. There is essentially nothing to be done, just have four instances of the state structure. The only thing that will require a tiny amount of work is having all of the game states share the same maze but even that should be 10 minutes work at most.
Sounds great. But don't worry: I'll come up with some enhancements to make it difficult. Just kidding (I think).
By the way, once active development stops on Monsta, perhaps you or I could post a screen shot here. And maybe you (or I, but better if it's the creator) could make a short YouTube video of it in action (even a video showing just one screen) for linking to from WordFire (or just here or both). It'd be the first "third party" game created for the console. You could be the next Activision (back in the day). Okay, I'd better stop interrupting your work there and move on to other things on this side of the world myself.
Ah, right you are! Open mouth, insert foot! When I hurriedly typed that, I recalled that Mike had done some work on a Pac-Man style game but hadn't published yet, and the Lunar Lander game escaped my mind at that moment. Mike banged Lunar Lander out in his first 24 hours of console ownership, which was quite amazing, as he had to come up to speed on the environment. I know he was considering some enhancements, too, but I read that he has been quite busy. At any rate, to Mike, I apologize for my oversight.
By the way, David, if a Pac-man style game gets released at some point, it will slightly overlap with Monsta, in that the former is somewhat maze-like. But Monsta is a different animal and will stand out on it's own, so Monsta will definitely add some variety. Based on the history you've provided about Monsta, namely its era, it seems likely that something like it was a precursor of Pac-Man. In fact, the other day when I played Monsta, I had the thought that there could be multiple monsters, similar to how there are four ghosts in Pac-Man. But in a multiple-monster Monsta, perhaps one could slay some of the monsters (with clubs, not by hitting them over the heads with "sleighs" as I originally spelled "slay").
Anyway, just as I posted a picture of Lunar Lander, it'd be good to post one of Monsta. Thanks to you both for your development efforts and support of the console.
OK, I had some spare time to work on my current 4-way editor.
The attached folder needs to be on the SD card, and - hmm - allows editing of any file, with some restrictions.
My basic plan was to build a screen editor for classical Character-Map based games. and I released a prior version. This one now allows to edit the filename and the width and height to expect when opening the file.
There are two modes the editor understand, one is a pure ascii file of width xxx and height xxx, or a screen file using the first half of the file as characters and the second half of the file as attributes, like the screen is organized by the video driver of the Quby/Wordfire.
All of this is quite rough, but it basically works.
All 4 user work on the same File and will see changes made by other users instantly.
I am kind of stressing the SD card by opening, writing or reading ONE byte and closing the file again. The most horrible construct, way open to optimization. Same goes for the cursor, it gets read from the file every time it gets moved on any screen.
I started to draw a Pac-Man Screen, and I have some idea to build a Game-Engine running Maps by (dis)allowing movements by Map-Content.
this is just a current copy, not really production level,
Here is the Monsta! game running on all four screens. However, each screen currently has a different maze. Also, there seems to be lag sometimes in responding to keys so I may need to do some optimization.
Hi, Mike. Great! I loaded it up in its own directory, EditMap3 and changed the name of the binary and edited the about file to match. I wasn't sure if this completely replaced EditMap1 at this point, though I would imagine so. Guess I was a little apprehensive about writing the card so often, so I chose to retain EditMap1 in its own directory. But I realize that you crafted a new version of the SD card driver that is based on Kye's latest work. Thanks for that and the continuing work!
Oh, by the way, when scrolling the instructions, if convenient (see below), I might stop scrolling once, for example, the last line of the instructions is at the top of the screen, but maybe there's no way currently for the program to know when it's at the end of the line. Also, I noticed that one can scroll the instructions sideways, replacing them with dots. Perhaps this horizontal scrolling and the way that the vertical scrolling works are due to the instruction screen using the same techniques as what the overall program uses. But I was too dense to conclude that with any confidence. Anyway, if that's the case and it makes the program easier or more elegant, or provides a nice example, then totally ignore the clueless guy in the peanut gallery (me).
Hi, David. I'll try to load this up later tonight after I get free. But I do have some comments that I wanted to pass on based on prior play. First and foremost, I like your game already and it looks like it'll get even better. Ignore my earlier comments about colors and seeing other players and so on. Keep it simple, at least for now.
I'm really looking forward to a four-player version where everyone wanders around in the same maze. I think the process of wandering through the maze--both with and without the walls exposed--is enjoyable. I would like to play (test) it with a friend or two if you release such a version.
I've noticed that one can often get the target/goal when only, say, a third of the maze walls are exposed. But the maze walls are an artistic part of the game, so they deserve to be mostly exposed. For that reason and also general playing dynamics, what I think I would do is deploy around five targets, but probably one at a time. When ANY player gets a target, "ring the bell" and then randomly deploy the next target. Then, rather than using elapsed time for scoring, it could just be a count of collected targets. So, this way, a game would consists of several rounds, wherein each round had one maze configuration but several targets. And even if players had exposed most of the walls before the final target or two were deployed, it's still fun to navigate the maze to collect them.
As for bombs and clubs, I'd consider dropping them. I think that they are a distraction. Even though this game is not designed as a smooth animation game like Pac-Man, it still plays like a video game and doesn't need smooth animation. Navigating the maze is its strength (though please consider moving just one space at a time).
But back to the bombs and clubs, they may not be needed. Yes, I realize that a player might get trapped by the monster, but so be it: let them lose one of the targets they've collected. And probably don't let them just jump over the monster. If they need a way out, make them do something unique like type "jump" to get away or whatever. But I think you can just let the chips fall where they may.
However, I think it would be cool to have time bombs that randomly appeared and momentarily blocked passageways. Players would need to navigate around them or wait them out, as they'd disappear (explode without damaging the walls) on their own after, say, five or ten seconds. If a player bumped into one, they could lose a collected target, if they had any to lose (I probably wouldn't go negative on the count).
As for the randomizers (the question marks), I love them! They can be good and bad for a player. On the one hand, they serve to make it more challenging to go in the desired direction by randomly transporting a player elsewhere (which could also be closer to the target), but on the other hand, a player may deliberately run into them to get a better position closer to a target or to get away from a/the monster. Anyway, I like how they are first invisible, but later visible, such that one can avoid them, if desired, and if one does run into a randomizer, then one has to suffer the consequences, for better or worse. So randomizers are a nice feature. By the way, I also like the "breadcrumbs" that show where a player has gone (the breadcrumbs should be a part of a player's game state, just like the exposed walls), helping one to know a safe path to avoid randomizers, as some randomizers might still be hidden. Good job!
As for the monster, while strictly not necessary, it's a cool feature. You might even consider allowing for multiple monsters on screen at the same time (and all the same for all four players, wherein I'm assuming that they players have the same maze, which I think would be best). I noticed that the monster is kind of dumb (most monsters are dumb but make up for it with their brawn, I guess). That is, the monster has no knowledge about the maze and can go through the walls. That's probably a good thing, as it allows a player to trick a monster into moving in a certain direction so that the player can go the way he or she needs to go. But multiple monsters might be difficult to manage. Perhaps there could be a total of four monsters, with each monster focusing on one player, but wherein the monsters could inadvertently attack the players that they weren't focused on. Again, rather than ending the game for a player that was "eaten" (attacked) by a monster, I'd probably just deduct one of that players accumulated targets. That's a pretty high penalty and would add to the strategy of the game, namely, avoid the monsters if you know what's good for you.
Well, I know I said to ignore my earlier comments, but as for being able to see other players, maybe something could be done there, after all. Maybe whichever player crashed into another player first (as determined by whichever keystroke came first), then that player could send the other player packing, i.e., randomly displace the other player. That'd be better than deducting a collected target, as that would be too severe of a penalty and change the game dynamics too much. Anyway, even if you did show the other players to all players, such as by using different letters or tokens or colors for them, each player's wall and breadcrumb state would be unique (though perhaps for the final target in a round you could reveal all the maze walls and kill the breadcrumbs, or not). Anyway, this last possibility could be considered after some of the other things were in place.
Well, of course, it's your game, so feel free to take or leave the above suggestions. But I am looking forward to playing a multi-player version of Monsta. And I also like playing it by myself, so that's a good sign. Good luck finding the time to work on it, though. Again, I'll load up your latest version tonight. Yeah, I could have done it in the time that it's taken me to write this post, but I wanted to pass on my comments while they were still pretty fresh on my mind. Cheers!
*Edit* By the way, the game seems more about mazes than monsters. So maybe the name of the game could use the word "maze." Perhaps something like "MazeFour" (or "MazeQuad" or "QuadMaze") would work (as up to four players can play), and it kind of reminds me of the game name "Connect Four." There must be other possibilities, too. Hmm...MazeTrek? AmazXing? MegaMaze? Well, I'll stop (at least for now).
Hi, David. I'll try to load this up later tonight after I get free. But I do have some comments that I wanted to pass on based on prior play. First and foremost, I like your game already and it looks like it'll get even better.
Thanks for all of your comments but my current goal is to get the game working in its original form. After all, this is an implementation of a game I had fun with a long time ago not something new I'm inventing myself. However, the original game was single player so some alterations will have to be made to enable it to be multi player. I'll take your suggestions into consideration for that. BTW, the game engine does support multiple monsters. I think I have it hardwired to only one at present but it can handle up to four and even that limit would be easy to extend. Also, the monster always moves toward the player in the most direct path possible. As you've noticed, it isn't impeded by the walls. There is one exception to that rule. If there are two ways that the monster can move toward the player then it will choose the path that doesn't require walking through a wall.
I understand. Although I thought some changes around the edges, so to speak (well, more like inside the edges), might enhance things for multiple players, it also makes sense to remain as faithful as possible to the original game.
I loaded up the latest and it seems to be working as advertised, with mazes working on all screens (actually, I just tested the N/E/W screens). As far as any input lag is concerned, maybe I didn't test enough to notice that.
I do hope that you can get the game working such that all screens use the same maze. You may need some static data structures for that (and maybe create all four mazes at the same time when or before play starts), but it's worth doing, I feel, because it'll be more exciting for multiple players to know that they are somewhat loosely linked together by playing the same maze with the same initial starting conditions.
Also, if done, it makes good use of the console's four screens. At first blush, this might seem illogical because, if all four screens have the same maze, then perhaps the game could be done on one screen for multiple players. However, the maze only gets progressively revealed, so the state of each player's revealed maze (and the locations of the tokens) will be different (on each screen). So, that makes for good use of the four screens, in my opinion. Not every game needs that, and it's not possible for every game, but it seems like a natural for this game, Monsta.
Now pardon me for sticking to my guns and stating again that the maze itself is kind of an artform. But often only a small portion of it gets revealed before the goal is collected and the game is won (That's assuming just one goal needs to be found, as things currently stand). So, at the very least (?) perhaps you could reveal the whole maze when the goal is collected, though, of course, only for the player that got the goal.
And if you're worried that doing so will destroy the history of what the player revealed, there's still the breadcrumb track, and you could possibly draw the rest of the maze in a different color, such as bright yellow or aqua, the latter of which is kind of a dimmed down version of the "white" color. Anyway, revealing the whole maze would be a visual reward for players getting the goal, kind of like how the cards bounce in Solitaire.
Also, you might consider doing a screensaver of sorts that periodically paints the screen(s) with different mazes, pausing a few seconds between each redraw. That would make for a nice screen to look at prior to the game starting, rather than just a mostly blue screen with a 'P' and 'M'. Pressing 'S' would start the game by clearing the currently-displayed maze except for the borders. But maybe you have a score screen planned for between games.
By the way, I also had the thought that the goal could possibly move around at times, such as after a random or predetermined interval or after a player walked into a visible randomizer. But that's moving away from the original version again and also a minor difference and not necessarily an improvement. Using the same maze for all players is the main thing that I'd like to see. But even that's your call, of course, though I think you've decided to go that way once you find time to code it.
Lastly, a secondary wish (that doesn't involve any significant changes to the original game) would be to add at least a third color to the screen somewhere/somehow (maybe for the tokens or breadcrumbs). Yeah, perhaps a DEC VT100 (or whatever) was monochrome, but no matter. Okay, I've overstayed my welcome, but you've got a nice game for the console in the makings there.
Yep. But an automatic reveal would be nice. Then pressing a letter could go back to the partially revealed maze, if desired and memory allowed. Anyway, as I said before, I'd avoid using a capital letter for that. I'd prefer to press a lowercase 'w' for "walls" or 'm' for "maze." Guess I'm lazy about pressing shift. Anyway, I'm chewing my cabbage twice.
Besides, you might want to consider disabling being able to show the walls when multiple players compete, unless you want a handicap feature. At the very least, players shouldn't be able to cheat/peek without others knowing.
Yep. But an automatic reveal would be nice. Then pressing a letter could go back to the partially revealed maze, if desired and memory allowed. Anyway, as I said before, I'd avoid using a capital letter for that. I'd prefer to press a lowercase 'w' for "walls" or 'm' for "maze." Guess I'm lazy about pressing shift. Anyway, I'm chewing my cabbage twice.
Yes, it would probably be good to automatically reveal the entire maze when the game is over. I'll add that.
Besides, you might want to consider disabling being able to show the walls when multiple players compete, unless you want a handicap feature. At the very least, players shouldn't be able to cheat/peek without others knowing.
The cheat buttons should probably only be available in demo mode. In fact, I need a way to select the difficulty level at start.
Hey, just had a idea that may or may not be good, but I'll throw it out there and then hopefully get out of your way. In an earlier post, I blah-blah-blah'd about how one might possibly make the maze use an even number of columns (and thus overcome the 2n+1 limitation of the maze generator algorithm). But the thought just occurred to me that you could draw a vertical bar in the color associated with the player on the far right (or left) of the screen, which would have the effect of (a)adding some color, (b) identifying the players, and (c) centering the design (maze and bar) within the screen. That'd be a heck of a lot easier than modifying the maze to insert a column, which you probably weren't planning to do anyway. Well, I say "probably" partly because you did talk about making the maze extend to the edges, in which case you'd basically have to use all 40 columns. But even there, adding the bar might be a way to go (you'd still have the right border in white beside it) as it would work with a 2n+1 maze algorithm, which is already coded/working/tested.
As a design element, I tend to like vertical bars in a solid color (with or without text), as I think they look cool. But a possible problem in this case is that the bar might seem too narrow to have the right effect (and it will be partially hidden by the bezels on your version of the console). Also, it might not look good juxtaposed against another vertical bar, that being a white side bar of the maze. Still, it might be worth considering. But if the colored bar idea doesn't work or strike you, perhaps you could just do a doubly-thick wall on either the left or right side if you want to take the maze to the edges. But if you go the color bar route, I associate blue with north, yellow with west, red with south and green with east. Anyway, I'm not even saying that the maze has to go to the edges to look good. It looks good with a blue border around it, too. And it looks decent even though it's not centered (though such things tend to bother me, unless being done intentionally for an asymmetrical design). So, it seems that you can do no wrong.
Anyway, I'm not even saying that the maze has to go to the edges to look good. It looks good with a blue border around it, too. And it looks decent even though it's not centered (though such things tend to bother me, unless was is intentional doing an asymmetrical design).
I was thinking of putting my status line on the right side and display it vertically. That way I can use that last column and I can free up another row at the bottom of the maze.
Unfortunately, I haven't had time to modify Monsta! to use the same maze on all four screens but I did add a way to change the level. You can now use the + and - keys to increment and decrement the level prior to starting the game. Higher levels have more monsters. I have also simplified the status line to only indicate what the player is carrying (number of clubs and bombs) as well as the level. The total number of randomizers has to be discovered by playing the game.
Looks good. Simplified indicators let people focus on the game. As for the number of randomizers, players don't need to know...because they will play this like a video game rather than a strategy game where they might plot out each move. If the screens updated really slowly for some reason, then things might be different, but they update right away. And some randomness is good/realistic (life is partly unpredictable).
I've got to be honest, I don't use the bombs, and I never needed to look at the number of clubs until I played with four monsters, and even then, I only looked once for a couple games. During play, sometimes I just remembered that I had picked up at least one club. Although the clubs are nice, It's reasonably easy to stay away from the monster(s). Having said that, I think that the clubs do make sense. They're there if you need them.
Today, I had a visitor, whom I let play the game. Of course, it would have been nice if we could have played the same maze, but that can come later. I do have a *very* simple request for the next incremental change or major upgrade that's probably just a couple lines of code: could you show the breadcrumb dot trail in green (or yellow) instead of plain vanilla? It's not that it's needed, as the white trail communicates where one has been well enough, but a touch of green on the blue background would really add some visual appeal.
Also, I'm curious if the randomizers can totally block the goal. Hopefully not, but maybe placement is totally random. And maybe that's good enough for almost all games. I assume that, when one gets "randomized" and appears at the other end of the "wormhole," that one won't be placed on the goal itself nor a monster, next to perhaps but not smack dab on to the goal/monster. But even if one did materialize on the goal/monster, that wouldn't be a deal breaker. Anyway, just curious.
Thanks for your comments. I will try to add some color to the game soon. I'd like to get everyone playing from the same maze first. It turned out to be a little harder than I expected since the maze is actually generated when the player starts the game rather than when the maze structure is first initialized so I need more hooks at the main level to make it possible. How did your friend like the game?
BTW, I'm pretty sure that in the original game the speed of the monsters increased with level as well as the number. I'll have to look into adding that. I realized that it will be hard to keep this implementation "pure" since I no longer have access to the original game and my memory of it is probably imperfect. This is a little different than trying to make a PacMan clone. There the original game is still available to use as a reference. So maybe I can take more liberties with Monsta! than I had been assuming.
My friend caught on right away after having watched me play it once and seemed to enjoy it, playing three or four times. This game is pretty intuitive, so one can catch on quickly. Most people appreciate that. And it's important to keep in mind that most games are a lot more fun when playing with or against others. And this one is going to work quite well in a multiplayer version (once all the hooks are in place).
As far as getting harder each time or level or whatever, I'm pretty satisfied with the way it plays now. I hate those games that start out easy and then quickly "fall off a cliff" in terms of difficulty. I still feel that the way to make this game more intriguing for multiple players is to keep generating a new target after a target is obtained (and a sound effect alerts players). As for increasing the number or speed of the monsters, that's fine, but that's more of a single player feature.
In thinking about various multiplayer games and sports, many of them don't get progressively harder as one plays. Each volley for a point in tennis follows the same rules as the point before. Yet we still enjoy it, as each point is different from the one before due to the randomness of factors beyond rules. So, I think that repeatedly going for the goal in Monsta would be a good thing, particularly as it would progressively reveal the maze. So perhaps four or five goals per round would be a good number. Sorry if I'm beating a dead horse, but I thought I'd mention it again since you're willing to relax the original rules/play dynamics a bit, particularly since this can be a multiplayer game.
One problem with adding new goals is that the initial goal is placed so it is furthest away from where the player starts. This is done during maze generation so I can't really generate a subsequent goal in the same way. They would have to be random or placed at a maximum linear distance from the player which may or may not actually be far away when following the maze. It can certainly be done though. So what happens when one player reaches a goal? Does that goal go away for the other players and the new goal appear?
Yes, I think so: the goal disappears for all players and a sound effect occurs, but players hold their positions as the new goal is placed. For the first goal, if you're willing to have two goal-placement methods (and any needed associated logic), you could still place it far away because all players start from the same cell of the maze at the beginning of a round. But subsequently, it seems like simple random placement (without clobbering someone) or something pretty close to that method would be good enough. And you could even do that for the first goal, too, if you wanted to keep the code simple and/or play consistent.
I think it will all work out in the end. Sure, sometimes the goal will be placed really close to a player, but generally not. It's all good because it's a game and some randomness is expected and any unfairness evens out over time, so it still becomes a game of mostly skill (but with enough luck to keep it interesting such that a poorer player can still win). By the way, obviously, at some point in development, it might help if the goal were in a unique color or had a pretty distinctive shape; it could even flash continually.
But your question serves to remind me that I haven't really thought through this way of playing. It seems like it would be good, but I don't know that for sure. And even if it is, there are likely other ways that are as good or better. For example, maybe multiple goals can be strewn around at the same time. Maybe goals could continually pop in and out of existences (or a goal could be mobile, but I doubt it). Maybe a mixture of goal types could be used. So I appreciate your question, as it made me realize that I'm just guessing. I'm making a logical guess, but as it turns out, logic and fun are often two different things.
Still, I do like the idea of letting the players continue to play until all or most of the walls are revealed and maybe even beyond that a bit. That's because I like the way the maze looks and because it's fun to navigate it. But there are other ways to let players see and use the maze, like make the goal harder to get to, so I could be wrong. But my gut feeling is that it would be fun if goals came "fast-and-furious," which would naturally cause the maze walls to get exposed.
Did some work tonight on having all four players use the same maze. The maze part is working but the monsters are in different places for each player. That's not what is wanted of course. Once I fix that I'll upload a new version.
Comments
Now, for fun, you could possibly let each of the four players see each other's tokens, plotted in differing colors (with each player on top for his or her screen if occupying the same space, to keep it simple). Of course, that might be even more effective if you started competition with the walls visible. Then either all four players would start from the same tile, or you could randomly position them because, well, life isn't fair and some people are born with a silver spoon in their mouths and others are not.
If you used a purple background, you could use red, green, blue and yellow for the players' tokens. But a blue background is nice, so maybe you could go with red, green, yellow and purple. Or you could swap either yellow or green for white, if the contrast between them is not enough. That can be a bit of a problem for people like me who have one of the two or three kinds of red-green color deficiency, particular for small characters (as opposed to large areas). But given one is using the cursor keys to navigate, it probably would be okay.
Anyway, keeping everything separate would be just fine, and sometimes it's best to keep things simple. But maybe the screens of those that got the target could then show the locations of the other players, so that they wouldn't get bored. And scoring could be based on time, right? A game could consist of 10 rounds, for example, with the times being cumulative. *Edit* Well, there's probably no need to limit the number of rounds (unless the score indicators were going to wrap around/overflow).
By the way, David, if a Pac-man style game gets released at some point, it will slightly overlap with Monsta, in that the former is somewhat maze-like. But Monsta is a different animal and will stand out on it's own, so Monsta will definitely add some variety. Based on the history you've provided about Monsta, namely its era, it seems likely that something like it was a precursor of Pac-Man. In fact, the other day when I played Monsta, I had the thought that there could be multiple monsters, similar to how there are four ghosts in Pac-Man. But in a multiple-monster Monsta, perhaps one could slay some of the monsters (with clubs, not by hitting them over the heads with "sleighs" as I originally spelled "slay").
Anyway, just as I posted a picture of Lunar Lander, it'd be good to post one of Monsta. Thanks to you both for your development efforts and support of the console.
The attached folder needs to be on the SD card, and - hmm - allows editing of any file, with some restrictions.
My basic plan was to build a screen editor for classical Character-Map based games. and I released a prior version. This one now allows to edit the filename and the width and height to expect when opening the file.
There are two modes the editor understand, one is a pure ascii file of width xxx and height xxx, or a screen file using the first half of the file as characters and the second half of the file as attributes, like the screen is organized by the video driver of the Quby/Wordfire.
All of this is quite rough, but it basically works.
All 4 user work on the same File and will see changes made by other users instantly.
I am kind of stressing the SD card by opening, writing or reading ONE byte and closing the file again. The most horrible construct, way open to optimization. Same goes for the cursor, it gets read from the file every time it gets moved on any screen.
I started to draw a Pac-Man Screen, and I have some idea to build a Game-Engine running Maps by (dis)allowing movements by Map-Content.
this is just a current copy, not really production level,
Enjoy,
Mike
Oh, by the way, when scrolling the instructions, if convenient (see below), I might stop scrolling once, for example, the last line of the instructions is at the top of the screen, but maybe there's no way currently for the program to know when it's at the end of the line. Also, I noticed that one can scroll the instructions sideways, replacing them with dots. Perhaps this horizontal scrolling and the way that the vertical scrolling works are due to the instruction screen using the same techniques as what the overall program uses. But I was too dense to conclude that with any confidence. Anyway, if that's the case and it makes the program easier or more elegant, or provides a nice example, then totally ignore the clueless guy in the peanut gallery (me).
I'm really looking forward to a four-player version where everyone wanders around in the same maze. I think the process of wandering through the maze--both with and without the walls exposed--is enjoyable. I would like to play (test) it with a friend or two if you release such a version.
I've noticed that one can often get the target/goal when only, say, a third of the maze walls are exposed. But the maze walls are an artistic part of the game, so they deserve to be mostly exposed. For that reason and also general playing dynamics, what I think I would do is deploy around five targets, but probably one at a time. When ANY player gets a target, "ring the bell" and then randomly deploy the next target. Then, rather than using elapsed time for scoring, it could just be a count of collected targets. So, this way, a game would consists of several rounds, wherein each round had one maze configuration but several targets. And even if players had exposed most of the walls before the final target or two were deployed, it's still fun to navigate the maze to collect them.
As for bombs and clubs, I'd consider dropping them. I think that they are a distraction. Even though this game is not designed as a smooth animation game like Pac-Man, it still plays like a video game and doesn't need smooth animation. Navigating the maze is its strength (though please consider moving just one space at a time).
But back to the bombs and clubs, they may not be needed. Yes, I realize that a player might get trapped by the monster, but so be it: let them lose one of the targets they've collected. And probably don't let them just jump over the monster. If they need a way out, make them do something unique like type "jump" to get away or whatever. But I think you can just let the chips fall where they may.
However, I think it would be cool to have time bombs that randomly appeared and momentarily blocked passageways. Players would need to navigate around them or wait them out, as they'd disappear (explode without damaging the walls) on their own after, say, five or ten seconds. If a player bumped into one, they could lose a collected target, if they had any to lose (I probably wouldn't go negative on the count).
As for the randomizers (the question marks), I love them! They can be good and bad for a player. On the one hand, they serve to make it more challenging to go in the desired direction by randomly transporting a player elsewhere (which could also be closer to the target), but on the other hand, a player may deliberately run into them to get a better position closer to a target or to get away from a/the monster. Anyway, I like how they are first invisible, but later visible, such that one can avoid them, if desired, and if one does run into a randomizer, then one has to suffer the consequences, for better or worse. So randomizers are a nice feature. By the way, I also like the "breadcrumbs" that show where a player has gone (the breadcrumbs should be a part of a player's game state, just like the exposed walls), helping one to know a safe path to avoid randomizers, as some randomizers might still be hidden. Good job!
As for the monster, while strictly not necessary, it's a cool feature. You might even consider allowing for multiple monsters on screen at the same time (and all the same for all four players, wherein I'm assuming that they players have the same maze, which I think would be best). I noticed that the monster is kind of dumb (most monsters are dumb but make up for it with their brawn, I guess). That is, the monster has no knowledge about the maze and can go through the walls. That's probably a good thing, as it allows a player to trick a monster into moving in a certain direction so that the player can go the way he or she needs to go. But multiple monsters might be difficult to manage. Perhaps there could be a total of four monsters, with each monster focusing on one player, but wherein the monsters could inadvertently attack the players that they weren't focused on. Again, rather than ending the game for a player that was "eaten" (attacked) by a monster, I'd probably just deduct one of that players accumulated targets. That's a pretty high penalty and would add to the strategy of the game, namely, avoid the monsters if you know what's good for you.
Well, I know I said to ignore my earlier comments, but as for being able to see other players, maybe something could be done there, after all. Maybe whichever player crashed into another player first (as determined by whichever keystroke came first), then that player could send the other player packing, i.e., randomly displace the other player. That'd be better than deducting a collected target, as that would be too severe of a penalty and change the game dynamics too much. Anyway, even if you did show the other players to all players, such as by using different letters or tokens or colors for them, each player's wall and breadcrumb state would be unique (though perhaps for the final target in a round you could reveal all the maze walls and kill the breadcrumbs, or not). Anyway, this last possibility could be considered after some of the other things were in place.
Well, of course, it's your game, so feel free to take or leave the above suggestions. But I am looking forward to playing a multi-player version of Monsta. And I also like playing it by myself, so that's a good sign. Good luck finding the time to work on it, though. Again, I'll load up your latest version tonight. Yeah, I could have done it in the time that it's taken me to write this post, but I wanted to pass on my comments while they were still pretty fresh on my mind. Cheers!
*Edit* By the way, the game seems more about mazes than monsters. So maybe the name of the game could use the word "maze." Perhaps something like "MazeFour" (or "MazeQuad" or "QuadMaze") would work (as up to four players can play), and it kind of reminds me of the game name "Connect Four." There must be other possibilities, too. Hmm...MazeTrek? AmazXing? MegaMaze? Well, I'll stop (at least for now).
I loaded up the latest and it seems to be working as advertised, with mazes working on all screens (actually, I just tested the N/E/W screens). As far as any input lag is concerned, maybe I didn't test enough to notice that.
I do hope that you can get the game working such that all screens use the same maze. You may need some static data structures for that (and maybe create all four mazes at the same time when or before play starts), but it's worth doing, I feel, because it'll be more exciting for multiple players to know that they are somewhat loosely linked together by playing the same maze with the same initial starting conditions.
Also, if done, it makes good use of the console's four screens. At first blush, this might seem illogical because, if all four screens have the same maze, then perhaps the game could be done on one screen for multiple players. However, the maze only gets progressively revealed, so the state of each player's revealed maze (and the locations of the tokens) will be different (on each screen). So, that makes for good use of the four screens, in my opinion. Not every game needs that, and it's not possible for every game, but it seems like a natural for this game, Monsta.
Now pardon me for sticking to my guns and stating again that the maze itself is kind of an artform. But often only a small portion of it gets revealed before the goal is collected and the game is won (That's assuming just one goal needs to be found, as things currently stand). So, at the very least (?) perhaps you could reveal the whole maze when the goal is collected, though, of course, only for the player that got the goal.
And if you're worried that doing so will destroy the history of what the player revealed, there's still the breadcrumb track, and you could possibly draw the rest of the maze in a different color, such as bright yellow or aqua, the latter of which is kind of a dimmed down version of the "white" color. Anyway, revealing the whole maze would be a visual reward for players getting the goal, kind of like how the cards bounce in Solitaire.
Also, you might consider doing a screensaver of sorts that periodically paints the screen(s) with different mazes, pausing a few seconds between each redraw. That would make for a nice screen to look at prior to the game starting, rather than just a mostly blue screen with a 'P' and 'M'. Pressing 'S' would start the game by clearing the currently-displayed maze except for the borders. But maybe you have a score screen planned for between games.
By the way, I also had the thought that the goal could possibly move around at times, such as after a random or predetermined interval or after a player walked into a visible randomizer. But that's moving away from the original version again and also a minor difference and not necessarily an improvement. Using the same maze for all players is the main thing that I'd like to see. But even that's your call, of course, though I think you've decided to go that way once you find time to code it.
Lastly, a secondary wish (that doesn't involve any significant changes to the original game) would be to add at least a third color to the screen somewhere/somehow (maybe for the tokens or breadcrumbs). Yeah, perhaps a DEC VT100 (or whatever) was monochrome, but no matter. Okay, I've overstayed my welcome, but you've got a nice game for the console in the makings there.
As a design element, I tend to like vertical bars in a solid color (with or without text), as I think they look cool. But a possible problem in this case is that the bar might seem too narrow to have the right effect (and it will be partially hidden by the bezels on your version of the console). Also, it might not look good juxtaposed against another vertical bar, that being a white side bar of the maze. Still, it might be worth considering. But if the colored bar idea doesn't work or strike you, perhaps you could just do a doubly-thick wall on either the left or right side if you want to take the maze to the edges. But if you go the color bar route, I associate blue with north, yellow with west, red with south and green with east. Anyway, I'm not even saying that the maze has to go to the edges to look good. It looks good with a blue border around it, too. And it looks decent even though it's not centered (though such things tend to bother me, unless being done intentionally for an asymmetrical design). So, it seems that you can do no wrong.
I've got to be honest, I don't use the bombs, and I never needed to look at the number of clubs until I played with four monsters, and even then, I only looked once for a couple games. During play, sometimes I just remembered that I had picked up at least one club. Although the clubs are nice, It's reasonably easy to stay away from the monster(s). Having said that, I think that the clubs do make sense. They're there if you need them.
Today, I had a visitor, whom I let play the game. Of course, it would have been nice if we could have played the same maze, but that can come later. I do have a *very* simple request for the next incremental change or major upgrade that's probably just a couple lines of code: could you show the breadcrumb dot trail in green (or yellow) instead of plain vanilla? It's not that it's needed, as the white trail communicates where one has been well enough, but a touch of green on the blue background would really add some visual appeal.
Also, I'm curious if the randomizers can totally block the goal. Hopefully not, but maybe placement is totally random. And maybe that's good enough for almost all games. I assume that, when one gets "randomized" and appears at the other end of the "wormhole," that one won't be placed on the goal itself nor a monster, next to perhaps but not smack dab on to the goal/monster. But even if one did materialize on the goal/monster, that wouldn't be a deal breaker. Anyway, just curious.
BTW, I'm pretty sure that in the original game the speed of the monsters increased with level as well as the number. I'll have to look into adding that. I realized that it will be hard to keep this implementation "pure" since I no longer have access to the original game and my memory of it is probably imperfect. This is a little different than trying to make a PacMan clone. There the original game is still available to use as a reference. So maybe I can take more liberties with Monsta! than I had been assuming.
As far as getting harder each time or level or whatever, I'm pretty satisfied with the way it plays now. I hate those games that start out easy and then quickly "fall off a cliff" in terms of difficulty. I still feel that the way to make this game more intriguing for multiple players is to keep generating a new target after a target is obtained (and a sound effect alerts players). As for increasing the number or speed of the monsters, that's fine, but that's more of a single player feature.
In thinking about various multiplayer games and sports, many of them don't get progressively harder as one plays. Each volley for a point in tennis follows the same rules as the point before. Yet we still enjoy it, as each point is different from the one before due to the randomness of factors beyond rules. So, I think that repeatedly going for the goal in Monsta would be a good thing, particularly as it would progressively reveal the maze. So perhaps four or five goals per round would be a good number. Sorry if I'm beating a dead horse, but I thought I'd mention it again since you're willing to relax the original rules/play dynamics a bit, particularly since this can be a multiplayer game.
I think it will all work out in the end. Sure, sometimes the goal will be placed really close to a player, but generally not. It's all good because it's a game and some randomness is expected and any unfairness evens out over time, so it still becomes a game of mostly skill (but with enough luck to keep it interesting such that a poorer player can still win). By the way, obviously, at some point in development, it might help if the goal were in a unique color or had a pretty distinctive shape; it could even flash continually.
But your question serves to remind me that I haven't really thought through this way of playing. It seems like it would be good, but I don't know that for sure. And even if it is, there are likely other ways that are as good or better. For example, maybe multiple goals can be strewn around at the same time. Maybe goals could continually pop in and out of existences (or a goal could be mobile, but I doubt it). Maybe a mixture of goal types could be used. So I appreciate your question, as it made me realize that I'm just guessing. I'm making a logical guess, but as it turns out, logic and fun are often two different things.
Still, I do like the idea of letting the players continue to play until all or most of the walls are revealed and maybe even beyond that a bit. That's because I like the way the maze looks and because it's fun to navigate it. But there are other ways to let players see and use the maze, like make the goal harder to get to, so I could be wrong. But my gut feeling is that it would be fun if goals came "fast-and-furious," which would naturally cause the maze walls to get exposed.