These skills will also stand you (eventually) in good stead for Rocket Club.
---
So, I am waiting for the muse to inspire me as to what next for synJam, and was idly thinking about synFPS (it is officially not ruled out) and then had nagging guilt feelings about unfinished Toys.
In my opinion, the only truly unfinished toys at present are synVille, which is a completely multiplayer building game, but not really very competitive, and not sufficiently inspiring for artistic types to add building styles to it. I think it will languish until I add some sort of easy building designer and some combat options. Which I don't feel like doing today.
So that leaves TurnAbout, which is clearly unfinished (though my version is a bit more advanced that what you see on the web site.) I added a scripting language to it some time ago (um, sigh, yes, some YEARS ago now.) I did this because I was uncomfortable making a simple script language whose commands lived inside the cards themselves.
My original goal for TurnAbout was that the card deck was everything. But I now feel I need both the card deck AND a master script for the root card. So if the root card is a monopoly card, then you are playing monopoly and everyone is running the master monopoly script and the cards are basically just a funky kind of memory device where the script saves data about the game.
So, once I got over that hump, I got interested again in working on this. And I think some of you will find this interesting. The way I am headed now, TurnAbout is going to finally open Arcadia to 3rd party toy development. It's a controlled enough environment that I can make it safe against your creating viruses and the like, yet a powerful enough language that you should be able to create an infinity of mini-games, not all of which are actually dependent on TurnAbout cards.
There are still some asset issues to be resolved, since 3rd party minigames will probably want to come bundled with some collection of image and sfx files. BUt I am just going to ignore that at first and proceed with the TurnAbout Card metaphor first, with other details emerging later.
And the scripting language is pig-slow, so we're probably not talking flight simulators here. But I do plan to provide basic graphics support to 'virtual screens' which can then be placed here and there in the toy window, with perhaps some simple sprite animation on the scripts behalf.
I probably shouldn't even mention this now, since this is a spectacularly busy time in my life and I probably won't take well to actual suggestions at this point, and commenting in advance probably invites suggestions, some of which will be really terrific (except the ones about MP3s!)
Anyway, I have a budget of 2 hours to wire this up. Let's see what I can do.
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
Is TurnAbout going to be pure Lua (which I looked at when you picked it for Rocket Club), or is it going to be an Arcadia language like QUEST is for Well of Souls?
---
Oh, and please fix the itty bitty tiny bug in synSpades that causes it to deal in the same order every hand
-------------------- SoV: Exalted Devout Oracle | World Developer | The Black Guard Outside is just a prank older kids tell younger kids at Internet Camp Posts: 9479 | From: NY | Registered: Apr 2003
| IP: Logged
posted
So, the pig-slow-ness means we can't write the FPS for you. Any chance of the scripting being sped up, or is that an inbuilt unchangeable limitation?
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
When you first posted about Lua on the RC Forum my brother was studing at the University that created it. Now *I*'m studing there
-------------------- "The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom" O.G. Posts: 4510 | From: Why would you want to know that? | Registered: Jun 2004
| IP: Logged
it's a very tiny, yet powerful, language, but it achives tiny-ness by lot's of deep code re-use and largish 'variant's instead of normal data types.
Now, is it slower or faster than visual basic? I don't know. It is likely faster. Plus, while it is an interpreted language, it DOES compile on first use (part of the slowness in some implementations is that they reload the script a lot. In TurnAbout the script will only load once, so you will only pay that price once)
Speaking of which, all you close-to-the-chest types would actually be able to pre-compile your scripts and distribute only the compiled version. While decompilers probably exist, I doubt they recover a very easy to read version.
And yes, 3rd party synFPS did cross my mind as well. :-)
The way it will work is similar to QUEST in the sense that you will NOT write a long program in lua which just takes over and runs constantly for the life of the game.
You will be INVOKED at specific function name points and you will do a small amount of work and then return as soon as possible. (Otherwise, arcadia will lose the ability to render, chat, etc.)
Something like this:
Every 50 msec, I call:
LuaDoTick() { }
Inside of your implementation of LuaDoTick(), you advance the state of your game, and make various simple requests of me like
GetCardData() SetCardData() LoadDIBFromJPG( dib3, "monster.jpg" ) DrawDIBOnOtherDIB( mainDIB, dib3, x, y) SendAPacket( "my very own packet")
And then return. Nothing that 'waits' on anything.
Arcadia will then accumulate a master DIB from what you tell it above, and will then render the last known state of mainDIB in the toy window. (THis is assuming your script wants to control the display... a 'normal' TurnAbout would just use the default TurnAbout stonehenge rendering -- for generic move-in-a-circle board games. Maybe other generic formats will emerge over time)
When packets come in that your script sent, arcadia will call some other function
LuaIncomingPacket()
---
Those are not the real names, just to give you an idea. Your lua script should be thought of as being a collection of 'event handlers' that get called when the game starts, stops, someone enters, leaves, a packet is received, time has gone by, etc.
Your event handlers can then make service 'requests' of arcadia, like 'send a packet', 'play a sound effect', 'display this simple UI widget'
What you will NOT be able to do is load/save any files. At all. Not until I am sure I can keep you contained to a sand box.
(note: asking arcadia to load a .wav or a .jpg is different from you having lua "fopen usersCheckBook.money")
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
I think you could create a class of TurnAbout "program" that is quicker, specifically for the purpose of a third-party FPS or similar. I think the main problem with that would be input control, though. How do I test that the player is holding down the W key (standard forward, for those unfamiliar with the genre)?
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
Your script would be 'event driven' so you would receive key up and key down events, and remember the state of the keys you cared about.
then in your periodic time tick, you would advance your physics based upon current user input state and previous physics state.
every so once in a while (to be determined by realistic lua performance limitations), your peridoc time tick would also render a new image in your output frame buffer
Arcadia would then copy your frame buffer to the screen whenever it changed, and hold the last known image until the next change.
You would also receive an event when your frame buffer changed size (because the user resized arcadia or dragged the splitter window)
As to the fact that arcadia wants the W key for chatting purposes... well, I guess that's open for negotiation. Will probably have to give you a way to 'register' keys that you want to own (and give you a way to turn that on and off, so that you could provide a 'chat toggle' for the player.)
None of the above is meant to imply an FPS is within the ability of Arcadia/TurnAbout/Lua.
Though if I exposed the Arcadia Park API and added support for 'walls' and 'objects', I imagine a lot of silly little games could take advantage of that environment.
I think these would be considered a menu of 'render styles' available to the script:
* turnabout circle of cards * arcadia park with moving faces * raw graphics of some ilk
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
You make my head spin. You make me learn QUEST. Now I have to learn Lua? :S Make one where I have to learn VB, and C++, too. Only way I will learn Posts: 3450 | From: OVER THERE! LOOK OUT! | Registered: Jul 2004
| IP: Logged
posted
OK, I didn't actually get to use my two hours yesterday, so I am going to use them today (I hope).
So, gettig back to Turnabout board/card games (cards in a circle).
The idea is that you can create a game 'style' by creating a new 'style card' (using the card editor).
There is always one script per style. So the style "monopoly" using the script "monopoly.script" while the style "spit" using the script "spit.script"
Style cards are always created by someone, and that somone has an aradia SerNum which is baked into the style card id. This serNum is also used to manage scripts. Hence when I (serNum 00000001) make a new style card for 'monopoly' it uses the script
assets/scripts/00000001/monopoly.script
and in theory you could have your own monopoly game, with a script called monopoly.script, but under your own serNum. (if you serNum changes, it is no big deal, you can make a deck using styles created by other serNums)
So, what's a DECK? Well, first, what's a CARD?
I admit to already confusing myself over this a bit, and the system is not quite as general as you might like it to be. But basically a CARD is a little basket of named properties. Some properties are present on all cards (like style and name), while other properties are unique to individual cards or groups of cards.
Cards are defined hierarchically, which each card 'inheriting' from some other cards (all cards ultimately inherit from the ROOT card)
The starting Hierarchy is like this:
ROOT (I define this, don't worry about it) ...STYLE (game being played) ......BASE (some category within the game) .........NODE (just to give it a name)
(to take part in the same game all cards must be in the current style. The moderator picks the style before the game starts)
So for Monopoly, you have a single master STYLE card called "Monopoly" and several BASE cards with names like "Train" "Utility" "Chance" and "Real Estate"
For each BASE card you then have NODE cards like "Reading Railroad", "Gas Works", "You win $5" and "Park Place"
So you can sort of see that to create monopoly, you need to use the card editor to make one card for each of the spots on the board, and one card for each 'chance' etc.
And I think you also end up with one card per player (card that represents players bank account, for example)
You then make a DECK by collecting together a bunch of cards (all from the same style). For hard core monopoly, there is exactly one deck and it never changes.
But from the perspective of TurnAbout, you could make your own Monopoly Deck (note: you are NOT changing the monopoly script, just making a different collection of cards) which might have more properties and fewer chance cards, but still followed all the basic rules of monopoly.
The monopoly.script is still in charge of the game (keeping track of who's turn it is, what choices they can make, what they roll, how far they move, what card they land on, what options do they have on that card, etc.
The individual NODE cards also contain appropriated data properties. For example the PARK PLACE node card has a 'rental rate' property. Rather than bake that information into the script (which you could, if you wanted), the card becomes a separately editable object.
This makes more sense in an RPG board game, where the card might represent some monster and the card properties contain the hit points etc of that monster.
Which brings us to static vs dynamic state. When you edit the card in the card editor, you are editing the 'static' or defined state of the card. When you actually play a game with that card, the card is 'copied' and its properties start with their default values that you set in the editor, but over the course of the game those values can change. These changes are NOT binding to the card itself (at least not yet.. the possibility exists to have cards that completely die.. thus no longer being available in subsequent games).
NOW, do you need cards?
Well, you absolutely need a STYLE card, because that is how the moderator picks the game people are playing, and what defines which script is to run. (and the moderator actually starts by picking a DECK which has at least one card in it, that card specifying the style) You can use the DECK editor to craft decks from all the cards you know about.
The rest of the game could be done entirely by the script, and need no cards at all. This might even make sense for something as static as monopoly.
So.
1.) Someone designs and implements a game by defining a STYLE and one or more CARDs, plus a SCRIPT.
2.) Someone wanting to moderate an instance of that game makes a DECK containing at least one card of that STYLE
3.) The moderator chooses the DECK he wants to play, a COPY of the deck is sent to all players. (who then make a temporary data structure for the life of the game, out of the cards in that deck, and fetch the associated style script if they don't already have it)
4.) The Moderator STARTs the game, which invokes a SCRIPT function that tells TurnAbout how the cards should be layed out, the order of the board, etc. And the script initializes itself to known starting state. The script has complete read/write access to the temp copy of the DECK
5.) TurnAbout renders the 'game board' and passes events to the script as moves are made and packets are received.
6.) Although all players are sending events to their copy of the script, the script knows if it is the moderator or not, and only the moderator's copy actually advances game state.
The general packet metaphor is that players send packets JUST to the moderator, but the moderator sends packets to ALL players.
Each player then attempts to maintain a synchronized game state by this strategy:
1.) player 2 knows it is his turn 2.) His script gets his move 3.) His script sends his move to moderator 4.) Moderator script receives move 5.) Moderator script validates move 6.) Moderator script translates move as needed 7.) Moderator script sends move to all players 8.) Players receive move from moderator and update their own state 9.) Player scripts request TurnAbout to display state. 10.) Part of the state is 'whose move is it'
The above being for a turn-based game. For a free for all, you just let players send move packets whenever they like, and each script validates and translates incoming moves as it feels best.
Even for a free for all, you can still have the moderator evaluate all moves, then forward them to the other players. This improves state synchronization at the expense of lag.
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
Note: only ROOT and STYLE are hard coded, you can have as many BASEs in the hierarchy as you see fit, it's just a way of setting common ancestry. for example:
A NODE can be a BASE. There is no real magic to BASE. Not the King Shark inherits from Shark, and the Shark inherits from Water Monster than inherits from monster.
The King Shark card only needs to specify properites which make it different from its base (shark). Likewise Shark card only needs properties which distinguish it from the base properties of a water monster, etc.
So unlike WoS where you have to fill in 50 values for every monster, here you can organize them and only diddle the things that make a monster unique. And you can come back later and modify 'monsters' properties and have that ripple through to all cards based on that.
So, cards are baskets of data. Given a card id, you can fetch any property of that card, and will get either the property set on that card, or backwards through its parentage until you find a base card that specifies that property.
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
Hmm... So this means that those of us who know/learn the scripting language will be able to make our own .script files, then take it further to make a DECK based on that .script if we so choose?
If so... I'll gladly take up the torch by making a turn-based Strategy game.
Don't get excited, it doesn't do anything worth shouting about, I just had to update the release so I could do some multiplayer development on it.
Note this requires Arcadia version 49 or you will have seg faults.
So, you guys have never seen the 'textured' stonehenge, and yet I did that three years ago at least.
You might find it interesting to look at toy10/assets/scripts/00000001/test.script (goes with the TEST card style -- you would need to make a deck with on TEST style card in it. Oh wait, I included one.. you just have to use the toy options dialog to select it. Then, as moderator, when you press the start game button, it will load the script and invoke a couple functions inside of it.
They will, in turn, invoke a couple TurnAbout functions (send packet, or add text to the chat window)
Not all that auspicious, but a start.
WHAT YOU NEED TO KNOW ABOUT LUA
-- This is a comment.
* Do not use semicolons at the end of lines
* this is a conditional:
if (whatever) then -- if true, do this else -- if false, do this end
* this is a function:
function myFunction( arg1, arg2 ) -- I can do stuff with arg1 and arg2 -- then I can return a value return arg1 + arg2 end
* you WILL forget the 'ends'
* you WILL add curly braces (don't)
* this is not-equal
if( a ~= 3 ) then TA_Log( "A is not 3" ) end
* ANY NUMBER is 'true' EVEN ZERO
* FOR FALSE, you need NIL
Any function starting with "TA_" (TurnAbout) is an extension to lua specific to turnabout.
If it starts with "TA_OnXXX" then it is an event handler function which YOU provide to handle INCOMING requests from TurnAbout.
Otherwise it is a functio nthat YOU call, to make a request of TurnABout to do something for you.
For example, YOU might want to send a packet with code like this:
When that packet is received at its destination, TurnAbout will call YOUR function:
function TA_OnPacket( fromSerNum, num1, num2, num3, num4, str1, str2, str3 ) -- Do something end
---
I doubt the packet stuff really works yet, it is what I was going to test. But maybe it does.
After years of writing mini-games, and hassling with lua, I came up with that format for packets as being the most 'generically useful'
The first argument is the serial number to which you are sending the packet. Use -1 for 'the moderator' and 0 for 'everyone' (though that doesn't mean you will receive your own packet, so if you need to do something yourself that everyone else will do only when they receive the packet.. well.. that's your problem)
the next 4 arguments are numbers (integers between -2 billion and +2billion. Sorry if you wanted floats. You don't get them -- see later on how you get them)
the next 3 arguments are strings (keep them simple, don't stick random binary or wacky punctuation in them). That's a destination and 7 arguments.
you will PROBABLY want to use the first number argument as a packet id number. You probably will send more than one sort of packet.
so that leaves you with 3 numbers and 3 strings to use for most packets. Packets are 'expensive' and as a designer you want to send as few as possible, and as small as possible.
I will be adding the 'who is playing' support later so you won't have to actually send packets to keep that coordinated.
Now, the numbers have to be signed integers, I don't allow you to use anything else. But the strings are just strings and I will send whatever you tell me to send. Just because I only give you three strings, doesn't mean you can't cram 25 pieces of information into each string. It's up to you to do the cramming and uncramming. I only promise to deliver it for you.
posted
Maybe this could be useful to link to, since it was posted here.
-------------------- SoV: Exalted Devout Oracle | World Developer | The Black Guard Outside is just a prank older kids tell younger kids at Internet Camp Posts: 9479 | From: NY | Registered: Apr 2003
| IP: Logged
posted
Well, as I've been looking forward to creating a version of Magic: The Gathering to play with DT, I'm glad you're finally working on this. I can see one place where abuse will take place, and that is folks will attempt to create looped scripts to hang Arcadia for everyone. Also, it looks like you're really changing the original idea around quite a bit. I guess I have to bite teh bullet now and bother to learn Lua, even though you suggested I do so last time we all discussed TurnAbout.
posted
Yeah, I know I originally wanted the scripting to be built into the cards themselves, but I just couldn't see how that was going to be powerful enough without making the cards huge. And since cards already only make sense within the context of a single style, it seems a style script is the best option all around for delivering something powerful in my lifetime
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
I might as well expose this since I already have all the support for it.
Say your script wants to offer the player a little popup panel of buttons, appropriate to the 'move' you are waiting for the player to make. (like "Deal Cards" or "Fight/Flee")
If you look in toy10/assets/panels you will see pairs of files like deal.bmp/deal.ini
If you look at deal.bmp you will see it is the graphic of a little panel, but two copies of it, one to the right of the other.
In the LEFT copy, all the buttons are 'up' and in the RIGHT copy all the buttons are 'down' (and buttons must be far enough apart that you can make a rectangle around each of them which does not intersect with the others)
The .ini file has a description of all the rectangles of interest on the panel, including an id #.
So, I will set it up so that the lua script can say "display panel X"
and then when the user clicks on one of the buttons, I will call TA_OnPanelClick( panelName, buttonId )
and the script will then do whatever that button means to the script. Including telling me to stop showing that panel, or show another one instead (currently I only support one panel at a time, but I could probably widen that)
UPSIDE
Code already exists, metaphor is simple, you can draw whatever you like (ahead of time) so you control look and 99% of feel.
DOWNSIDE
Buttons are completely static (you can't, for example, supply text at run time to put somewhere on the panel). And it's just buttons. No edit boxes, etc.
I could go in several directions here... augment Panel support to include these things... force you to provide Windows DIALOG Rresource definitions (too much work for me, I think).
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
Well, dang. I guess an FPS really is out of the question, then, if we can only provide that much data per packet. Transmitting a shot would take at least two packets, and imagine the packet storm during machinegun wars.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
posted
You're thinking too literally... send a packet when the trigger is pulled, send another packet when the trigger is lifted. synthesize all the bullet info at both ends.
You know all about the weapon from one packet sent only when the user selects a new weapon (weapon #3), and then locally you have a table that knows how many bullets a second, at what speed, etc, are associated with that weapon.
If you can design your game to send one packet (or less) in response to individual player actions (button clicks), then probably you won't have packet issues.
For position updates, you would probably do something 'predictive' like every second send one packet with a guess as to where you will be a second later. (as opposed to sending 30 packets a second saying "i am HERE")
HOW SLOW IS LUA
OK, well, I apologize for implying lua was synonymous with molasses. After some simple tests:
1.) 'C' can complete a function call and return from lua in under 500 nanoseconds. Slower than a Pentium Whatever can call a local function, but still much faster than I expected.
2.) a simple lua iteration (for 1,1000,1 do) is about 50 ns per step
3.) inside that iteration, a multiply is about 15 ns
4.) inside that iteration, storing a value to a hash is about 200ns, and reading it back is about 100 ns.
So, sure, it won't replace your GPU (I mean, we KNOW we won't be coding pixel shaders in Lua), but still, kudos to lua!
posted
I was thinking more along the lines of "Sending firing type packet, player aimed at x,y,z", then repeating for every bullet fired, though I suppose I should allow for something like predictive firing.
I already know that I'm going to limit packets from movement to whenever a player changes direction or speed, so that players running in straight lines continue to do so, even if a player drops. I think that I will need two packets there as well, one for "I am here right now, about to give you a new destination to move your model of me towards", and one for "I am moving towards this destination".
Firing would involve, with my model: "I have clicked the fire button with my current weapon (which has ammunition) from my location, and am about to send you the destination packet (where I'm looking)", and "I was looking here when I fired."
I suppose pressing and lifting the trigger would work better, though.
It does mean rotation packet storms, though. One player could stand in place and look around as fast as they could to cause insane amounts of lag, unless I tried to predict that as well, or told people I was changing where I was looking, and in what direction, and then told them I had stopped changing that.
I guess that would work best: packets for movement (8), packets for looking (2), packets for firing (2), packets for switching weapons. And that includes crouching and jumping, as well!
That means that we're responding to clicks on the mouse with a packet apeice, which is bad for burstfire-ers (repeated clicking), and good for those who hold the button. It means we're responding with one packet to any combination of the WASDC<Space> keys. And it means that a movement of the mouse also gets one packet, until it stops moving that way. It also means I'm sending a packet when we switch weapons.
Sounds pretty neat, it shouldn't be too bad. Now, I just wonder how well "stealing" keys is going to work? I wonder if it would be possible to set a hotkey to toggle the other frame into/out of existance and have the whole program window be controlled by the style card script during key-stealing? That way, the chat/playerlist isn't there being distracting during a heated round of capture the flag.
I could even program a small console prompt in the game to allow players to send short text strings back and forth without needing to bring up the chat frame. That would also allow voting for game modes, maps, and possibly removing disruptive players from the game (though that should probably be limited to the moderator of the server).
And yes, that is simply a flow of ideas off of your post. Thanks.
Oh, btw, I'd love to talk with you sometime about an RTS I'm programming for my senior project.
-------------------- Constantinople! We shall never forget your zany barge poles! Posts: 4232 | From: Gresham, OR | Registered: Nov 2003
| IP: Logged
-- This is a TurnAbout STYLE Script, for the style "0000001.Test" -- It probably doesn't do anything interesting, but perhaps it will evolve into -- something of a demonstration script. -- It is just a text file, and contains "lua" code. You can read about -- lua at "http://www.lua.org/pil"
-- Note the incredibly non-standard comment marker (two dashes) used in lua. Lua is... different
TA_Log( "Hey, this came from lua!" );
-- Just to test argument passing function OnTestFunction( arg1, arg2, arg3 ) TA_Log( "Arcadia called OnTestFunction( " .. arg1 .. ", " .. arg2 .. ", " .. arg3 .. " )" ) return arg1, arg2, arg3 end
---------------------------- -- Here we initialize some globals
---------------------------- -- These are the Event Handlers which you MUST provide -- Event Handlers always start with TA_OnXXX -- Anything else starting with TA_ is a request you are making of TurnAbout to do something for you -- You don't have to DO anything necessarily in your function, but the -- funciton must exist.
----------------------------------------------------- -- Script has just been loaded, here are some sernums -- And the size of the toy screen window (in pixels) -- You should initialize anything you think needs initialization
TA_Log( "TA_OnLoaded called" ) if( TA_IsModerator( glMySerNum ) ) then TA_Log( "..And I am the moderator!" ); end end
------------------------------------------------------ -- Toy Window has changed size. If you do graphics, you probably care
function TA_OnSize( width, height ) glWidth = width glHeight = height TA_Log( "TA_OnSize( " .. width .. " x " .. height .. " )" ) end
------------------------------------------------------ -- A packet has been received. This packet was SENT via the TA_SendPacket -- command, and contains the arguments included at that time
-- For this test file, we react to an incoming packet FROM the moderator by -- sending a packet back to him.
if( TA_IsModerator( serNumSender ) ) then TA_Log( "That packet was from the moderator, so I will send a packet back!" ) TA_SendPacket( -1, -11, -22, -33, -44, "response string1", "response string2", "response string3" ) end end
--------------------------------------------------------- -- Moderator has just started the game, if you do not allow drop-in play, then -- preserve the player list now (note: I do not yet have a player list for you -- but when I do, it will also include bots)
if( TA_IsModerator( glMySerNum ) ) then TA_Log( "..And I am the moderator! I will send a packet to everyone!" ); TA_SendPacket( 0, 1, 2, 3, 4, "this is string1", "this is string2", "this is string3" ) else TA_Log( ".. And I am NOT the moderator. I will send a packet to the moderator" ); TA_SendPacket( -1, -1, -2, -3, -4, "player string1", "player string2", "player string3" ) end end
----------------------------------------------------------- -- TurnAbout wants to know if you still exist. This is just for timing measurements -- and we don't have to really do anything (in fact, best if we don't, but you might -- find some use in sticking some function call in here that you would like to test
function TA_OnPing( count ) --[[ -- Do nothing, just testing time for 'C' to call Lua. (450 ns per call) -- OK, it was about 500 nanoseconds to call and return. much better than I thought -- Now to see how fast lua is doing some simple iteration -- OK, so it takes lua about 50 microseconds to iterate over 1000 in a for loop (50 ns per loop) local a = 23 local data = {} for var=1, 1000, 1 do -- nothing -- ok, some simple math -- a = a * 1.234 -- about 15 nanoseconds per multiply -- ok, writing to a hash data[ var ] = "test" -- about 220 nanoseconds (269 microseconds to do it 1K times - 47) if( data[ var ] ~= "test" ) then -- (383 uS, so 114 nanoseconds to read hash and do compare) end end --]] end
----------------------------------------------------------- -- This function is called 'frequently' (though there is no guarantee exactly how -- often). 'msec' is how many milliseconds since your computer was booted, hence -- it is of no absolute use, but if you track changes, you can use it to implement -- timers of any duration. -- This is where you should (periodically) calculate your physics and (periodically) -- cause your display to be refreshed -- I will start calling this right after TA_OnLoaded(), so be prepared. You might -- (for example) not really have anything to do until after the game starts.
F5IsDown = nil
function TA_OnTick( msec ) -- Let's track the state of the F5 key local F5IsDownNow = TA_IsKeyDown( 116 ) -- need 'vkey code' if ( F5IsDown ~= F5IsDownNow ) then -- state has changed F5IsDown = F5IsDownNow if( F5IsDown ) then TA_Log( "F5 is down! let it go!" ) else TA_Log( "F5 is up! Push it again!" ) end end end
----------------------------------------------------------- -- This function is called when the player hits ENTER after typing a line of text -- in the arcadia chat window. If it is not a special Arcadia slash command, then -- you get to see it before it is sent to the other players. -- You might use it as a way to pick up special commands. This function returns -- TWO values (lua is like that). The first is a number, and the second is a string -- -- return 0, "" (means go ahead and send this as chat as you would normally) -- return 1, "" (means, do NOT send this as chat! act like the user never typed it -- return 2, "send this instead" (means, forget what he typed, send my string instead! -- -- The serNum and playerName will always be that of the local player, but are included -- on the off chance they are of value to you
function TA_OnText( serNum, playerName, text ) if( text == "apple" ) then -- replace it return 2, "I like apples! My name is " .. playerName .. " and my sernum is " .. serNum elseif ( text == "secret" ) then -- discard it return 1, "" else -- treat it as normal return 0, "" end end
code:
Available Service functions:
TA_Log( "add this to the chat window" ) TA_IsModerator( someSerialNumber ) TA_SendPacket( ... ) (see example) TA_IsKeyDown( virtKeyCode ) TA_Print( "like Log but with <b>bold</b> and things like that" ) TA_MaxPlayerSlots() (returns 8) TA_NthPlayerSlot( n ) (returns state, serNum, name of player in slot (1-8), if any)
I am still waffling between adding TA_OnKeyDown/Up events versus having you register as 'owning' individual keys. You have more precise control with the keyDown/Up events, but you have to return very correct values (to properly suppress the events) or windows will ultimately get hosed.
So right now, holding down the W key would be easily sensed (see example handling of F5 key) but it is still being used in chat at the same time
Anyway, between OnText, OnPacket, Log, and SendPacket, you could now compose a complete multiplayer text game where input was what the player typed in the chat window and output was back to the chat window.
I guess I should write such a game now and then push a new version.
posted
"Trapping" the mouse cursor also turns out to be important for an FPS. Imagine trying to turn right when the cursor is already on the far right of your screen! I imagine that if you implemented the toggling thing for those who want full screen control, you could make the cursor become either trapped, or replaced by a custom cursor (cool-looking RTS?). This is probably the coolest toy yet, Dan.
And Dan, this example script is nice. It looks fairly simple to do, and I'm already loving LUA.
posted
Congratulations everyone, im the first Arcadian to play the MUD! I played the text adventure game which is simply thrilling. I am honestly working on a map which i have made some progress on. Im really tired so ill work on it tomarow.
posted
Luke, if I understand you to say you are editting miniMUD.script to make your own map, I have the following comments:
1.) be sure to copy it to a folder with your serial number, or else it will get overwritten on the next release.
2.) I have not implemented auto-file-sharing of the script files yet, so you would have to share it manually for now
3.) The API is still in flux, and will likely change over the next few releases, in ways which will require (probably) updating existing scripts. Though I will try to keep that to a minimum.
---
The special directives used in the TA_Print() function are:
code:
<b>this is in bold</b> <i>this is in italic</i> <u>this is underlined</u> <color=FF0000> everything after that is in red <size=120> everything after that is font size 120 <font=verdana> everything after that is in verdand font
New lines always start out white, size 90, with the user's selected arcadia chat font.
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
Lol actually i didnt mess with your MUD script yet. I just mapped your MUD world. I can find my way anywhere really quick now. If you want to check out my map i hosted it for you at http://www.soleyhosting.gotdns.com/Luke/IMG/lukemap.jpg
It will help you if you get lost in the amazing world. If you find anything missing or wrong let me know so i can update it.
-------------------- SoV: Exalted Devout Oracle | World Developer | The Black Guard Outside is just a prank older kids tell younger kids at Internet Camp Posts: 9479 | From: NY | Registered: Apr 2003
| IP: Logged
posted
Glad you like it, my favorite has to be the Hillside or the omnious stench room. If i missed any doorways or missed some rooms let me know ill add on.
Posts: 44 | From: Kansas | Registered: Nov 2005
| IP: Logged
-------------------- "The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom" O.G. Posts: 4510 | From: Why would you want to know that? | Registered: Jun 2004
| IP: Logged
posted
Wow, i headed on down to the beach area and noticed that im missing several rooms! Not only am i missing the ocean, i also have no surf, and none of the right beaches. Im going to do a bit more exploring to see if i have missed anything else. I will start working on the revision now, expect me to be finished with revision 2 in a few hours.
Posts: 44 | From: Kansas | Registered: Nov 2005
| IP: Logged
* improves multiplayer elements of MiniMUD * extends TA_ api * adds ability to read/write card properties from script * handles latecomer drop-in to game in progress * did first cut of web page describing toy * added 'items' to miniMUD (and made them extensible by adding cards to deck) * added TAKE command and room description includes stuff on floor.
MOstly fleshing out miniMUD and adding API functions to make it possible to do something like miniMUD.
-------------------- He knows when you are sleeping. Posts: 10597 | From: California | Registered: Dec 1998
| IP: Logged
posted
!!! I'm definitely going to call them toy-lets now. My assessment of arcadia's player base predicts this name will spread like wildfire.
-------------------- "In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." Posts: 152 | From: yesterday | Registered: Nov 2003
| IP: Logged
posted
Im all pumped up about this! I cant wait untill Dan's Mini Mud toylet supports combat! I mean it was great exploring all over but then i got bored and started my mapping project, after a while i got tired of THAT. Then we were all surprised by these excellent items such as copper pants and such, i just hope we got combat soon, i cant wait to hit someone with my poundcake!
Posts: 44 | From: Kansas | Registered: Nov 2005
| IP: Logged
posted
TurnAbout Bug #1: When you enter a server with a game in progress, either you don't see the Join Game button, or the Join Game button doesn't work, thus you can't join the game. However, if it starts while you are already in the server, then it works fine.
TurnAbout Bug #2(Dan's MiniMUD): When you type 'look' then for some people it displays who's in the room with you, for others it doesn't. Could be a problem with packets. Second with this, is that the message still appears when they enter or exit your room.
-------------------- SoV - High Priest Posts: 1139 | Registered: May 2005
| IP: Logged
Printer-friendly view of this topic
![[Smile]](smile.gif)
![[Big Grin]](biggrin.gif)
![[Eek!]](eek.gif)
![[Razz]](tongue.gif)
![[Frown]](frown.gif)
