Congrats on the progress, David. I assume that the PASM-based adventure language interpreter is for responding to input and enforcing the map during actual game play (rather than for creating the adventure world in the first place). Wonder if all that will run on the WF game console. I guess so. For my games, there is one free cog left (assuming that a dedicated audio cog isn't used). That is, there's a game cog, four video cogs, an SD cog, and a keyboard cog, for a total of seven used cogs, leaving one free. Assuming that you need a master game cog for SPIN to tie everything together, the adventure language interpreter would occupy the last remaining cog. So things would just work out (assuming no memory problems).
The games are created on a PC but they will run on the Propeller. This is really no different than any other game. They will likely be written in Spin on a PC. However, you could put Tachyon Forth on the WF platform and that might allow you to create games right on the console. I don't have much experience with Tachyon myself but it is a very powerful language.
Yes, I was assuming that your adventure games would be created in another environment. I was just trying to get at your cog allocation if running such games on the console. As for Tachyon and Chip's desire for a self-hosted system, that's all great. But when it comes to the game console, I'd rather develop word games in SPIN on my PC than on one of the 7" screens of the console. The 7" screens are possibly the perfect size for playing such games, but on the smallish side for development. However, I can see adding game content being a possibility on the console (since it's usually just text), but I'd probably prefer to have Google and the full internet, a spell checker and so on at the ready, which a PC provides.
For what it's worth, here's what the console looks like prior to shipping (the console is flanked by a keyboard on two sides, and the other two keyboards go on top before sealing the box):
For what it's worth, here's what the console looks like prior to shipping (the console is flanked by a keyboard on two sides, and the other two keyboards go on top before sealing the box):
Cool! I'm looking forward to receiving mine. I'll have to accelerate my game programming so that I have something ready to try when it arrives. Thanks for creating such an interesting console!
I made a bit more progress on the virtual machine I want to use on the WordFire. Unfortunately, I'm nearly out of COG memory for the virtual instruction set interpreter and I need to add three more instructions for handling exceptions. Looks like I have to put some effort into optimizing what I've got before moving ahead. On a positive note, the PASM interpreter is working and running programs I used to have to run on a PC.
Congrats on your progress. Is all the try-catch-finally conversion stuff (that you mentioned in another thread) strictly necessary? I mean, a game running on the console isn't anything mission critical, so it's sometimes good to simplify things. Of course, it's best to write robust code, and the game logic should be reliable so as not to alienate players that lose their game due to a crash. But if worse comes to worse one time out of a thousand games and the console crashes, the power can be cycled and they can have another go. Sometimes, I have a tendency to overcomplicate things. Maybe balance is the key.
Congrats on your progress. Is all the try-catch-finally conversion stuff (that you mentioned in another thread) strictly necessary? I mean, a game running on the console isn't anything mission critical, so it's sometimes good to simplify things. Of course, it's best to write robust code, and the game logic should be reliable so as not to alienate players that lose their game due to a crash. But if worse comes to worse one time out of a thousand games and the console crashes, the power can be cycled and they can have another go. Sometimes, I have a tendency to overcomplicate things. Maybe balance is the key.
Well, I have to deal with the situation where a program asks for a property of an object that doesn't exist. My current way of handling that is to generate an exception with other code to catch the exception. The old system just returned NIL for any property that didn't exist and any method called that didn't exist did nothing and returned NIL. I guess I could go back to that approach. I'll have to think about this. I might be able to squeeze my code to make these extra opcodes fit. They aren't that big.
Gee, if you have to deal with code asking for properties that may or may not exist, then you really are writing something somewhat comparable to a computer language parser (but for adventure game tokens), though scaled down. So it's understandable that you would like to handle such exceptions, if possible. But it's not clear to me how you could meaningfully handle an exception for a property that doesn't exist. I mean, what would that entail: rolling back some of the game state or pending content? And does it mean that the game creator made a mistake in designing the game? Or is it that the bytecode compiler didn't catch it or couldn't catch it because it was a run-time thing? Whatever the case, it sounds pretty daunting to deal with. So good luck. *Edit* However, it sounds like you already know how to deal with it but just don't have the COG memory. In that case, good luck optimizing.
It is a complete C-like programming language. Here is the code to get a property from an object taking into account that the property may be missing. FYI, this is used for things like navigation commands. If a user asks to "go north" and there is no exit from the current location to the north then the code must handle that.
def getp(obj, prop)
{
var value;
try {
value = obj.(prop);
}
catch (e) {
value = 0;
}
return value;
}
Looks impressive. Wonder if there's a discovery method for cycling through (listing) the available objects. But that's probably overkill and not needed (as it's not for a general purpose programming language). Anyway, good luck optimizing things to squeeze functionality into the interpreter COG. Perhaps the conditional testing options available for each PASM statement could save a long here and there, even though you're no doubt already using that technique quite a bit. And maybe the same variable (memory location) can be used for multiple things at different times (if the times that such variables are used don't overlap and state doesn't need to be maintained between such uses). Might not be pretty from a coding standpoint, but might free a long or two. There's probably other "tips and tricks" like that which might be candidates for saving memory. In tight (memory) times, one has to think outside the box (though I'm not saying to go to the HUB necessarily). For example, you can reuse initialization variables for other things. Those people that are good at writing video drivers here tend to know how to squeeze every ounce out of each PASM statement.
Looks impressive. Wonder if there's a discovery method for cycling through (listing) the available objects. But that's probably overkill and not needed (as it's not for a general purpose programming language). Anyway, good luck optimizing things to squeeze functionality into the interpreter COG. Perhaps the conditional testing options available for each PASM statement could save a long here and there, even though you're no doubt already using that technique quite a bit. And maybe the same variable (memory location) can be used for multiple things at different times (if the times that such variables are used don't overlap and state doesn't need to be maintained between such uses). Might not be pretty from a coding standpoint, but might free a long or two. There's probably other "tips and tricks" like that which might be candidates for saving memory. In tight (memory) times, one has to think outside the box (though I'm not saying to go to the HUB necessarily). For example, you can reuse initialization variables for other things. Those people that are good at writing video drivers here tend to know how to squeeze every ounce out of each PASM statement.
I'm afraid my PASM programming is not incredibly clever. I mostly just write the most straight forward code to implement something. However, I did squeeze enough space to let me add two of the three instructions I need for exception handling. Now I just have to find space for the last one.
That's great. Where there's a will, there's a way. By the way, straightforward code is usually preferred, but there are times that things must be tweaked for the sake of memory or performance. For example, over in SPIN land, I sometimes prefer to write a := a + b, as I find it more readable, but a += b saves memory (at least on the PropTool) and likely runs a tad bit faster. Anyway, onwards and upwards.
I just got my simple game working on the Propeller. It's only a single player game so far and it is really nothing more than a few rooms you can navigate by typing 'n', 's', 'e', 'w' but it's a start. Here is the game and the game runtime code. This is just in time for me to try it on my console which is supposed to arrive tomorrow.
Game:
var initialLocation = livingroom;
include "game.adi";
location storage_room {
description: "You are in the storage room.";
west: hallway;
}
location hallway {
description: "You are in the hallway.";
east: storage_room;
north: kitchen;
south: livingroom;
}
location kitchen {
description: "You are in the kitchen.";
south: hallway;
west: pantry;
}
location pantry {
description: "You are in the pantry.";
east: kitchen;
}
location livingroom {
description: "You are in the livingroom.";
north: hallway;
west: closet;
south: outside;
}
location closet {
description: "You are in the closet.";
east: livingroom;
}
location outside {
description: "You are outside.";
north: livingroom;
}
Game runtime:
object location {
}
property north, south, east, west;
property description;
def getp(obj, prop)
{
var value;
try {
value = obj.(prop);
}
catch (e) {
value = 0;
}
return value;
}
def getc()
{
asm {
TRAP 0
RETURN
}
}
def main()
{
var loc = initialLocation;
var newloc, ch;
print #loc.description;
while (1) {
if ((ch = getc()) != '\n') {
if (ch == 'n')
newloc = getp(loc, north);
else if (ch == 's')
newloc = getp(loc, south);
else if (ch == 'e')
newloc = getp(loc, east);
else if (ch == 'w')
newloc = getp(loc, west);
else if (ch == 'q')
break;
else
newloc = -1;
if (newloc == -1)
print "Huh?";
else if (newloc == 0)
print "You can't go that way.";
else if (newloc != loc) {
loc = newloc;
print #loc.description;
}
}
}
}
That's great, David. Good luck in getting your code to run on it, but from the looks of things so far (your rapid progress), I don't think you'll need it.
Great! Of course, the time reverted back to midnight of January 1st, 2000 since I couldn't ship the small lithium battery with the real-time clock module (they actually ask about batteries at the Post Office and I answered honestly). But a prototype I've got running here has been within a second of the correct time for many months (perhaps just luck). Anyway, thanks for firing it up and reporting back. I'm glad that it arrived safe-and-sound, apparently no worse for wear from all its travels. That was a fast trip, though: about four days.
Yes, I was assuming that your adventure games would be created in another environment. I was just trying to get at your cog allocation if running such games on the console. As for Tachyon and Chip's desire for a self-hosted system, that's all great. But when it comes to the game console, I'd rather develop word games in SPIN on my PC than on one of the 7" screens of the console. The 7" screens are possibly the perfect size for playing such games, but on the smallish side for development. However, I can see adding game content being a possibility on the console (since it's usually just text), but I'd probably prefer to have Google and the full internet, a spell checker and so on at the ready, which a PC provides.
Seems like a cool project, well done.
As for Tachyon, while it the whole compiler/interpreter/debugger environment is on the Prop, you still do your source code editing on the PC and communicate via a serial terminal. The difference from Spin is Tachyon ends up more compact and faster but most importantly it is interactive. So you can make or take one small section of your program and interact with it. Once you figure that one out you can add another section in a similar manner. As you do this you see your program or game come together. In my simple VGA BREAKOUT game I did this, first drawing a brick and then coloring it and then creating a wall from bricks and then layers of walls, then a ball that bounced around etc. Any and all components are accessible by name and so you use the language/environment itself to debug and develop, usually finding better solutions as you build it up incrementally.
Thanks for the clarification, Peter. That's a highly dynamic/interactive environment you've got there, to say the least. Guess that's the point, or one of them. Looking forward to seeing that built in to the P2, too. The Breakout example would seem to illustrate the advantages of the interactive workflow nicely (speaking as one who hasn't received the force..eh..forth yet).
Speaking of Breakout, I would guess that a four-player version of it could be done on the WF game console, wherein four differently-colored balls could be active at the same time, though a player could only hit his or her own ball. Perhaps the bricks would disappear only after every active player had hit the brick, or something like that (need to think about it). Well, that'd probably force people to work as a team, though that might be okay. Instead, perhaps there could be different colored bricks on the screen for the different players, and a player would win when all the bricks in his or her color were cleared. Guess players would be allowed to blast other players' bricks by accident (or intentionally), though that seemingly wouldn't help them win. Anyway, although the tile-mapped video driver uses text, the first 32 font characters are easily redefined, which could allow for finer/smoother animation of the balls, though there'd be a problem when differently colored balls crossed each other's paths. Yikes! Never mind. I'm just thinking off the cuff here. Guess the balls would have to be the same color when crossing, or perhaps they'd have to annihilate one another like an electron-positron pair if crossing. Alternatively, one could write a different video driver that used bit-mapped graphics, making everything easier, but such a driver would have to work for four screens or allow for four instances of it (and the hsync and vsync signals would have to be shared). Well, I didn't think this post through (and the idea is not ready for prime time), but I'll post it anyway just to stimulate folks' creative juices. Maybe I should offer a console for dirt cheap to a person willing to undertake a decent multi-player, old-school video game on it. Hey, text games are the focus, but a little video game diversion shouldn't hurt. Quad Pac-Man anyone?
Thanks, Mike. PM reply sent. As for Spin, I like working in it for games. And you wouldn't really have to touch PASM unless you wanted to do your own driver(s), such as a different video driver.
Oh, my comments where just there to tease Peter J. the master of Tachyon.
I really like this guy, he is immensely helpful and knowledgeable and does wonders on a P1 chip with his software.
Your post about a 4-player breakout sounds like a dream to do in Spin, but if Peter is bored he might write this in a afternoon. Just to show off that he can do it with 345 longs of Tachyon byte code.
My plans are more simple, a text display will do perfectly.
Yes, I was assuming that your adventure games would be created in another environment. I was just trying to get at your cog allocation if running such games on the console. As for Tachyon and Chip's desire for a self-hosted system, that's all great. But when it comes to the game console, I'd rather develop word games in SPIN on my PC than on one of the 7" screens of the console. The 7" screens are possibly the perfect size for playing such games, but on the smallish side for development. However, I can see adding game content being a possibility on the console (since it's usually just text), but I'd probably prefer to have Google and the full internet, a spell checker and so on at the ready, which a PC provides.
Seems like a cool project, well done.
As for Tachyon, while it the whole compiler/interpreter/debugger environment is on the Prop, you still do your source code editing on the PC and communicate via a serial terminal. The difference from Spin is Tachyon ends up more compact and faster but most importantly it is interactive. So you can make or take one small section of your program and interact with it. Once you figure that one out you can add another section in a similar manner. As you do this you see your program or game come together. In my simple VGA BREAKOUT game I did this, first drawing a brick and then coloring it and then creating a wall from bricks and then layers of walls, then a ball that bounced around etc. Any and all components are accessible by name and so you use the language/environment itself to debug and develop, usually finding better solutions as you build it up incrementally.
I admire the interactive nature of Tachyon. I have to admit that I've tried a number of times to create a simple infix language that runs directly on the Propeller but have so far failed. It's hard to compete with what you've done with Tachyon. It's really an amazing piece of work and it would probably be ideal for this game platform.
I just got my simple adventure game running on one of the WordFire screens. Now I just have to figure out how to use all four screens at the same time!
Comments
https://web.archive.org/web/20020806222552/http://www.unantes.univ-nantes.fr:80/~brebion/16kentry.htm
http://www.andreasen.org/16k.shtml
def getp(obj, prop) { var value; try { value = obj.(prop); } catch (e) { value = 0; } return value; }Game:
var initialLocation = livingroom; include "game.adi"; location storage_room { description: "You are in the storage room."; west: hallway; } location hallway { description: "You are in the hallway."; east: storage_room; north: kitchen; south: livingroom; } location kitchen { description: "You are in the kitchen."; south: hallway; west: pantry; } location pantry { description: "You are in the pantry."; east: kitchen; } location livingroom { description: "You are in the livingroom."; north: hallway; west: closet; south: outside; } location closet { description: "You are in the closet."; east: livingroom; } location outside { description: "You are outside."; north: livingroom; }Game runtime:
object location { } property north, south, east, west; property description; def getp(obj, prop) { var value; try { value = obj.(prop); } catch (e) { value = 0; } return value; } def getc() { asm { TRAP 0 RETURN } } def main() { var loc = initialLocation; var newloc, ch; print #loc.description; while (1) { if ((ch = getc()) != '\n') { if (ch == 'n') newloc = getp(loc, north); else if (ch == 's') newloc = getp(loc, south); else if (ch == 'e') newloc = getp(loc, east); else if (ch == 'w') newloc = getp(loc, west); else if (ch == 'q') break; else newloc = -1; if (newloc == -1) print "Huh?"; else if (newloc == 0) print "You can't go that way."; else if (newloc != loc) { loc = newloc; print #loc.description; } } } }Seems like a cool project, well done.
As for Tachyon, while it the whole compiler/interpreter/debugger environment is on the Prop, you still do your source code editing on the PC and communicate via a serial terminal. The difference from Spin is Tachyon ends up more compact and faster but most importantly it is interactive. So you can make or take one small section of your program and interact with it. Once you figure that one out you can add another section in a similar manner. As you do this you see your program or game come together. In my simple VGA BREAKOUT game I did this, first drawing a brick and then coloring it and then creating a wall from bricks and then layers of walls, then a ball that bounced around etc. Any and all components are accessible by name and so you use the language/environment itself to debug and develop, usually finding better solutions as you build it up incrementally.
Speaking of Breakout, I would guess that a four-player version of it could be done on the WF game console, wherein four differently-colored balls could be active at the same time, though a player could only hit his or her own ball. Perhaps the bricks would disappear only after every active player had hit the brick, or something like that (need to think about it). Well, that'd probably force people to work as a team, though that might be okay. Instead, perhaps there could be different colored bricks on the screen for the different players, and a player would win when all the bricks in his or her color were cleared. Guess players would be allowed to blast other players' bricks by accident (or intentionally), though that seemingly wouldn't help them win. Anyway, although the tile-mapped video driver uses text, the first 32 font characters are easily redefined, which could allow for finer/smoother animation of the balls, though there'd be a problem when differently colored balls crossed each other's paths. Yikes! Never mind. I'm just thinking off the cuff here. Guess the balls would have to be the same color when crossing, or perhaps they'd have to annihilate one another like an electron-positron pair if crossing. Alternatively, one could write a different video driver that used bit-mapped graphics, making everything easier, but such a driver would have to work for four screens or allow for four instances of it (and the hsync and vsync signals would have to be shared). Well, I didn't think this post through (and the idea is not ready for prime time), but I'll post it anyway just to stimulate folks' creative juices. Maybe I should offer a console for dirt cheap to a person willing to undertake a decent multi-player, old-school video game on it. Hey, text games are the focus, but a little video game diversion shouldn't hurt. Quad Pac-Man anyone?
Sadly I have a hard time getting used to read or even write source for it.
Might be interesting to try. I just PM'd you, if you still have one, I would like one of your WF consoles.
But I will most likely use Spin/PASM, I feel more comfortable there.
I really like the idea of having 4 players together at one place.
Enjoy!
Mike
I really like this guy, he is immensely helpful and knowledgeable and does wonders on a P1 chip with his software.
Your post about a 4-player breakout sounds like a dream to do in Spin, but if Peter is bored he might write this in a afternoon. Just to show off that he can do it with 345 longs of Tachyon byte code.
My plans are more simple, a text display will do perfectly.
Enjoy!
Mike