As I just mentioned to someone who inquired by PM, I ordered LCD screens and audio chips today. The screens cost me somewhat more than what I was hoping to pay. I hope to receive shipment towards the end of this week. I still need cables and power adapters. Then, I'll need some time to get the parts installed and consoles tested. But I'm making progress, slow but sure, as they say.
Dealing with small parts vendors online can be frustrating at times. I contacted four LCD screen providers only to learn that the prices that they were advertising were for non-new screens, for lack of a better term (and differentiated from "used"). But, of course, they couldn't honestly state that up front in their ads (I know: if it seems too good to be true, it probably is). Perhaps the screens were unused but pulled from devices that didn't sell or something like that. If that were the case, it might be fine (as long as I let any buyers know), but the vendors didn't specify the exact circumstances. So, I opted to go with new screens for about 25% more in cost than the non-new ones.
I told the last person that PM'ed me that I'd give him first dibs on claiming a unit from this small, initial batch that I'm building as a reward for expressing early interest. I'll do that for anyone else that either has already expressed interest via a PM (or a post in one case) or PM's me subsequently prior to announcing availability. Note: In line with the general forum rule that prohibits direct sales by members, please express any interest in purchasing either via a PM or by going to my website, not by posting interest in buying in this thread, as was laid out in a guideline about the rule a few months back.
While I'm not ready to announce a final price, I will say that my new target price for the forum is $250 USD + $50 shipping (to Australia and the US/Canada; not sure about other locals yet). That target price would bring the total with shipping to three bills even ($300), which I believe to be a rather attractive and reasonable price point for something like this that is not mass produced (remember that the system includes four screens and four keyboards). Please don't balk at the shipping cost, as the console + keyboards and box w/packing materials approaches 4.5 kg in a somewhat largish box, and I expect to lose money on that $50 shipping price based on the shipping quotes I received last week.
Now, any received PM's won't be considered to be solid commitments to buy; however, please only "claim" a console if you're sincerely interested. But feel free to PM me with questions, comments or suggestions even if you don't wish me to put your name on a console at this time (or just post general comments and questions on this thread). For those that do want to put their name on a console (even if just temporarily), once the console is available (or nearly so), I'll give you at least a couple of days to decide whether you really want to pull the trigger (buy). I'll just work my way down the list of names first come, first serve. It'll probably be a small list, but I think this is a good way to handle things at this early stage. At this time, I can't say if or when there will be a second batch. I'm just building out an initial batch of ten, including my prototype and a couple of units that I'll reserve for people on my end. But if the batch sells out and more forum members do express interest, I'll look into building a second batch. And obviously, for now, I'm just approaching people on the forum, you know, fellow Propeller-heads. Well, that's the latest. --Jim
Nice to hear you're making progress on building units for sale. I'd love to try writing some multi-player text adventure games for this. The last time I wrote one was for a PDP-10 timesharing computer back in the 70's.
Sounds intriguing, David. As I mentioned by email, I also received a PM yesterday from someone with a similar interest. Such adventure games constitute a game type that I haven't worked on at all for the console (I've had my hands pretty full), so it's exciting to consider. I presume such games typically have a language parser to handle the various responses that one might provide. Deciding how robust to make such parsers sounds pretty important, as you can't cover everything. But just off the top of my head, I can see how that might consume a lot of memory to handle the various strings, though I haven't calculated anything. So I imagine that one would have to pull a lot of the text to test against (possibly in tree form?) off of an SD card. Anyway, I know next to nothing about text adventure games or parsers like that, so I'll limit my speculation.
However, what follows is perhaps an alternative form for text adventure games that wouldn't require a sentence parser, only straightforward word matching. Essentially, you present an adventure as a series of paragraphs wherein some words are blanked out. Players then populate the blanks of a single paragraph at a time, filling in the blanks in any order. Players could do so independently or collaboratively. Letters could fill in progressively over time if players were stuck. Players could be held in lockstep from paragraph to paragraph or not, depending on the game design. Anyway, I haven't spent any time trying to flesh this out other than composing this post response (though I did allude to this possibility when you first mentioned the subject). However, I just took three minutes or so to write the following example of what I *think* I have in mind:
You're in a d____ lit room. How you ___ _____ you don't ____. To your _____ is a narrow c_______. To your ____ is a wall cabinet with various t___s inside. You open the _______ and remove a h_____t, thinking that it might ____ in h____ if you need to _x_r_c___ yourself or f____ something o___. You're just t___k___ _h___, trying to devise a c_________ plan for the _n_x____d. With your ____ better adjusted to the d_______, you n_____ a ____ directly __ _____ __ you. "Should I ____ it?" you ___ yourself. Decisions, _________! What __ __, ____ __ do?
I'll give you folks an opportunity to fill in the blanks. Perhaps you'll say that it is too easy. But with multiple players playing, things could move along quickly and it could be fun. Being fast would likely be a factor in the scoring. I like the concept because it's very language centric and perfectly tuned for the console. Perhaps it retains a bit of the text adventure spirit. But I guess it doesn't make one go through quite the same mental gymnastics. But that could be a plus as much as a minus.
Perhaps there are a lot of embellishments that could be made. The blanks above were human-chosen (by me), but perhaps the program could pick them to add variety if repeating a story (possibly by following simple rules). However, perhaps such wouldn't be strictly necessary if hundreds of adventures were created to provide sufficient variety. Or perhaps adventures themselves could be created automatically from sentences stored on an SD card, though that sounds highly tricky/complex...but might be worth considering.
Anyway, I'm just trying to get the creative juices flowing by thinking outside the box of the traditional text adventure format, which may be difficult to implement. However, for all I know, some adventure games may already use a format like the above example paragraph with blanks. I mean, over the last five decades surely not all adventure games use language parsers. Or maybe they do and what I've exemplified above goes by a different name. I suppose that's more likely.
Whatever the case, such a game engine sounds like a great candidate for a game for the console, with "adventures" or stories being stored on an SD card one by one, and with the program randomly choosing amongst the stored stories at play time. Perhaps the average story could take approximately 15 minutes to complete, allowing players to complete, say, four to six stories in one 60-90 minute session. Longer stories could be done, of course, but it would be much easier to get people to write content for shorter stories I'm pretty sure, allowing a collection of stories to be built up more rapidly. I think creating content of this nature would be fun. Heck, maybe a game like this could be created in which the players themselves create the content at play time, taking turns to create each sentence and allowing all other players to play concurrently to fill in the blanks. That's just a thought, though. But the keyboards make something like that possible, that is, not just filling in blanks but writing whole sentences.
While that might be an interesting game it isn't what I would think of as a text adventure. The idea of text adventures is to model a world and allow the player to explore it. At least that's the part I'm interested in. The parser is essential. In any case, this should be possible using your console. The original Infocom adventure games could be run on very minimal machines. They paged text and code code in from a floppy drive so an SD card should be a very adequate substitute.
Ordered some PH2.0 cables (from China to Taiwan). Received them 20 hours later for ~$5.00 in shipping. Service! Guess everything went just right (i.e., vendor shipped immediately, plane had a tail wind, etc.).
That's taxing to think about. Guess the little guy doesn't stand a chance. In related news, the LCD screens came. I need to go out of town soon for a couple of days, but hope to get the screens installed and consoles tested next week. Hopefully, they'll be "shipshape" (i.e., in boxes) soon. The screens are new; I'll probably leave the protective screen film on them when I tape the driver boards to the backs and connect the cables. Users can then peel them off on their own by temporarily removing the bezel cap. All for now.
@David: That's seems right (It's been a while since I've checked). Also, you might be able to reclaim some memory from the main objects that load into cogs and then are never reloaded again. So far, I haven't used that technique myself and don't have the particulars on how things are stored. But I would think that doing so could free several KB for data/tables/strings. There's probably not much reason to keep those objects in HUB, as they seem pretty reliable and likely won't need to be reloaded after the initial load into COGs. My routines don't have any built-in facility to reload stuff. I've forgotten, but the SD card stuff might have been able to reload at one time, but that was before the latest version of the PCB which uses dedicated lines for the SD card socket and operation is quite stable. If something were ever to go wrong with a driver, say the video drive (four instances) or whatever, one would have to cycle power, but I haven't had that happen with this version (yet). Anyway, you probably know the particulars about how to reuse such memory space and it sounds like you've got a good reason to do so, that being multiplayer text adventure games. Being lazy compared to you, I sometimes avoid the more advanced programming techniques until I really need them. And so far, my games have worked in the available memory space. But as they say, "Necessity is the mother of invention.
@WBA: I like clocks, so I've taken notice of that project several times in the past (more than one incarnation). It's quite artistic/clever. For a time, in addition to my four main time screen, I had various other screens that could appear, and one of them was the time in words. However, word strings eat into memory pretty fast compared to the efficient byte codes for SPIN instructions. Also, I only had/have the one standard font size, which is kind of small, so displaying the time in words wasn't so effective. I had other screens, too, like displaying the time on flag-like background (such as the US flag with the time in the star field). But ultimately, I decided to rip all of that extra stuff out to simplify things. And before the big rip (not a reference to cosmology), I think I was down to under 200 longs of free memory, and I believe that was tempting fate, stack-wise. I also eliminated a troubleshooting screen for testing the system because it was basically a luxury, as most of the functionality of it was obtainable in other ways. I felt it was best to keep things minimal to make it easier for people to modify my clock program if they didn't want to write one from scratch, thus allowing them to add functionality (or whatever). Anyway, potential users can either modify the clock that's in EEPROM or write alternative versions that can be loaded off an SD card. But back to that clock style you mentioned, if one used a different video driver, I believe one might be able to generate larger text, possibly with bitmapped graphics. But any such alternate driver must be written in such as way as to alloy the v-sync and h-sync signals to be shared amongst the screens (such as by synchronizing four instances) if driving all four screens. But my games and the clock utilize the console's "standard" tile-mapped video driver that forum member kuroneko developed. For standard text stuff, that's probably enough. I mean, multiple font sizes and faces would be great, but I feel that the text looks pretty good on the system as is. Chip Gracey designed a nice three-pixel-wide font that is easy to read and somewhat bold.
@All: I think I will be in a position to take orders sometime next week. I just need to determine whether I'll use my own PayPal account or try to use an account of someone local here in Taiwan. I tested the waters to see if people would be willing to use MoneyGram as the payment method, but the waters seemed pretty icy. So I'll probably just go with PayPal (sorry, no credit cards), as a lot of people are comfortable with that. My apologies for the lack of recent progress and updates. Some medical matters cut into available time and money to move forward as fast as I would have liked to. But things seem to have stabilized, so I hope to make an announcement next week that I'm able to take orders. At that time, anyone wanting to order a console can send me an instant personal message (PM) for details of the payment method and to supply the shipping address. However, for now, I'm just doing this initial batch, taking things step-by-step. So, keep an eye out for an announcement beginning about mid-week next week. And if the forum software still allows it, I'll probably alter the name of this thread to make availability more manifest, such as by using "Now Available/Shipping" or similar. That would help alert people. Thanks for your patience and continuing interest.
Is your source code available somewhere in a repository? My current plan is to get my game engine working on a vanilla Prop board and later worry about merging it with your code to run on your console. I figure I can start out by just using a couple of PropPlugs to simulate multiple consoles. How does your system work? Do you have some sort of master program that presents a menu of games available on the SD card and loads them on demand? What does the runtime environment of the game look like? How does my game logic print to each of the LCD displays and get input from them?
Hi, David. No, I haven't put my code in a repository. I don't have any immediate plans to do so. What I'm more inclined to do is to make SD card images available from my website at some point. I know programmers love GitHub and other awkwardly-named repositories (I like the name GitHub about as much as I like the name Android for a phone OS for the masses, despite the cute mascot, but what do I know). Of course, all that version tracking stuff is great and allows for far easier collaboration (maintenance, upgrades, multiple versions, etc.). But, for now, I have no immediate plans to take advantage of it. Frankly, at this stage, only a few people even know about the existence of the console system, and even fewer have expressed interest. If you feel the need to help me "see the light" on this matter, perhaps you could send me a PM (just keep in mind the saying about dragging a horse to water). Of course, even if I don't utilize a repository, that doesn't mean you couldn't. For example, kuroneko, a real programmer, like yourself, uses GitHub for his stuff. I'll take advantage of such a repository if and when it becomes necessary. Anyway, in the beginning, I'll either put images on my website or supply an image on an SD card with the system.
As for how the console loads games, yes, a separate menu program is available for doing that. If you boot up the console into the clock program (assuming you leave it in the EEPROM), hitting ESCape will automatically load a Game Menu program. And from there, one can select a game or program to run. On my website, there's a video of the Game Menu program in operation. It lets one choose among 48 programs off of an SD card (6 pages of games with 8 games per page). That seems to me like a fair number of programs on a single SD card. The reason for the limit is that the Game Menu program automatically scans an inserted SD card and load the names and a descriptions of all the programs on the card that are stored in their own directories. That speeds up navigating through them. But one could write a different--presumably less responsive--menu program without that hard limit. Again, see the video to see the program in action. Naturally, one could place the game menu program in the EEPROM, but I keep the clock there. Perhaps one could merge a clock routine with a menu routine, but memory could be tight.
As for your remaining inquiries, there's some information on the website and examples that address them, or at least touch on them fairly hard. And though it might not be enough for you to fully develop your system without having a console, it's probably enough to get you going. In particular, there are examples of how to write to the screen(s) with the "basic/standard" screen routines (the code for the routines is given with the examples). They are quite straightforward to use. And as for how to receive input from the four keyboards, there's an exemplary minimal program snippet on the website that does exactly that. I don't think it provides the initialization routine (not that there's anything special there), but it explicitly shows how to receive character data from the keyboard buffers from the quad-keyboard driver. I think it just involves about three lines of code. The way my games do it is to poll the keyboards round-robin style somewhere in the main loop or a sub-loop thereof. If value 0 is returned, the corresponding buffer for the polled keyboard is empty, otherwise the next character in line is popped from that keyboard's buffer, FIFO-style, all handled by the driver automatically. Now as I write this response to your post, I don't think I've written the keyboard driver to return the key up/down states for fast-action video games, though that should be possible. But for text adventure games, you probably don't care about that. And even without that, you can certainly know who typed a character first (not that you'd generally need that). Actually, there's a very slight bit of "unfairness," in that I generally poll the keyboards in the same order NWES (counterclockwise from north) continually for simplicity. One could randomize the polling order, but that would slightly complicate things for very little benefit, as one would rarely see the difference based on how slow human reflexes are compared to how fast the system can poll, and that is with doing whatever else that one needs to do in the loop (such as process character input, scoring and keeping time). Anyway, hopefully you can take a look at the website to get a better idea. Suffice it to say that writing to the screens and receiving text from the keyboards is dead simple, like you'd probably expect. Hmm...no parsing is done for words or anything like that; you just get a character at a time. From there you can process (or ignore) things as needed.
I generally use the write() method for outputting words/sentences. And for receiving text input, the main lines (in a loop) are:
s := kbs := (kbs + 1) // 4 'cycle among the 4 kbd's 0..3, wrapping around
ch := kbd.getKey(kbs) 'get key from keyboard buffer, if present
if ch <> 0
'process character
Where s = screen (for subsequent usage), kbs = keyboard selector (current keyboard in round-robin order), ch = text character from a keyboard buffer, and kbd = the array of four keyboards
Apologies for not providing direct links in my prior response.
My pleasure. Considering all you want to do, it sounds like memory could be tight. Best of luck.
Any text will go on an SD card and the game system has a PC-based compiler that produces byte codes that are interpreted by a PASM program at runtime so they don't take up that much space. We'll see though.
I've got a few game consoles available for sale. Units are fully assembled and tested. If anyone wants to purchase one, send me a personal message (PM) here. The USD price is $250 + $50 shipping = $300 total. Payment will be through PayPal. Orders will be taken first come, first serve, with the exception that those who have previously expressed interest have five calendar days from now to decide whether to go ahead (Obviously, people's situations can change so there's no obligation to follow through). Shipping should start next week, with delivery a couple weeks after that. This offer will be available for the coming two weeks, if units are still available. For now, I'm just selling units from the initial batch, so I won't be taking backorders (and there are no immediate plans for a second batch). Again, PM me if you want to order a unit. Thanks. --Jim
This is a pretty interesting and cleverly implemented project/product. I think that focussing on word games is a good idea because there are many products focussing on twitchy video games, and if you're trying to get a family group together with all ages word games could be a great fit. Plus I think that it should be easier to develop them than graphics based video games, and easy for anyone to enhance them with additional content.
You could even add some additional (romanized) languages - I wonder if foreign language teachers could use this in their classes to motivate students? Or perhaps games to prep kids for SAT tests etcetera.
When I was recently in China there was a popular game show based on classical Chinese poetry where a large number of audience members could input answers in parallel with some sort of keyboard. (I think it was this - https://u.osu.edu/mclc/2017/03/03/ancient-poetry-game-show/)
Also the price seems quite reasonable. If you look at some Pi-based products Piper Minecraft is $300 and only has a single screen. Kano complete is $200 for one unit. You also have a clever physical design and by centralizing everything it should "just work", you don't have to worry about different components getting out of sync, and the setup is straightforward. I never would have considered the snack holders if I had been doing this ;-)
Edited to add:
Fill in the blank mathematical problems would be another possibility for education. You could even give players problems based on their ability, so adults and kids could still play each other.
Also perhaps a crossword race where you race to fill in the rows/columns and the first player to complete an entry gets the score for it. A simple handicapping system could be to allow some players to receive feedback about wrong individual letters, and others get penalized if they enter a wrong solution.
David - another adventure possibility might be a multiplayer rogue-like game. Seems tough with the memory constraints, but perhaps? Look at Dwarf fortress for an example of ASCII-style graphics gone wild.
Jim since you're in Taiwan - was this console at all influenced by watching people play Mahjong? It looks like it's designed with those types of tables in mind, and the cardinal directions feature prominently. (For anyone who hasn't seen the really fancy tables search on google and be amazed.)
As for languages, the console is basically limited to the built-in Prop character set (which has some european language characters). However, one can redefine some of the characters (such as the first 32) to be custom characters (letters or graphical elements) at the expense of RAM.
I like the idea about content similar to that on SAT tests. The math and crossword ideas are good, too. Regarding a game similar to a crossword puzzle, it wouldn't necessarily have to use the stardard horizontal-vertical puzzle format.
I hadn't heard of the classical poetry show, but China has a lot of high-budget singing shows/contests.
About those Pi add-ons, I'm always confounded by how much they cost considering how reasonable the Pi is. In the case of Kano, though, I believe that they produced their own keyboard unit, which is cool.
About the snack bowl, it's cool and distinctive, but perhaps I should have focused more on making the system cheaper and easier to make. People are pretty sensative about pricing these days, considering how much functionality they can get in a cell phone.
As for Mahjong, I've never played, but I've briefly seen it being played on TV. It does have tiles for the four cardinal directions, as you mentioned. I ended up with four directions mostly because I was working on a board game before I ever started on the console. The board game idea mutated into the more generalized console.
But you're right about the square tables being rather ideal for the console. For example, card tables (in various sizes) accommodate it and the keyboards quite well. Maybe I should have gone into the table business instead of working on a console. Then again, shipping would be a killer.
David - another adventure possibility might be a multiplayer rogue-like game. Seems tough with the memory constraints, but perhaps? Look at Dwarf fortress for an example of ASCII-style graphics gone wild.
Jim since you're in Taiwan - was this console at all influenced by watching people play Mahjong? It looks like it's designed with those types of tables in mind, and the cardinal directions feature prominently. (For anyone who hasn't seen the really fancy tables search on google and be amazed.)
Yes, Rogue would be a good option. Also Battleship. There are lots of things that could be done with this platform.
I ended up with four directions mostly because I was working on a board game before I ever started on the console. The board game idea mutated into the more generalized console.
Do you mean you were originally thinking about making a Propeller-controlled board game? Can you say more about it? I've always been intrigued by electronics-assisted board games.
I was working on a high school knowledge game with 48 subjects. Rather than using cards, the questions were displayed on a little music player with an LCD screen that could run Flash programs that players could pass around (another possibility was having four of them). So it was kind of a hybrid game (electronic device complemented with standard board game equipment). I like the physicality of a board game with the dice and the movement of tokens around the board. The game console gives that up, obviously. A virtual board could be done on the screens, of course, but it wouldn't have the tactile elements that make for a somewhat different user experience. And although I've considered a couple different versions of the console that would involve a board with "cutouts" for the keyboards (such as by propping up the four screens above the game board like a sports arena's score board), those ideas didn't seem as pragmatic as a straight console.
Now the "Propeller-controlled board game" that you've mentioned may have merit in some incarnation. There are also some game systems that involve tablets, and even large LCD touch screens. The latter are quite sophisticated like Microsoft's original Surface (?) table (an actual table, not a tablet) that cost five or ten grand when first introduced, but such offerings don't seem to have caught on yet. I've seen newer, affordable versions, but it seems that the existence of cell phones and tablets restrict the market. Still, I think I saw a video of something like that running The Settlers of Catan. Guess stuff like that puts my little effort to shame, as they have all the bells and whistles (dynamic graphics, touch gestures and so on). Then again, they are not so user-friendly when it comes to handling text, but I suppose that they will be one day (if they're not already).
Actually, I like the text-only nature of your console. It seems like a good platform for bringing back lots of old text-based games not just word games. One might imagine a version of the old StarTrek ASCII graphics game for multiple players. Of course, most of those old games were single player. They would all have to be adapted for your console. The good thing is that they ran in very little memory since the early personal computers were very resource constrained.
Here's a sales update: A couple of you have PM'd me over the last week for my PayPal info, which I'll get to you soon. Meanwhile, I've decided to offer a $100 discount on the console price (that's a total of $200 shipped) to anyone that commits to writing a game for the console (within six months of receipt) and allows me to bundle the game with the console in any future sales. The exact nature of the game is up to you, but it should be a multiplayer game (simultaneous play or turn-based, either way) and it should be something without any copyright restrictions. Preferably, it would be something that players can play more than once, but it doesn't have to be. It can be a word game, an adventure game, a card-like game, a typing game, a video game, and so on, doesn't matter. This offer *is* also retroactively available to those who have already PM'd me, or you can stick with the original deal if you don't want to make such a commitment. However, I've decided to limit this offer to the next two new buyers, as I plan to keep some consoles for another purpose. This new offer is good for a week. Let me know by a PM if you want to buy. Thanks. --Jim
That's a nice offer. I almost have my revised adventure writing language working. I just have to implement try/catch/finally/throw (like in Javascript) and I can attempt a simple game. The interpreter is currently written in C and runs on a PC but I have a PASM interpreter for a very similar language that I can easily adapt to this one. That should let me run these games on a Propeller.
There is only sketchy documentation at present but there is a skeleton of a simple game in the file "game.adv". This will be yet another funky language that runs on the Propeller! I have no illusions that it will be used by anyone except me but it was fun to write.
Comments
Dealing with small parts vendors online can be frustrating at times. I contacted four LCD screen providers only to learn that the prices that they were advertising were for non-new screens, for lack of a better term (and differentiated from "used"). But, of course, they couldn't honestly state that up front in their ads (I know: if it seems too good to be true, it probably is). Perhaps the screens were unused but pulled from devices that didn't sell or something like that. If that were the case, it might be fine (as long as I let any buyers know), but the vendors didn't specify the exact circumstances. So, I opted to go with new screens for about 25% more in cost than the non-new ones.
I told the last person that PM'ed me that I'd give him first dibs on claiming a unit from this small, initial batch that I'm building as a reward for expressing early interest. I'll do that for anyone else that either has already expressed interest via a PM (or a post in one case) or PM's me subsequently prior to announcing availability. Note: In line with the general forum rule that prohibits direct sales by members, please express any interest in purchasing either via a PM or by going to my website, not by posting interest in buying in this thread, as was laid out in a guideline about the rule a few months back.
While I'm not ready to announce a final price, I will say that my new target price for the forum is $250 USD + $50 shipping (to Australia and the US/Canada; not sure about other locals yet). That target price would bring the total with shipping to three bills even ($300), which I believe to be a rather attractive and reasonable price point for something like this that is not mass produced (remember that the system includes four screens and four keyboards). Please don't balk at the shipping cost, as the console + keyboards and box w/packing materials approaches 4.5 kg in a somewhat largish box, and I expect to lose money on that $50 shipping price based on the shipping quotes I received last week.
Now, any received PM's won't be considered to be solid commitments to buy; however, please only "claim" a console if you're sincerely interested. But feel free to PM me with questions, comments or suggestions even if you don't wish me to put your name on a console at this time (or just post general comments and questions on this thread). For those that do want to put their name on a console (even if just temporarily), once the console is available (or nearly so), I'll give you at least a couple of days to decide whether you really want to pull the trigger (buy). I'll just work my way down the list of names first come, first serve. It'll probably be a small list, but I think this is a good way to handle things at this early stage. At this time, I can't say if or when there will be a second batch. I'm just building out an initial batch of ten, including my prototype and a couple of units that I'll reserve for people on my end. But if the batch sells out and more forum members do express interest, I'll look into building a second batch. And obviously, for now, I'm just approaching people on the forum, you know, fellow Propeller-heads. Well, that's the latest. --Jim
However, what follows is perhaps an alternative form for text adventure games that wouldn't require a sentence parser, only straightforward word matching. Essentially, you present an adventure as a series of paragraphs wherein some words are blanked out. Players then populate the blanks of a single paragraph at a time, filling in the blanks in any order. Players could do so independently or collaboratively. Letters could fill in progressively over time if players were stuck. Players could be held in lockstep from paragraph to paragraph or not, depending on the game design. Anyway, I haven't spent any time trying to flesh this out other than composing this post response (though I did allude to this possibility when you first mentioned the subject). However, I just took three minutes or so to write the following example of what I *think* I have in mind:
You're in a d____ lit room. How you ___ _____ you don't ____. To your _____ is a narrow c_______. To your ____ is a wall cabinet with various t___s inside. You open the _______ and remove a h_____t, thinking that it might ____ in h____ if you need to _x_r_c___ yourself or f____ something o___. You're just t___k___ _h___, trying to devise a c_________ plan for the _n_x____d. With your ____ better adjusted to the d_______, you n_____ a ____ directly __ _____ __ you. "Should I ____ it?" you ___ yourself. Decisions, _________! What __ __, ____ __ do?
I'll give you folks an opportunity to fill in the blanks. Perhaps you'll say that it is too easy. But with multiple players playing, things could move along quickly and it could be fun. Being fast would likely be a factor in the scoring. I like the concept because it's very language centric and perfectly tuned for the console. Perhaps it retains a bit of the text adventure spirit. But I guess it doesn't make one go through quite the same mental gymnastics. But that could be a plus as much as a minus.
Perhaps there are a lot of embellishments that could be made. The blanks above were human-chosen (by me), but perhaps the program could pick them to add variety if repeating a story (possibly by following simple rules). However, perhaps such wouldn't be strictly necessary if hundreds of adventures were created to provide sufficient variety. Or perhaps adventures themselves could be created automatically from sentences stored on an SD card, though that sounds highly tricky/complex...but might be worth considering.
Anyway, I'm just trying to get the creative juices flowing by thinking outside the box of the traditional text adventure format, which may be difficult to implement. However, for all I know, some adventure games may already use a format like the above example paragraph with blanks. I mean, over the last five decades surely not all adventure games use language parsers. Or maybe they do and what I've exemplified above goes by a different name. I suppose that's more likely.
Whatever the case, such a game engine sounds like a great candidate for a game for the console, with "adventures" or stories being stored on an SD card one by one, and with the program randomly choosing amongst the stored stories at play time. Perhaps the average story could take approximately 15 minutes to complete, allowing players to complete, say, four to six stories in one 60-90 minute session. Longer stories could be done, of course, but it would be much easier to get people to write content for shorter stories I'm pretty sure, allowing a collection of stories to be built up more rapidly. I think creating content of this nature would be fun. Heck, maybe a game like this could be created in which the players themselves create the content at play time, taking turns to create each sentence and allowing all other players to play concurrently to fill in the blanks. That's just a thought, though. But the keyboards make something like that possible, that is, not just filling in blanks but writing whole sentences.
Edit: Never mind. I checked back to earlier messages and see that about 16K of hub memory is available for the game logic.
https://www.instructables.com/id/Literary-Clock-Made-From-E-reader/
Excel file in that page has quotes for almost every minute of the day.
@WBA: I like clocks, so I've taken notice of that project several times in the past (more than one incarnation). It's quite artistic/clever. For a time, in addition to my four main time screen, I had various other screens that could appear, and one of them was the time in words. However, word strings eat into memory pretty fast compared to the efficient byte codes for SPIN instructions. Also, I only had/have the one standard font size, which is kind of small, so displaying the time in words wasn't so effective. I had other screens, too, like displaying the time on flag-like background (such as the US flag with the time in the star field). But ultimately, I decided to rip all of that extra stuff out to simplify things. And before the big rip (not a reference to cosmology), I think I was down to under 200 longs of free memory, and I believe that was tempting fate, stack-wise. I also eliminated a troubleshooting screen for testing the system because it was basically a luxury, as most of the functionality of it was obtainable in other ways. I felt it was best to keep things minimal to make it easier for people to modify my clock program if they didn't want to write one from scratch, thus allowing them to add functionality (or whatever). Anyway, potential users can either modify the clock that's in EEPROM or write alternative versions that can be loaded off an SD card. But back to that clock style you mentioned, if one used a different video driver, I believe one might be able to generate larger text, possibly with bitmapped graphics. But any such alternate driver must be written in such as way as to alloy the v-sync and h-sync signals to be shared amongst the screens (such as by synchronizing four instances) if driving all four screens. But my games and the clock utilize the console's "standard" tile-mapped video driver that forum member kuroneko developed. For standard text stuff, that's probably enough. I mean, multiple font sizes and faces would be great, but I feel that the text looks pretty good on the system as is. Chip Gracey designed a nice three-pixel-wide font that is easy to read and somewhat bold.
@All: I think I will be in a position to take orders sometime next week. I just need to determine whether I'll use my own PayPal account or try to use an account of someone local here in Taiwan. I tested the waters to see if people would be willing to use MoneyGram as the payment method, but the waters seemed pretty icy. So I'll probably just go with PayPal (sorry, no credit cards), as a lot of people are comfortable with that. My apologies for the lack of recent progress and updates. Some medical matters cut into available time and money to move forward as fast as I would have liked to. But things seem to have stabilized, so I hope to make an announcement next week that I'm able to take orders. At that time, anyone wanting to order a console can send me an instant personal message (PM) for details of the payment method and to supply the shipping address. However, for now, I'm just doing this initial batch, taking things step-by-step. So, keep an eye out for an announcement beginning about mid-week next week. And if the forum software still allows it, I'll probably alter the name of this thread to make availability more manifest, such as by using "Now Available/Shipping" or similar. That would help alert people. Thanks for your patience and continuing interest.
As for how the console loads games, yes, a separate menu program is available for doing that. If you boot up the console into the clock program (assuming you leave it in the EEPROM), hitting ESCape will automatically load a Game Menu program. And from there, one can select a game or program to run. On my website, there's a video of the Game Menu program in operation. It lets one choose among 48 programs off of an SD card (6 pages of games with 8 games per page). That seems to me like a fair number of programs on a single SD card. The reason for the limit is that the Game Menu program automatically scans an inserted SD card and load the names and a descriptions of all the programs on the card that are stored in their own directories. That speeds up navigating through them. But one could write a different--presumably less responsive--menu program without that hard limit. Again, see the video to see the program in action. Naturally, one could place the game menu program in the EEPROM, but I keep the clock there. Perhaps one could merge a clock routine with a menu routine, but memory could be tight.
As for your remaining inquiries, there's some information on the website and examples that address them, or at least touch on them fairly hard. And though it might not be enough for you to fully develop your system without having a console, it's probably enough to get you going. In particular, there are examples of how to write to the screen(s) with the "basic/standard" screen routines (the code for the routines is given with the examples). They are quite straightforward to use. And as for how to receive input from the four keyboards, there's an exemplary minimal program snippet on the website that does exactly that. I don't think it provides the initialization routine (not that there's anything special there), but it explicitly shows how to receive character data from the keyboard buffers from the quad-keyboard driver. I think it just involves about three lines of code. The way my games do it is to poll the keyboards round-robin style somewhere in the main loop or a sub-loop thereof. If value 0 is returned, the corresponding buffer for the polled keyboard is empty, otherwise the next character in line is popped from that keyboard's buffer, FIFO-style, all handled by the driver automatically. Now as I write this response to your post, I don't think I've written the keyboard driver to return the key up/down states for fast-action video games, though that should be possible. But for text adventure games, you probably don't care about that. And even without that, you can certainly know who typed a character first (not that you'd generally need that). Actually, there's a very slight bit of "unfairness," in that I generally poll the keyboards in the same order NWES (counterclockwise from north) continually for simplicity. One could randomize the polling order, but that would slightly complicate things for very little benefit, as one would rarely see the difference based on how slow human reflexes are compared to how fast the system can poll, and that is with doing whatever else that one needs to do in the loop (such as process character input, scoring and keeping time). Anyway, hopefully you can take a look at the website to get a better idea. Suffice it to say that writing to the screens and receiving text from the keyboards is dead simple, like you'd probably expect. Hmm...no parsing is done for words or anything like that; you just get a character at a time. From there you can process (or ignore) things as needed.
And for receiving keyboard input, I meant the Code tab: http://wordfire.net/code/code.html
I generally use the write() method for outputting words/sentences. And for receiving text input, the main lines (in a loop) are:
Where s = screen (for subsequent usage), kbs = keyboard selector (current keyboard in round-robin order), ch = text character from a keyboard buffer, and kbd = the array of four keyboards
Apologies for not providing direct links in my prior response.
You could even add some additional (romanized) languages - I wonder if foreign language teachers could use this in their classes to motivate students? Or perhaps games to prep kids for SAT tests etcetera.
When I was recently in China there was a popular game show based on classical Chinese poetry where a large number of audience members could input answers in parallel with some sort of keyboard. (I think it was this - https://u.osu.edu/mclc/2017/03/03/ancient-poetry-game-show/)
Also the price seems quite reasonable. If you look at some Pi-based products Piper Minecraft is $300 and only has a single screen. Kano complete is $200 for one unit. You also have a clever physical design and by centralizing everything it should "just work", you don't have to worry about different components getting out of sync, and the setup is straightforward. I never would have considered the snack holders if I had been doing this ;-)
Edited to add:
Fill in the blank mathematical problems would be another possibility for education. You could even give players problems based on their ability, so adults and kids could still play each other.
Also perhaps a crossword race where you race to fill in the rows/columns and the first player to complete an entry gets the score for it. A simple handicapping system could be to allow some players to receive feedback about wrong individual letters, and others get penalized if they enter a wrong solution.
Jim since you're in Taiwan - was this console at all influenced by watching people play Mahjong? It looks like it's designed with those types of tables in mind, and the cardinal directions feature prominently. (For anyone who hasn't seen the really fancy tables search on google and be amazed.)
As for languages, the console is basically limited to the built-in Prop character set (which has some european language characters). However, one can redefine some of the characters (such as the first 32) to be custom characters (letters or graphical elements) at the expense of RAM.
I like the idea about content similar to that on SAT tests. The math and crossword ideas are good, too. Regarding a game similar to a crossword puzzle, it wouldn't necessarily have to use the stardard horizontal-vertical puzzle format.
I hadn't heard of the classical poetry show, but China has a lot of high-budget singing shows/contests.
About those Pi add-ons, I'm always confounded by how much they cost considering how reasonable the Pi is. In the case of Kano, though, I believe that they produced their own keyboard unit, which is cool.
About the snack bowl, it's cool and distinctive, but perhaps I should have focused more on making the system cheaper and easier to make. People are pretty sensative about pricing these days, considering how much functionality they can get in a cell phone.
As for Mahjong, I've never played, but I've briefly seen it being played on TV. It does have tiles for the four cardinal directions, as you mentioned. I ended up with four directions mostly because I was working on a board game before I ever started on the console. The board game idea mutated into the more generalized console.
But you're right about the square tables being rather ideal for the console. For example, card tables (in various sizes) accommodate it and the keyboards quite well. Maybe I should have gone into the table business instead of working on a console. Then again, shipping would be a killer.
Thanks again for your feedback. --Jim
Now the "Propeller-controlled board game" that you've mentioned may have merit in some incarnation. There are also some game systems that involve tablets, and even large LCD touch screens. The latter are quite sophisticated like Microsoft's original Surface (?) table (an actual table, not a tablet) that cost five or ten grand when first introduced, but such offerings don't seem to have caught on yet. I've seen newer, affordable versions, but it seems that the existence of cell phones and tablets restrict the market. Still, I think I saw a video of something like that running The Settlers of Catan. Guess stuff like that puts my little effort to shame, as they have all the bells and whistles (dynamic graphics, touch gestures and so on). Then again, they are not so user-friendly when it comes to handling text, but I suppose that they will be one day (if they're not already).
If anyone is interested in following this language development the code is here: https://github.com/dbetz/advsys2
There is only sketchy documentation at present but there is a skeleton of a simple game in the file "game.adv". This will be yet another funky language that runs on the Propeller! I have no illusions that it will be used by anyone except me but it was fun to write.