Re: MSX game: an idea
On Wed, 9 Dec 1998 [EMAIL PROTECTED] wrote: > >Sending the complete map? Not necessary! > > No, just the data of the robots. Which raises the question which data > a robot should have and which are sent to the other robots: > Public: > - Position(of course) > - alive sign (so other robots will know whether a robot is still in play) What also should be sent is the action performed on sqares (attack and drop), since the other robots have to react to it. If communication is possible, I would think it better to give it a maximum length, so the network doesn't get too slow. > Private: > - Energy > > Or would it be more fun if all robots would know about each others > energy level (I see complete hordes of robots turning against the > weakest :-)) What I would like is having separate energie for: - shield - attack - move And one main energie type, which can be transferred to (not from) those types. To make this work, it will be useful that transferred energie cannot be used in the same turn as it was transferred. Otherwise, everybody would just have all his/her energie as shield at the end of every turn, which would make the separation useless. > >Do you want the program to be the only parameter for the robot, or are there > >other settings as well? For example, it could be an option to make a robot > >that receives more damage from attacks, but in return it would move faster. > > That hasn't been discussed, yet. But we assumed each robot could only move > one square (4-neighbourhood) per turn, so an agility/dexterity trade-off > is not possible. It could however be possible to divide the available power > between defence (shield, whatever) and attack power. With energie separation as stated above, this would make it part of the program. I think it would make the programming too complex if you have to choose the hardware as well. I think we all agree on it that the language should be as simple as possible. > >About the map: is every square (I assume it uses squares, not hexes or > >something else) accessible? Or are some squares blocked (obstacles)? > > Squares are fine :-) > I'd say that all squares are accessible. What do we do, however with > dead robots? Are they removed from the field or will they stay as obstacles? I'd like them to stay, but if anybody has good arguments for removing them, it's fine with me. I think it would be nice if in a scan, you can't see if a robot is alive or not. > >When a robot scans the environment, does it get info like "enemy at (-2,-3), > >friend at (1,-1)" or does it know which enemies and friends are nearby: > >"enemy type 1 at (-2,-3), friend type 3 at (1,-1)"? > > Not discussed, yet :-) > I proposed an inaccurate long range scanner, giving information about a certain > part of the playing field, which only delivers the number of robots, energy > packets etc. Shevek and I worked up a short range scanner, which gives > detailed information about a small environment surrounding the robot. I'd say that with short range scanning (looking) you can see also the ID-number of the robot and its communication at channel "local". > Team play has not been discussed at all (apart from mentioning it w.r.t. > the energy packets), so all other robots are of type enemy :-) I agree. > > Maybe a robot can even identify individual enemies and friends, to remember > >"I damaged that one pretty seriously last time I saw it, so now I'll finish > >him off". > > IMHO that should be left to the robot programmer - the programming language > for the robots should have the means to do things like that, of course... This would be possible with the scan mentioned above. > >When using multiple robots in a team, can they communicate? Cooperation would > >be much more diverse if communication is allowed. And if they can communicate, > >are they allowed to send as much info as they want per turn, or only a limited > >amount? > > I think that team play would be very hard if no communication can take > place between the robots of the same party. But, as already stated, team > play has not been discussed yet. IMHO team playing makes the whole thing > very complex, and simplicity should be the thing to strive for. The more > complex we define the possible behaviour, the complexer our programming > language will become. That will definitely have an impact on the code size > of the robot programs _and_ on the code size of the compiler/parser. There should be a maximum size, if only for the coder of the robot-language, so he knows the size he must reserve for this purpose. But how much? For communication, I suggest the following method: Every robot can send signals at certain channels: -local:only readible for robots that can see the robot. Costs no energie -group:readible for every robot of a certain group (It does not have to be it's own group) Should cost energie (How much?) -all:readible for everyone. should cost energie (how much?) I think it would be good if the robots cannot see w
Re: MSX game: an idea
Hi all you MSX freaks! Stefano Fronteddu <[EMAIL PROTECTED]> launched this idea: > I was thinking to develop a battle game: blah, what the news !!! No > this was my idea: > > I intended to develop a program that was able to read 2 files. > These files were the source code to control the action of a > simulated 'robot'. > > I must be more clear > > The game screen is a grid of established dimension. > Each cells can contain one of these objects (randomized > positioning): > > NULL > Enemy's robot > pyramid (Marco Casali will apreciate this) > cobweb > mine > > Pyramids are the place where robots can find new weapons (laser, > shield, mines, ...). If a robot goes in a cell where there is a > cobweb is blocked for 2 turns. If a robot goes in a cell with a mine > it takes 3 damnages. > > (etc.) I love it! These kinds of simulations are one of the things I love to run on my computer, when I run into these. This immediately made me think of Conway's game of Life (I think you will know this). Your idea seems like a similar 'recipe' for such a simulation. I did wonder about this: did you cook this up yourself, or is it something you found elsewhere (and maybe modified it a bit)? If so, can you please tell us where you found this, who figured out the original concept of this? I'm not going to program this I think, but if anyone else does, I volunteer as a beta-tester, to see how to make it a more interesting simulation! This made me remember several similar things, for anyone who's going to use this idea: I saw on TV once a simulation, where 2 robots where put against each other in a simple 'arena' (a square playingfield), with only 1 goal: to get a 'prize' (a simple ball, initially placed in the middle), and take it home (to some corner, or back to their own starting position). At the start, these 2 robots would ofcourse have equal chances, by putting them on opposite sides, but equal distance from the prize. These 2 robots had certain characteristics, like speed, weight, endurance, and (important) a certain shape. The simulation would modify these parameters slightly each for one, or both robots (in a different way), and run a number of simulations, to see what set of characteristics would show to be the most succesfull one. By trying this back and forth with the robots used in previous simulations, you could watch an entire 'evolution' evolving in the shapes and other characteristics of these robots. I guess it was done this way, that changing a single parameter would either be non-related to others (like the program controlling the behaviour of the robots), or have its effect on other parameters: if an 'arm' was made longer, the weight would increase, making it slower, or taking more effort to move, and thus giving it less endurance. Or making it move faster, but with less accuracy, etc. etc. You would see robots 'growing' longer arms, to be able to reach the prize before the other one did. One might see opponents of such a robot 'respond' by getting smaller, but faster, in order to grab the prize first, and make a run for it. Or some might get an extra large body, to be able to put themselves between the prize and the other robot, to prevent this other one from grabbing it back from them, etc. Fun to watch! Another related idea is this: In a simulated 'computer', the 'lifeforms' consist of pieces of program code, written in a simple code (like for a stripped Z80), and given small amounts of CPU-time one by one (I'm not sure how exactly). Purpose for each 'liveform' was to survive, that is, to keep a copy of itself somewhere in the simulated CPU memory (like a computer virus), and maybe have many 'children' (copies in other places in this memory). At the start, a number of simple liveforms would be put in here (or the memory filled with random data), and to make it more interesting, this memory would have random bit changes from time to time (call it 'mutations', or 'radiation effects'). You would see simple liveforms, that would simply copy itself to a bit futher on in memory, to get a copy, and thus survive, when another program/liveform would erase their initial one. After a while, more sophisticated methods would be seen: a program might use parts of other liveforms to copy themselves (by calling, or copying these), to save program size of their own, and thus allow to copy themselves quicker than others (shorter program = less CPU cycles needed to copy the thing). And ofcourse you would get a separation in different techniques used: some liveforms might stay small and simple, to be able to copy themselves more quickly, and survive by numbers. Others might grow more sophisticated instead, to prevent being erased, or actively hunt down/erase others. An idea I had myself once, was to run a simulation of an ant heap (or several), in a simulated environment. Scientists have always wondered, how it is possible that such
Re: MSX game: an idea
On Mon, 7 Dec 1998, Ricardo Jurczyk Pinheiro wrote: > At 12:19 06/12/98 +0100, you wrote: > > I think you're forgetting the latency problem. Explaining: All the > MSXes would be connected by the joystick port, right? So, if you've 16 MSX > connected, the first MSX would be connected to the second, the second to the > third... And finally, the sixteenth to the first, so we'll have a 16-MSX ring. > > Suppose you want to send some signals from the fourth to the > twientieth computer. So, your packages would be sent through eight > computers, and you'll spend time sending this file, maybe some seconds. > Sending a file through a LAN is a matter of time: The faster, the better. > Into a game, it's a life-and-death problem: Just imagine that you lose a > game 'cause of network lag. Generally speaking, you are right. In this game, it is not the point, though, since it works in turns. computer 1 never wants to send a package to computer 4. It only sends the complete playing area to computer 2 and gets it from computer 16. Therefor, in this case, a ring would be the perfect architecture. > So, does anyone has thought about a... switch, like the Ethernet > switches, mostly common into Beowulf supercomputers, to be used into our > networked MSXes? I don't think it would be pretty difficult to be done. Not difficult, perhaps, but how many people do you think will buy one? If you want a networking standard that is actually used, it need to be REALLY low-cost. Personally, I wouldn't buy a switch if it would be more expensive than say 3 english pounds (and I'm sure you can't make it for that money)... > And about the game: I don't think 256 computers connected would be a > great idea... Huge amount of packages running over the LAN, it would be a > great mess. I agree. It was just to make clear that the number of robots will not be one of the limitations. > ByE! > Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Can someone forward me the original message about this game-idea? I have missed it due to modem-problems etc. but I'd like to read it so that I know what u are talking about. ~Grauw MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Hi all, i think that a similar version of the game you are talking about is called CROBOTS and you can find some info at: http://www.ingenia.com/~nfraser/crobots/index.html The robots are a little c-like program with some special istruction to move, shot, etc. Here in italy an important computer magazine (MCmicrocomputer - www.mclink.it) set up a tournamente every year. CIAO !!! Maurizio x Morandi a.k.a MxM Softworks on Msx $ IN MSX WE TRUST $ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
] I gave the above ideas, and I know of implementations of Conway's ] Live game for MSX (one called 'bosbrand', by the MCCM, and another ] one written by myself once). But are there more versions of this Live ] simulation, or other simulations like it, written for MSX? I implemented conways live once. And distributed it via the dragon disk from msx engine. It was rather fast, something like 10 generations per second on screen 0 in 80 column mode. Now that I think of it again, I could as well upload it to funet. I think I will do that somewhere next week. Kind regards, Alex Wulms -- Alex Wulms/XelaSoft - MSX of anders NIX - Linux 4 ever See my homepage for info on the *** XSA *** format http://www.inter.nl.net/users/A.P.Wulms MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
> I love it Thanks a lot ! > This immediately made me think of Conway's game of Life (I think you > will know this). Yes I know it > Your idea seems like a similar 'recipe' for such a simulation. I did > wonder about this: did you cook this up yourself, or is it something > you found elsewhere (and maybe modified it a bit)? If so, can you > please tell us where you found this, who figured out the original > concept of this? I 'cook this up' myself, a lot of time ago, when nobody was thinking about simulation on home computer ... ;-) > I'm not going to program this I think, but if anyone else does, I > volunteer as a beta-tester, to see how to make it a more interesting > simulation! I'm sorry for this, but good to know that there will be at least one beta tester ! Bye, Stefano Fronteddu MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[RobotZ] > I'll think about the actions myself as well. I hope more people will, so > we will get a game that a lot of people will like. Ok, here's an idea: Every robot is allowed to calculate as much as it wants. It's turn is over when it performs any of the following actions: -move (1 step). -scan -pass (so you don't have to do something which would cost energie) -attack -drop Attack is to use part of your energie on a square next to you. If there is a robot there, it will be damaged according to the amount of energie given. Drop is to drop an energie-packet, so smeone else can pick it up. Only useful when playing in teams. Moving and scanning should cost energie as well. Looking is also possible (only short-range), but I don't think it should cost you a turn. Tell me what you think about it. What do you think should be the maximum scanning range? Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re[2]: MSX game: an idea
>> PS. I've had a look at the CRobots homepage(lost the URL unfortunately). >> Looks pretty much like what we're trying to make here... >Eh, ok. Is that a problem? Nope. In the contrary. It could be interesting to grab some ideas from it. > It is for pc, right? Yep. The robot programs are in some C like language - if we could just port the compiler for that language to MSX, we're already halfway there. Then we don't need to specify all behaviour things ourselves. We'd just have to define the data protocol for Joynet, build a (G)UI and presto. Disadvantage: less fun :-)) Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
On Tue, 8 Dec 1998 [EMAIL PROTECTED] wrote: > [step] > >IMO, the nicest would be a 4-neighbourhood for moving, attacking and dropping > >energie and a 12-neighbourhood for looking (I'll explain further on). Tell me > >if you don't agree. > > >I was thinking of one large energie-supply, since I didn't put shields in it > >anyway, but perhaps this should be different. What's your opinion? > > Well, ok, "shield" may have been not the correct word, but I think a robot > should be able to sustain a certain amount of damage, related to its energy > supply, before it is brought down by an attack. That is right. I didn't think of it as a different thing, but it could be. I think that would be nice. > looking & scanning] > >> Ok, that could be equal to my proposal for the short range scan, while the > >> long range scan will cost you turn... > >Indeed, only I think you should be able to look at least one square further > >than you can walk (12-neighbourhood): > Hm, the argument in favour of the 12-neighbourhood (scan/look one step > further than you can move) is ok, but I'm not very enthousiastic about > the 12-nbh: it just doesn't look that good :-) I'd propose a 24-nbh > (square) or a 20-nbh (more or less circular): I agree. I prefer the 20-nbh, since it feels more natural to have a circular range. > PS. I've had a look at the CRobots homepage(lost the URL unfortunately). > Looks pretty much like what we're trying to make here... Eh, ok. Is that a problem? It is for pc, right? Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
> [RobotZ] > > Looks like fun! I'd love to implement it, but I'm already having a hard > time finding any spare time :-( However: if anyone wants to make it and > needs help programming e.g the parser for the robot's programming > language, just yell :-) I just wanted to say, that I heard from this kind of game before. I remember that I read something about such a game in the magazine ASM (Aktueller Software Markt). This maga was published from about 1985 till 1993 I think. An somewhere in an issue between 1986-1989 I have read something about a game called "Orion" or "Omikron" or similar. I have searched, but it seems that I cannot find it anymore. This maga was dedicated to the Homecomputer-Scene (Atari, Amiga, CPC, MSX, C64...). So I think that you wouldn't find it on PC. greetz Wolfgang - just thought to have to say it - -- Chief-Gavaman Programmers' Affair - The Vampyre of MSX Empire <___ACTIVE - GROUP___>> http://www.myworld.privateweb.at/gavaman/default.html MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
At 02:41 PM 12/04/98 +, you wrote: >At the start, some fuzzywuzzy takes place to determine the size of the >ring - lets say N. Then each computer sends its own data block (to left), >reads N data blocks, (from right) and sends them all (to left) except for >the last one which is the data block sent by its left neighbour. If you program it like that, computers don't even need an ID. They only need to know the number (N) of computers in the ring. >In contrast to my idea, where each computer gets a globally known fixed ID, >you work with 'relative' id's in this method and then you can connect upto >257 comps. Clever! It's a nice from a theoretical point of view. But in practice it's more efficient to add another bit in the transmission, doubling the number of possible computers. >Anyway, I think that a competition of 256 or 257 robots will be very close >to impossible to play. You'd have to have a *huge* playing field to make >it a bit interesting, which has to be updated and kept consistent over all >connected computers... There is a simple way of doing that: make the gameplay deterministic. This means that there is never a choice with a random factor in it. So if all computers start with the same field and process the same movements, their fields will always be consistent. You may say "no random factors will make a game boring, because two programs will always play the same battle". But remember that random numbers in computers are not really random. Usually sequences are used that look like random numbers. Such sequences are initialised with a "random seed". That seed is chosen using some more-or-less random properties (for example, system time). This means that is the same random seed is distributed to all computers running the robot wars program, they all play the same game. But if the game is started again, the game they will play a new game. >>It might even be possible to encode it, so that you can't read the source to >>see how to beat it, but that would be quite hard. If the algorithm is somewhat complicated, just looking at the source code won't tell you how to beat it. >That's why leaving the programming language open to the programmer is so >good. Disassembling compiled TurboPascal or MSX-C code is quite hard... How do we prevent programs in such a language from cheating? It would be quite simple for a program to inspect the entire map, to it can look beyond its sensor range. Also, a specific robot programming language may be easier for beginning programmers. Not everyone knows how to code Pascal or C. Yet another advantage would be that the robot wars program can be made for other systems as MSX as well. Maybe you disagree about this being an advantage, but I'd like to see for example a Java version that can be played over the web. >To your Q: You can't if you don't use a special purpose robot programming >language. But with a well defined set of playing rules you can limit the >possibility of cheating. A well defined set of rules only makes sure people don't cheat legally. If they intend to break the rules, it doesn't matter how well defined those rules are. The advantage you named of using a general purpose language is at the same time a disadvantage: it's hard to disassemble, so you can't check easily if a program cheats or not. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[RobotZ] >Ok, here's an idea: >Every robot is allowed to calculate as much as it wants. It's turn is over >when it performs any of the following actions: >-move (1 step). And how is "one step" defined? As only north, south, east and west (4-neighbourhood)or also north-east, north-west, south-east and south-west (8-neighbourhood)? >-scan In your earlier idea, you mentioned two types of scan, a inaccurate long range scanner and a precise short range. Is this the long or the short version? What can be scanned? What is the result delivered by the scan? I was thinking of having a short range scan which reaches out 2 cells away in a 8-neighbourhood (covering a 5x5 square with the robot in the middle) giving an exact map, and a long range scan which must be performed in a certain direction (to be passed as parameter) which only gives the number of enemy robots, enery supplies, etc. in that direction up to the borders of the playing field. E.g a long range scan could be possible in north-east direction: | | | |X+++ + (X = robot, + = squares scanned) or in south direction: /X\ /+++\ /+\ /+++\ >-pass (so you don't have to do something which would cost energie) Ok >-attack Which raises the question: do we have one large enery supply from which attacks, shield and propulsion are supplied, or do we separate those? (which could leave a robot immovable, but still able to attack...) >-drop Ok >Attack is to use part of your energie on a square next to you. >If there is a robot there, it will be damaged according to the amount >of energie given. Again, what's "next to"? 4-neighbourhood or 8-neighbourhood? >Drop is to drop an energie-packet, so smeone else can pick it up. Only useful >when playing in teams. Ok. > Moving and scanning should cost energie as well. Agreed >Looking is also possible (only short-range), but I don't think it should cost >you a turn. Ok, that could be equal to my proposal for the short range scan, while the long range scan will cost you turn... Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
On Thu, 3 Dec 1998 [EMAIL PROTECTED] wrote: > [RobotZ] > > >Great idea! I could make it, I guess, but I can't say when it will be > >finished, since I don't have so much spare time. > > > But please, send me exact > >specifications on what the condition of an if-statement can be, and how the > >radar can be used (or am I now asking just one question). Anyway, I think it > >would be easy to make it hecto-multi-player (257 players at most, > >simultaneously), by making use of joynet. > > 257? How did you cook up _that_ number? 255 or 256 or even 65536 :-) are > numbers I could imagine, but 257? All robots need a number and it should be not too many bits when communicating. Therefore, you can have 256 external robots plus one for the computer itself. You don't need to send the data of the robot that's listening. It knows what it sent... > > I'm coding something at the moment > >so that implementing that will be easy. Anyway, were you planning to make the > >enemy-robots computercontrolled or humancontrolled? Human would be more fun, > >of course, but you can't always find a second player... > > So what? Can't you write two robot-programs? :-) Hehe... It will be boring after a while. If you make the possibility to play against the computer (not using joynet), you could also spread robot-programs. It might even be possible to encode it, so that you can't read the source to see how to beat it, but that would be quite hard. > Another thing crossed my mind: Why develop a special programming language > for the robot? The only reason for that could be that it's the only way > to get more 'programs' running in parallel on _one_ MSX. But: if we take > the game to JoyNet, as Shevek proposed, we only have to define the > rules of the game (e.g. how the long and short range radar function, > what happens if two robots want to get on the same playing field position) > and the interface (how does each player receive / send its move). > Then everyone can use his favorite programming language, and program his robot > in the way (s)he likes. It saves us the definition and implementation of a new > programming language and makes a killer app on JoyNet! It is possible, of course, but how do you check if a language does not cheat? Anyway, when I finish the game, I'll make the communication protocol public, so everybody is free to make his/her own language. In a contest you could demand the use of a certain one. > > Would make a heck of a competition game at a fair (wow!)... Indeed. > > Eric > Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
R: MSX game: an idea
>Can someone forward me the original message about this game-idea? The original idea has evolved in the meanwhile, but this is my original message: >Hi MSX people ! > I'm writing to all of You to explain an idea I had a lot of time ago. >I was thinking to develop a battle game: blah, what the news !!! >No this was my idea: > >I intended to develop a program that was able to read 2 files. >These files were the source code to control the action of a simulated >'robot'. > >I must be more clear > >The game screen is a grid of established dimension. >Each cells can contain one of these objects (randomized positioning): > >NULL >Enemy's robot >pyramid (Marco Casali will apreciate this) >cobweb >mine > >Pyramids are the place where robots can find new weapons (laser, shield, >mines, ...). >If a robot goes in a cell where there is a cobweb is blocked for 2 turns. >If a robot goes in a cell with a mine it takes 3 damnages. > >Each robot has 10 points of life. > >The files that the program loads are the code that each robot execute. >In the program we can find the following instruction : > >UP| >DOWN |__\ No more than 3 equal istruction for >LEFT | / each program >RIGHT | >USE >GOTO >IF (condition) GOTO (point of program) ELSE (point of program) > >Each robot is equipped with a sonar and a radar. >Sonar is good for distance less than 3 cells (it' precise). >Radar is good for distance less than 7 cells but with a dubtful measurement. >Each robot execute an istruction of the code than pass the move to the >opponent. > >The target of the game is to write the best program able to kill all the >other enemy written by other people. > >This is the idea. I left it in a drawer for long time, also because it's a >game that is fun if there is a lot of people involved. >Now I'm asking to all of You if there's someone interested in developing it >... >No great graphic, no wonderful sound, only a good engine to test the ability >and the intelligence of each one. > >Let me know Your opinions. By Fronteddu Stefano >I have missed it due to modem-problems etc. but I'd like to read it so that >I know what u are talking about. > > >~Grauw Bye bye, Stefano Fronteddu --- Fronteddu Stefano Student in Software Engineering [EMAIL PROTECTED] [EMAIL PROTECTED] http://space.tin.it/computer/stfront MSX, Sardinia, Robotics, Friends http://computer.digiland.it/1461 MSX Soft Tips Page Member of Miri Software - Italy http://Frengo.dragonfire.net/MSX.HTM ICQ: 21401454 0338/3645458 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
At 12:19 06/12/98 +0100, you wrote: >> [257 RobotZ] >> >Sorry for not being clear, but you got it right in the end ;-) > >> Anyway, I think that a competition of 256 or 257 robots will be very close >> to impossible to play. You'd have to have a *huge* playing field to make >> it a bit interesting, which has to be updated and kept consistent over all >> connected computers... >It sounds like you want every computer to calculate the position of every >robot. The way I see it, every computer keeps the program of 1 robot (or >more, if you're multitasking, which I am planning to include) and not that >of the others. Only the other's coordinates are sent through the net. As >someone stated before, you don't need to send any id, indeed. I think you're forgetting the latency problem. Explaining: All the MSXes would be connected by the joystick port, right? So, if you've 16 MSX connected, the first MSX would be connected to the second, the second to the third... And finally, the sixteenth to the first, so we'll have a 16-MSX ring. Suppose you want to send some signals from the fourth to the twientieth computer. So, your packages would be sent through eight computers, and you'll spend time sending this file, maybe some seconds. Sending a file through a LAN is a matter of time: The faster, the better. Into a game, it's a life-and-death problem: Just imagine that you lose a game 'cause of network lag. So, does anyone has thought about a... switch, like the Ethernet switches, mostly common into Beowulf supercomputers, to be used into our networked MSXes? I don't think it would be pretty difficult to be done. And about the game: I don't think 256 computers connected would be a great idea... Huge amount of packages running over the LAN, it would be a great mess. ByE! _ __ | __ \ (_| ICQ UIN: 3635907 | | M. Sc. In Numerical Modelling - UFF | |__) | _ __ _ _ __ __| | ___ Niteroi - RJ - BR +-+ | _ / | |/ __// _` | '__/ _` |/ _ \ | Sola Scriptura | | | \ \ | | (__| (_| | | | (_| | (_) | | Sola Gratia | |_| \_\|_|\___\\__,_|_| \__,_|\___/ Jurczyk Pinheiro |Sola Fide| http://pagina.de/rjp - [EMAIL PROTECTED] - [EMAIL PROTECTED] | Solo Christi | MSX freak, X-Phile, Trekker, Christian, Transformers, | Soli Deo Gloria | Anime (Yamato!), CuD, Gospel Rock, Comics, And hate M$! +-+ MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Hi! >Suppose you want to send some signals from the fourth to the >twientieth computer. So, your packages would be sent through eight >computers, and you'll spend time sending this file, maybe some seconds. >Sending a file through a LAN is a matter of time: The faster, the better. >Into a game, it's a life-and-death problem: Just imagine that you lose a >game 'cause of network lag. As far as I understood it, the robot game would be turn based. So if things get slow, the spectators might get bored, but the gameplay won't be affected. >Generally speaking, you are right. In this game, it is not the point, >though, since it works in turns. computer 1 never wants to send a package >to computer 4. It only sends the complete playing area to computer 2 and >gets it from computer 16. Therefor, in this case, a ring would be the >perfect architecture. Sending the complete map? Not necessary! Just re-read the thing I wrote about determinism... >Drop is to drop an energie-packet, so smeone else can pick it up. >Only useful when playing in teams. You could use an energy packet as a kind of "lure" to ambush another robot... Do you want the program to be the only parameter for the robot, or are there other settings as well? For example, it could be an option to make a robot that receives more damage from attacks, but in return it would move faster. About the map: is every square (I assume it uses squares, not hexes or something else) accessible? Or are some squares blocked (obstacles)? When a robot scans the environment, does it get info like "enemy at (-2,-3), friend at (1,-1)" or does it know which enemies and friends are nearby: "enemy type 1 at (-2,-3), friend type 3 at (1,-1)"? Maybe a robot can even identify individual enemies and friends, to remember "I damaged that one pretty seriously last time I saw it, so now I'll finish him off". When using multiple robots in a team, can they communicate? Cooperation would be much more diverse if communication is allowed. And if they can communicate, are they allowed to send as much info as they want per turn, or only a limited amount? How much work space does a robot get? Just for practical reasons (MSXes don't have megabytes of memory) we need a limit. But it's also more of a challenge to make a program that uses a limited amount of memory. I think the limit should be posed upon code size and variable size added together. In that way, small programs have more work space as a reward for keeping the code compact. Bye, Maarten MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
On Mon, 7 Dec 1998 [EMAIL PROTECTED] wrote: [RobotZ] > >-move (1 step). > > And how is "one step" defined? As only north, south, east and west > (4-neighbourhood)or also north-east, north-west, south-east and south-west > (8-neighbourhood)? IMO, the nicest would be a 4-neighbourhood for moving, attacking and dropping energie and a 12-neighbourhood for looking (I'll explain further on). Tell me if you don't agree. > >-scan > > In your earlier idea, you mentioned two types of scan, a inaccurate long > range scanner and a precise short range. Is this the long or the short > version? What can be scanned? What is the result delivered by the scan? The earlier idea wasn't mine, it was Stefano Fronteddu's. But it was mentioned, indeed. This would be the long range. > I was thinking of having a short range scan which reaches out 2 cells > away in a 8-neighbourhood (covering a 5x5 square with the robot in the > middle) giving an exact map, and a long range scan which must be performed > in a certain direction (to be passed as parameter) which only gives > the number of enemy robots, enery supplies, etc. in that direction up to > the borders of the playing field. Nice idea. That would be very good, I think. > >-attack > > Which raises the question: do we have one large enery supply from which > attacks, shield and propulsion are supplied, or do we separate those? > (which could leave a robot immovable, but still able to attack...) I was thinking of one large energie-supply, since I didn't put shields in it anyway, but perhaps this should be different. What's your opinion? > > Moving and scanning should cost energie as well. > > Agreed > > >Looking is also possible (only short-range), but I don't think it should cost > >you a turn. > > Ok, that could be equal to my proposal for the short range scan, while the > long range scan will cost you turn... Indeed, only I think you should be able to look at least one square further than you can walk (12-neighbourhood): _ /+\ /+++\ |++X++| \+++/ \+/ - > > Eric Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
MSX game: an idea
Hi MSX people ! I'm writing to all of You to explain an idea I had a lot of time ago. I was thinking to develop a battle game: blah, what the news !!! No this was my idea: I intended to develop a program that was able to read 2 files. These files were the source code to control the action of a simulated 'robot'. I must be more clear The game screen is a grid of established dimension. Each cells can contain one of these objects (randomized positioning): NULL Enemy's robot pyramid (Marco Casali will apreciate this) cobweb mine Pyramids are the place where robots can find new weapons (laser, shield, mines, ...). If a robot goes in a cell where there is a cobweb is blocked for 2 turns. If a robot goes in a cell with a mine it takes 3 damnages. Each robot has 10 points of life. The files that the program loads are the code that each robot execute. In the program we can find the following instruction : UP| DOWN |__\ No more than 3 equal istruction for LEFT | / each program RIGHT | USE GOTO IF (condition) GOTO (point of program) ELSE (point of program) Each robot is equipped with a sonar and a radar. Sonar is good for distance less than 3 cells (it' precise). Radar is good for distance less than 7 cells but with a dubtful measurement. Each robot execute an istruction of the code than pass the move to the opponent. The target of the game is to write the best program able to kill all the other enemy written by other people. This is the idea. I left it in a drawer for long time, also because it's a game that is fun if there is a lot of people involved. Now I'm asking to all of You if there's someone interested in developing it ... No great graphic, no wonderful sound, only a good engine to test the ability and the intelligence of each one. Let me know Your opinions. Bye bye Stefano Fronteddu --- Fronteddu Stefano [EMAIL PROTECTED] [EMAIL PROTECTED] http://space.tin.it/computer/stfront MSX, Sardinia, Robotics, Friends http://computer.digiland.it/1461 MSX Soft Tips Page ICQ: 21401454 0338/3645458 MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[step] >IMO, the nicest would be a 4-neighbourhood for moving, attacking and dropping >energie and a 12-neighbourhood for looking (I'll explain further on). Tell me >if you don't agree. [long range scan] >Nice idea. That would be very good, I think. >I was thinking of one large energie-supply, since I didn't put shields in it >anyway, but perhaps this should be different. What's your opinion? Well, ok, "shield" may have been not the correct word, but I think a robot should be able to sustain a certain amount of damage, related to its energy supply, before it is brought down by an attack. looking & scanning] >> Ok, that could be equal to my proposal for the short range scan, while the >> long range scan will cost you turn... >Indeed, only I think you should be able to look at least one square further >than you can walk (12-neighbourhood): _ /+\ /+++\ |++X++| \+++/ \+/ - Hm, the argument in favour of the 12-neighbourhood (scan/look one step further than you can move) is ok, but I'm not very enthousiastic about the 12-nbh: it just doesn't look that good :-) I'd propose a 24-nbh (square) or a 20-nbh (more or less circular): + +++ + + ++X++ ++X++ + + + +++ Eric PS. I've had a look at the CRobots homepage(lost the URL unfortunately). Looks pretty much like what we're trying to make here... MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Another day, another light: >> I think there should be only one energy supply (make life simple!) > >Simplicity is indeed a very good argument. :-) Amen :-)) > [ideas about IDs] >Oh, right. I like to have ID's. I stated before you don't need them, >but that doesn't mean you shouldn't... Ok, then hereby we declare that each robot will have an unique ID The IDs will be given at the start of the game. We already more or less agreed that having more than 256 rbots in the game would be unpractical so an ID of 1 byte should suffice, I guess... >To the scanner, all other robots are enemies. Not to the program. Ok, I C. [communication] >You don't have to use comunication. It's just useful when you're playing with >teams. I would like to have the commands, but in case of all against all, you >would not use them, of course. Hm, ok. I'll see if I can embed it in the draft for the Robotz spec. I'm putting together... >What I was talking about is a compiler which turns the robot-program into ml. >That sounds quite hard to me. Not impossible, but hard. Not too hard. I've taken some courses in building languages and compilers :-) Maybe I can put a very first draft of what I've cooked up so far on the list today, otherwise it'll have to wait till after the weekend... (Patience is Silver, Harddisk is Gold (Unknown Reality - NOP, 1993) :-) ) Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Hi, >As far as I understood it, the robot game would be turn based. So if things >get slow, the spectators might get bored, but the gameplay won't be affected. Right. >Sending the complete map? Not necessary! No, just the data of the robots. Which raises the question which data a robot should have and which are sent to the other robots: Public: - Position(of course) - alive sign (so other robots will know whether a robot is still in play) Private: - Energy Or would it be more fun if all robots would know about each others energy level (I see complete hordes of robots turning against the weakest :-)) >>Drop is to drop an energie-packet, so smeone else can pick it up. >>Only useful when playing in teams. > >You could use an energy packet as a kind of "lure" to ambush another robot... Ow, advanced tactics! Tricky :-) >Do you want the program to be the only parameter for the robot, or are there >other settings as well? For example, it could be an option to make a robot >that receives more damage from attacks, but in return it would move faster. That hasn't been discussed, yet. But we assumed each robot could only move one square (4-neighbourhood) per turn, so an agility/dexterity trade-off is not possible. It could however be possible to divide the available power between defence (shield, whatever) and attack power. >About the map: is every square (I assume it uses squares, not hexes or >something else) accessible? Or are some squares blocked (obstacles)? Squares are fine :-) I'd say that all squares are accessible. What do we do, however with dead robots? Are they removed from the field or will they stay as obstacles? >When a robot scans the environment, does it get info like "enemy at (-2,-3), >friend at (1,-1)" or does it know which enemies and friends are nearby: >"enemy type 1 at (-2,-3), friend type 3 at (1,-1)"? Not discussed, yet :-) I proposed an inaccurate long range scanner, giving information about a certain part of the playing field, which only delivers the number of robots, energy packets etc. Shevek and I worked up a short range scanner, which gives detailed information about a small environment surrounding the robot. Team play has not been discussed at all (apart from mentioning it w.r.t. the energy packets), so all other robots are of type enemy :-) > Maybe a robot can even identify individual enemies and friends, to remember >"I damaged that one pretty seriously last time I saw it, so now I'll finish >him off". IMHO that should be left to the robot programmer - the programming language for the robots should have the means to do things like that, of course... >When using multiple robots in a team, can they communicate? Cooperation would >be much more diverse if communication is allowed. And if they can communicate, >are they allowed to send as much info as they want per turn, or only a limited >amount? I think that team play would be very hard if no communication can take place between the robots of the same party. But, as already stated, team play has not been discussed yet. IMHO team playing makes the whole thing very complex, and simplicity should be the thing to strive for. The more complex we define the possible behaviour, the complexer our programming language will become. That will definitely have an impact on the code size of the robot programs _and_ on the code size of the compiler/parser. >How much work space does a robot get? Just for practical reasons (MSXes don't >have megabytes of memory) we need a limit. I would say: make it fit in 32k. That makes it easy to put the robot program in e.g. memory pages 1 and 2 ($4000 - $BFFF), have the 'robotz operating system' in page 0 an da lot of workspace for it in page 3... Another thing. How will the process of creating a robot and playing it be like? I mean, will we have one program that reads the robot source code and execute it immediately (probably after compiling it into memory) or do we separate the process of compiling the source code and running the compiled robot. (ehm... shorter: compiler+executor or interpreter or even a JIT-compiler?) I think it would be fun to have the compiler and executor separated. In that way you can create your own robot, and distribute the _compiled_ code, so others can test/play with your robot, but not hack it easily... I'll try to make some time to give a first indication of the robot machine language... Eric (Damn! How can I ever finish my own game when projects like this turn up? ;-)) MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
On Fri, 4 Dec 1998 [EMAIL PROTECTED] wrote: > [257 RobotZ] > Sorry for not being clear, but you got it right in the end ;-) > Anyway, I think that a competition of 256 or 257 robots will be very close > to impossible to play. You'd have to have a *huge* playing field to make > it a bit interesting, which has to be updated and kept consistent over all > connected computers... It sounds like you want every computer to calculate the position of every robot. The way I see it, every computer keeps the program of 1 robot (or more, if you're multitasking, which I am planning to include) and not that of the others. Only the other's coordinates are sent through the net. As someone stated before, you don't need to send any id, indeed. > >> So what? Can't you write two robot-programs? :-) > >Hehe... It will be boring after a while. If you make the possibility to play > >against the computer (not using joynet), you could also spread robot-programs. > > When robot-programs are spread you can take the program of another and your > own to play agains each other. No need to have a real 'computer' player. > Or do we have a slight different opinion of 'computer player' and are actually > saying the same? No, we do not and we are not. I was just not thinking about it at that moment. > >It might even be possible to encode it, so that you can't read the source to > >see how to beat it, but that would be quite hard. > > That's why leaving the programming language open to the programmer is so > good. Disassembling compiled TurboPascal or MSX-C code is quite hard... That is true, but it is also very hard, to make a robot in a language like that. My robot-language would only have the commands stated in the original mail. Forward, Backward, If, etc. It's not a good programming language. It's only there to make a robot move. But if you want your own operating system (in oppose to just the robot-program), you can, of course. But remember that it has to call the network and things like that. It wouldn't be something just anyone who wants to play the game can do. > On the other hand, if the source code of another program can help you to > improve your own program, you can get a real evolution of programs... Indeed, like with "real" code. But it's up to the programmer to make it public or not. That's the idea of copyright ;-) > > [idea!] > >It is possible, of course, but how do you check if a language does not > >cheat? > > A language can't cheat. Only the program (sorry for the lecture :-)) Sorry, we were misunderstanding each other. I was speaking of a language for the robot, not for the operating system. What I meant by a cheating language is a language that gives the player the possibility to break the rules. If you write your own operating system, you will be using the most cheating language there is, in this definition... > To your Q: You can't if you don't use a special purpose robot programming > language. But with a well defined set of playing rules you can limit the > possibility of cheating. If the rules are like:you cannot do more than 1 step each turn, it's easy. You could just put a referee in the chain, which checks if you are making any illegal moves. But in the original text, it is also stated that a program is not allowed to use more than three of each of the move commands. This can not only not be checked by a referee computer, it will be a meaningless rule if you don't define the language. > > Anyway, when I finish the game, I'll make the communication protocol > >public, > > Let's first try to define the _exact_ playing rules. Then it's easier to > define the communication protocol. I'll sleep on it this weekend :-) I'll propose something soon, as well. But let me start with the part that I have got already: At the start of the game, in whatever way, 1 robot starts. The game will be played in turns. Every turn a robot can do 1 action. The possible actions is what we still have to agree on. The game is finished when there is only 1 robot left. I hope nobody has a problem with this. If you think it should be different, write how you want it to be. I'll think about the actions myself as well. I hope more people will, so we will get a game that a lot of people will like. > > so everybody is free to make his/her own language. > > I think you didn't quite understand what I meant: I was talking of _using_ > a programming language to program the robot , not specifically _making_ it. > You only define the _playing rules_ and each and everyone can make a program > in any language (C, TP, asm, BASIC, COBOL) that obeys the rules and tries to > win... Indeed I didn't understand you meant that. I explained my opinion about this above. > Eric Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist
Re[2]: MSX game: an idea
Shevek: > What also should be sent is the action performed on sqares (attack and drop), > since the other robots have to react to it. Of course. When a robot has performed its action (which end its turn), it will recieve and pass on the actions/stati of the other robots until it is its turn again. And as each other robot is guaranteed to perform one and only one action during the "sleep" period, the complete playing field will at the start of the turn always be completely up-to-date... > What I would like is having separate energie for: > - shield > - attack > - move > And one main energie type, which can be transferred to (not from) those types. > To make this work, it will be useful that transferred energie cannot be used > in the same turn as it was transferred. Otherwise, everybody would just have > all his/her energie as shield at the end of every turn, which would make the > separation useless. I think there should be only one energy supply (make life simple!) from which you can take any amount to attack someone. Moving takes a constant amount of energy. The energy left at the end of a turn is used as shield during the attacks of the other robots. No need to make things complex and you always have the maximum profit of your energy supply. Remember, this is a turn-based game, so you can't attack when you need your shield (as it's not your turn at that moment) and you don't need your shield when you're attacking (as it;s your turn at that moment and others can't attack) [dead robots] > I'd like them to stay, but if anybody has good arguments for removing > them, it's fine with me. I think it would be nice if in a scan, you can't > see if a robot is alive or not. [scanning and looking] > I'd say that with short range scanning (looking) you can see also the > ID-number of the robot and its communication at channel "local". Ehm.. I thought we would have an 'anonymous' system: no IDs :-) >> Team play has not been discussed at all (apart from mentioning it w.r.t. >> the energy packets), so all other robots are of type enemy :-) > I agree. Then why do you propose a means of communication? > For communication, I suggest the following method: Every robot can send > signals at certain channels: > -local:only readible for robots that can see the robot. Costs no energie > -group:readible for every robot of a certain group (It does not have to be > it's own group) Should cost energie (How much?) > -all:readible for everyone. should cost energie (how much?) IMHO any form of communication makes the robots and the handling of them much too complex. No communication is the best. It is fine to me if robots are able to identify each other. That could be embedded in the communication that each robot sends anyway (e.g. each datablock could start with (short) name) > A compiler would be very hard, I think. What is easier is to write the sourc > and encode it before it can be executed. Which is about exactly what a compiler does :-) > This encoding should of course be extremely hard to decode... which raises > the question: how does the operating system running the robot do it? Using > a password is not a real solution, since then you can decode it if you can > play it (but isn't that always the case?) It is, which makes encrypting absolutely obsolete. There are of course always possibilities to decipher any program, just like any copy protection can be broken (lot of examples at hand...) >> I think it would be fun to have the compiler and executor separated. In that >> way you can create your own robot, and distribute the _compiled_ code, so >> others can test/play with your robot, but not hack it easily... > >Not to code easily, eighter... ?? Why? >> Eric (Damn! How can I ever finish my own game when projects >> like this turn up? ;-)) > > Time is a question of priority (I know, in dutch it sounds much better, > but it's still very true) A decent translation (english->dutch->english):-): (Having) Time is a matter of setting priorities Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[257 RobotZ] >All robots need a number and it should be not too many bits when >communicating. Agreed. One byte as ID should suffice, which makes 256 robotz... >Therefore, you can have 256 external robots plus one for the computer itself. No, 255 external IDs, plus one ID for the computer itself. When it wants to send data it has to have a means to make the others be able to identify him. >You don't need to send the data of the robot that's listening. It knows what >it sent... Ah! I C! Let me try to explain what I think that you mean. All computers are connected in a ring (Joynet basic principle number 1 :-)) Communication takes place in one direction, lets say from right to left. At the start, some fuzzywuzzy takes place to determine the size of the ring - lets say N. Then each computer sends its own data block (to left), reads N data blocks, (from right) and sends them all (to left) except for the last one which is the data block sent by its left neighbour. Then it can send it's own data block again and the next N-1 blocks recieved etc, etc... In contrast to my idea, where each computer gets a globally known fixed ID, you work with 'relative' id's in this method and then you can connect upto 257 comps. Clever! Anyway, I think that a competition of 256 or 257 robots will be very close to impossible to play. You'd have to have a *huge* playing field to make it a bit interesting, which has to be updated and kept consistent over all connected computers... >> So what? Can't you write two robot-programs? :-) >Hehe... It will be boring after a while. If you make the possibility to play >against the computer (not using joynet), you could also spread robot-programs. When robot-programs are spread you can take the program of another and your own to play agains each other. No need to have a real 'computer' player. Or do we have a slight different opinion of 'computer player' and are actually saying the same? >It might even be possible to encode it, so that you can't read the source to >see how to beat it, but that would be quite hard. That's why leaving the programming language open to the programmer is so good. Disassembling compiled TurboPascal or MSX-C code is quite hard... On the other hand, if the source code of another program can help you to improve your own program, you can get a real evolution of programs... > [idea!] >It is possible, of course, but how do you check if a language does not >cheat? A language can't cheat. Only the program (sorry for the lecture :-)) To your Q: You can't if you don't use a special purpose robot programming language. But with a well defined set of playing rules you can limit the possibility of cheating. > Anyway, when I finish the game, I'll make the communication protocol >public, Let's first try to define the _exact_ playing rules. Then it's easier to define the communication protocol. I'll sleep on it this weekend :-) > so everybody is free to make his/her own language. I think you didn't quite understand what I meant: I was talking of _using_ a programming language to program the robot , not specifically _making_ it. You only define the _playing rules_ and each and everyone can make a program in any language (C, TP, asm, BASIC, COBOL) that obeys the rules and tries to win... Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: Re[2]: MSX game: an idea
On Thu, 10 Dec 1998 [EMAIL PROTECTED] wrote: > Shevek: > > > What I would like is having separate energie for: > > - shield > > - attack > > - move > > And one main energie type, which can be transferred to (not from) those types. > > To make this work, it will be useful that transferred energie cannot be used > > in the same turn as it was transferred. Otherwise, everybody would just have > > all his/her energie as shield at the end of every turn, which would make the > > separation useless. > > I think there should be only one energy supply (make life simple!) Simplicity is indeed a very good argument. :-) > [dead robots] > > I'd like them to stay, but if anybody has good arguments for removing > > them, it's fine with me. I think it would be nice if in a scan, you can't > > see if a robot is alive or not. > > [scanning and looking] > > I'd say that with short range scanning (looking) you can see also the > > ID-number of the robot and its communication at channel "local". > > Ehm.. I thought we would have an 'anonymous' system: no IDs :-) Oh, right. I like to have ID's. I stated before you don't need them, but that doesn't mean you shouldn't... > >> Team play has not been discussed at all (apart from mentioning it w.r.t. > >> the energy packets), so all other robots are of type enemy :-) > > I agree. > > Then why do you propose a means of communication? To the scanner, all other robots are enemies. Not to the program. > > For communication, I suggest the following method: Every robot can send > > signals at certain channels: > > -local:only readible for robots that can see the robot. Costs no energie > > -group:readible for every robot of a certain group (It does not have to be > > it's own group) Should cost energie (How much?) > > -all:readible for everyone. should cost energie (how much?) > > IMHO any form of communication makes the robots and the handling of them much > too complex. No communication is the best. It is fine to me if robots are > able to identify each other. That could be embedded in the communication > that each robot sends anyway (e.g. each datablock could start with (short) > name) You don't have to use comunication. It's just useful when you're playing with teams. I would like to have the commands, but in case of all against all, you would not use them, of course. > > A compiler would be very hard, I think. What is easier is to write the sourc > > and encode it before it can be executed. > > Which is about exactly what a compiler does :-) Not at all. A compiter makes it ready for execution. This code would would not make it executable, but the os could decode any file before it executes it, which would make it necessary to encode it. It looks the same, I agree. But a compiler creates ml and this one wouldn't. > >> I think it would be fun to have the compiler and executor separated. In that > >> way you can create your own robot, and distribute the _compiled_ code, so > >> others can test/play with your robot, but not hack it easily... > > > >Not to code easily, eighter... > > ?? Why? What I was talking about is a compiler which turns the robot-program into ml. That sounds quite hard to me. Not impossible, but hard. Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
[RobotZ] >Great idea! I could make it, I guess, but I can't say when it will be >finished, since I don't have so much spare time. > But please, send me exact >specifications on what the condition of an if-statement can be, and how the >radar can be used (or am I now asking just one question). Anyway, I think it >would be easy to make it hecto-multi-player (257 players at most, >simultaneously), by making use of joynet. 257? How did you cook up _that_ number? 255 or 256 or even 65536 :-) are numbers I could imagine, but 257? > I'm coding something at the moment >so that implementing that will be easy. Anyway, were you planning to make the >enemy-robots computercontrolled or humancontrolled? Human would be more fun, >of course, but you can't always find a second player... So what? Can't you write two robot-programs? :-) Another thing crossed my mind: Why develop a special programming language for the robot? The only reason for that could be that it's the only way to get more 'programs' running in parallel on _one_ MSX. But: if we take the game to JoyNet, as Shevek proposed, we only have to define the rules of the game (e.g. how the long and short range radar function, what happens if two robots want to get on the same playing field position) and the interface (how does each player receive / send its move). Then everyone can use his favorite programming language, and program his robot in the way (s)he likes. It saves us the definition and implementation of a new programming language and makes a killer app on JoyNet! Would make a heck of a competition game at a fair (wow!)... Eric MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Re: MSX game: an idea
On Sun, 29 Nov 1998, Stefano Fronteddu wrote: > Hi MSX people ! > I'm writing to all of You to explain an idea I had a lot of time ago. > I was thinking to develop a battle game: blah, what the news !!! > No this was my idea: > > I intended to develop a program that was able to read 2 files. > These files were the source code to control the action of a simulated > 'robot'. Great idea! I could make it, I guess, but I can't say when it will be finished, since I don't have so much spare time. But please, send me exact specifications on what the condition of an if-statement can be, and how the radar can be used (or am I now asking just one question). Anyway, I think it would be easy to make it hecto-multi-player (257 players at most, simultaneously), by making use of joynet. I'm coding something at the moment so that implementing that will be easy. Anyway, were you planning to make the enemy-robots computercontrolled or humancontrolled? Human would be more fun, of course, but you can't always find a second player... Are there many other people that would want to be a beta-tester anyway? (this question is to the others, of course) Bye, shevek MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
Re: MSX game: an idea
Hey, I for sure would like to be a beta-tester! It's great to see that people still are (willing to) make games for the MSX. Later, Hans -Original Message- From: shevek <[EMAIL PROTECTED]> To: MSX mailing list <[EMAIL PROTECTED]> Date: woensdag 2 december 1998 20:42 Subject: Re: MSX game: an idea >On Sun, 29 Nov 1998, Stefano Fronteddu wrote: > >> Hi MSX people ! >> I'm writing to all of You to explain an idea I had a lot of time ago. >> I was thinking to develop a battle game: blah, what the news !!! >> No this was my idea: >> >> I intended to develop a program that was able to read 2 files. >> These files were the source code to control the action of a simulated >> 'robot'. > >Great idea! I could make it, I guess, but I can't say when it will be >finished, since I don't have so much spare time. But please, send me exact >specifications on what the condition of an if-statement can be, and how >the radar can be used (or am I now asking just one question). Anyway, I >think it would be easy to make it hecto-multi-player (257 players at most, >simultaneously), by making use of joynet. I'm coding something at the >moment so that implementing that will be easy. Anyway, were you planning >to make the enemy-robots computercontrolled or humancontrolled? Human >would be more fun, of course, but you can't always find a second player... >Are there many other people that would want to be a beta-tester anyway? >(this question is to the others, of course) > >Bye, >shevek > > > >MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put >in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the >quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/) > > MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
