Feb 7, 2010: Update
I haven’t worked on this project in some time…. Today it was time to cleanup and move the site to the new provider.
Aug 9, 2000: Update
As many of you have guessed, I had to put Netlod on hold for a few months while I’ve been tending to other things. Unfortunately, my biggest expense in developing a long term project like netlod is my own time — time spent programming netlod takes away from my more conventional money-paying work.
However, I do plan to resume serious work on Netlod within a month or so. I’ve set a preliminary deadline of the next release for September 15. I also plan on hosting a multiplayer game from my site. I’m in the process of replacing the problematic ISDN line with a much faster and more reliable wireless internet connection. The wireless connection was installed today and so far has tested out well — downstream bursts to 5Mbps.
Apr 21, 2000: ISDN Line Installed; New Beta Release
Uswest has finally got my ISDN line installed, and initial tests show it to be working fairly well. This means I will be able to get around to setting up the first LOD server based multiplayer game. I’m going to set up a special machine to handle this, which will probably take me a week or two to get sorted out.
The ISDN line has also given me enough bandwidth to resume uploading the LOD distributions, which I will try to do soon (maybe even tonight).
Mar 16,2000: Work Continues
I’m still waiting on the ISDN line from USWest. They’ve actually got things working to the point that I can connect to an ISP, but not without suffering terrible throughput and frequent line failures. New due date is tomorrow; Hopefully they will get tings resolved. If it isn’t done tomorrow, then I’ll probably proceed with uploaded beta 1.0e via my current (extremely slow) modem connection.
I have done some work on fixing graphic performance for 256-color users. Speed should now be on par with 24-bit users, and quality has improved significantly. Right now I’m using a flat color palette — as soon as I fix things to use LOD’s specialized palette then the graphics will be the same as in 24-bit mode.
Mar 6, 2000: Return from Vacation
I’m back from Vacation in Cabo San Lucas (I know, I forgot to mention I was going….). Work on NETLOD will resume soon. The phone company was here today working on the ISDN line; As soon as they get it finished, it’ll be time for me to setup a multiplayer game here at the house.
The next beta should be released soon, with many fixes and several devices implemented (vortex cells, warpers, etc).
Feb 24,2000: Vortex Ammo and EEEE
I spent some time implementing the Vortex Cell ammo type since they are a very nice thing to have, and required by some of the Zone 5 monsters. I’ve also opened up the EEEE store, since it is the place to buy vortex cells. The EEEE has several other items that I will be implementing soon…
A big thing on my list is the Warper device and its associated emwarp feature.
Borland C++ Builder 5.0 has arrived, and the good news is that it doesn’t crash my development environment as often as it used to. I believe it will also fix the problem of the <Tab> key not working right in the HTML window.
My ISDN line has been rescheduled for 3-6-00, so I’ll have to wait a bit longer to get the local server up and running.
Feb 22,2000: Beta Comments
I’ve had a few complaints with the latest beta that there’s not enough room on screen in 800×600 graphic modes. The best suggestion I can make is to run in 1024×768 or higher if possible. Of course, that doesn’t help those of you who have video cards or monitors that won’t go above 800×600.
I am working on making the inventory window have an optional pop-up mode. The inventory will automatically shrink to a little bar and only pop-up to full size when you move your mouse over it. This will be an optional mode, but will probably be quite nice for those who are short on space.
Feb 18,2000: Beta Released
The fourth beta version has been released. This version is adsoftware enabled, and includes the much awaited for rankings function as well as a wealth of bug fixes, large and small.
This one was particularly difficult to upload because both of my ISP’s crapped out on me. The idiots at AzStarnet terminated my account because I (supposedly) left my connection open for too many hours one day. They did this without notifying me, leaving me left in the dark, and crashing the 6 megabyte Gterm upload in mid-transfer. AzStarnet now owns the #1 position on my list of “companies not to ever do business with in the future”. Fortunately, I have backup ISP, Primenet, for use in just such emergencies. Unfortunately, the upstream connection on Primenet’s modems sucks. There’s no better way to put it — the service just plain sucks. Connection rates of 500-1000 bytes per second, frequent dropped connections, etc. I’ve sent an email off to Primenet tech support without any response as of yet… To make a long story short, it’s taken two and a half days to get Gterm 1.0d uploaded.
On a positive note, my ISDN install is still scheduled for 2-24-00, so I should be on the way to dedicated 128Kbps connectivity.
I’ve orded a new C++ Builder compiler from Borland. This should fix the problem of <Tab> and <Del> not working right in Gterm’s HTML window. Rather than fix the bugs in the compiler that I already paid Borland $250 for, Borland feels it’s a much better idea for me to pay another $250 to get an upgrade that fixes the bugs. (hmmm… releasing buggy, unreliable products is a good way for extorting $250/year out of customers for constant upgrades… If the big commercial shops actually guaranteed free updates to their software as I do with my shareware, they’d surely go broke)
I’m pleased with how the betas are coming along, and I think it won’t be much longer until I am ready to release the beta server, which will allow some multiplayer games.
Feb 16,2000: Waiting…
I’m holding up the next release while I wait for the adsoftware people to get back to me on adsoftware-enabling Gterm, so that I can have everyone testing the adsoftware version. I’ll probably reward the beta testers who’ve been significant contributors with free registration codes, but I’d still like everyone to try out the adsoftware version for a week or two.
I’m also waiting on the installation of an ISDN line at my house. DSL and CableModem aren’t available, so the best I can do is ISDN. It’ll give me 128Kbps dedicated connectivity with static IP’s, and I will use that to host initial versions of the LOD server. Once the server has checked out and has proven itself not to be a security/reliability risk, I’ll set one up on my CobaltRAQ which has dedicated high-speed connectivity to the backbone. My ISDN install is scheduled for 2-24-00.
On the programming front, I have been making improvements lately. The rankings command is now done and will be available in the next beta version. The rankings command is really one of the key elements of multiplayer interaction as it spurs competition among the players.
I’ve cleaned up several pylon interaction problems (i.e. hell pylons not working, etc) which should remove a few obstacles to gameplay. Also in place is the View-Monster command, which everybody has been asking for.
Feb 10,2000: AdSoftware
I’ve made the decision to use AdSoftware in the “free” versions of Gterm. For those of you who have not seen AdSoftware before, it displays a small advertisement across the bottom of the program window.
The reason for doing this is two-fold:
- I want users to be able to play LOD for free – no monthly fees, no program fees, etc. Absolutely free play.
- I need to be able to make enough money to support the NETLOD project.
The only way for me to make money, while still ensuring that NETLOD remains free to all players is to use a scheme like AdSoftware. Advertisements will only be displayed on the unregistered versions of NETLOD. Users who pay the modest registration fee will get a version that has no advertisements.
The price of the registrations is as of yet to be determined. I may build it into my $19.95 “SB series” shareware package, or I may make it a standalone package at a different price.
Feb 7, 2000: Music and Sound
I’ve added support for Classic LOD’s MOD music. There are several reasons for choosing MOD as an audio format:
- LOD’s Music is already written in the MOD format, and thus does not need conversion.
- MOD supports multiple channels and digital samples
- MP3 and WAV are too large for reasonable Internet download
The other obvious option would be to use MIDI, but I didn’t have the code as available and we would have needed to convert the existing music. I may add MIDI and/or MP3 in the future.
Music is set by adding a parameter onto the html filename — for example: store.html?music=witching.mod will display the file store.html and set the current music to witching.mod.
Sound effects can be linked into html pages using standard html mechanisms (see html/hell*.html for examples). The obvious choice here is the WAV format (with compression). I used MSADPCM compression which should be widely available to end-users and achieves fairly good results.
Feb 2, 2000: Third beta released (1.0c)
The third beta fixes a few bugs as well as adding a much needed clean (kill) objects command and a quick-heal command. A full list of revisions may be found here.
People have asked for some clarification on what happens if you log off or exit the game during combat. I believe the conditions are as follows:
- <Logoff> — automatic berserk. (1.0b does not notify the player of this; The next version will)
- Closing the terminal program — automatic berserk
- Closing the server — monster disappears, no dropping of inventory or gain of exp.
- Loss of connection (i.e. your ISP dumps you) — automatic berserk
- Local/Standalone mode — the terminal and server are the same program, so behavior defaults to #3. This does allow local players to cheat, but this is not much of a concern as local players could just go edit their INI files anyhow.
Also being discussed is adding a “helmet” equipped item. The helmet could either replace the shield, or could replace the laptop. (There’s really no good reasons why laptops are equipped items rather than inventory items).
Jan 31, 2000: Second beta released (1.0b)
Bug reports have been flowing in and I have released the second beta version. The major items fixed are combat stalling when monsters run out of ammo, and monsters remaining active after a player runs. Click here for the full revision history.
Jan 29, 2000: First beta released (1.0a)
I have gone ahead and released the first beta. Here’s hoping that it even loads up on everyones machines!
Jan 27, 2000: Finishing up the first Beta
Work on the first beta continues. I’m continually being hammered by small issues such as monsters appearing in the wrong zones, minor combat glitches, etc. There are a million small details with any project that always need to be ironed out.
I’ve created download and buglist pages to go on the website as soon as the beta is ready. I’m anxious to get the beta online so the final issues can be worked out.
The big test is going to be network latency. Previous versions of LOD worked over a dedicated modem connection and that minimized latency. Althought throughput is much better on the web since we’re all using 33K modems (or faster), latency is still terrible terrible due to all of the “hops” between and end user and a web server.
Jan 26, 2000: IE Problems
The MSIE web brwoser control used in LOD has been giving me significant amounts of grief. For some reason my test system running IE4 won’t allow typing in the HTML form fields. However, installing IE5 seems to have solved the problem. The end result is that LOD will (probably) require IE5.
Although I hate Microsoft as much as the next guy, the only other alternative is to require a large clunky HTML rendering control that would be at least as much size and complication as MSIE to install. It probably wouldn’t work nearly as well as MSIE, or support plug-ins and other exotic features.
Jan 17, 2000: Beta Work
I’ve been working on getting the beta ready for release. There are lots of little nagging details that have to be dealt with, such as 256-color performance (right now, LOD really likes true-color modes much better!). I also wrote up the install script so the game can be installed automatically.
256-color mode is giving me all sorts of problems due to palette matching. LOD needs to display 49 map tiles and 16 inventory tiles onscreen at once. I really wanted a solution that would let people use various palettes and color-match them at runtime, but this is probably too difficult. What I’ll end up doing is going with the standard LOD palette, and then matching anyone who uses a different palette to that one. The result: Use the standard LOD palette or your colors will get screwed up.
I made the change from the Delphi NMHTML control to use Microsoft’s WebBrowser control for displaying HTML. The Delphi control was no longer being supported and required a rather large runtime library. However, the Microsoft control requires that Internet Explorer be installed on your system. Since Microsoft has forced IE down everyones throat anyhow, this is not much of a problem. (Note, IE is a requirement of the client terminal only; The LOD server will fine without it)
The beta will be incomplete in the sense that many inventory items will not work properly, because I haven’t implemented them yet. The core functionality should be working though (i.e. combat, map movement, inventory management, etc). There’s no fortresses yet, and many places can’t be entered (i.e. EEEE, SSSS, Casino Machines, Taverns, etc). I still have to write the rankings system.
Jan 12, 2000: More Player-vs-Player Combat
I spent a lot of time ironing out the run and surrender commands. These were a simple thing to do in classic LOD, since you were always fighting a simple monster, but more difficult in netlod, since you may be fighting another player. Running will work as follows:
- When you run, your Agl will be compared to the Dex of each person you are fighting. An equal ratio will yield a 50% run chance. If you are fighting multiple people, then you chances of successfully running are fairly poor.
- Running will automatically move you to an adjacent square.
And surrender…
- First you offer a surrender tribute. The tribute is how much money you will pay for someone to let you go.
- Then, each person you are fighting must show mercy on you and let you escape, each one taking a portion of the tribute.
- Players and monsters are under no obligation to show mercy. Monsters will probably do it as long as your tribute is 1/2 your gold.
- Players may also show mercy at any time without taking a tribute. For example, if you are fighting someone and then change your mind and decide to let them go. However, if you show mercy, it is no guarantee your opponent will do the same.
Jan 7, 2000: Player-vs-Player Combat
I spent some time working on player-vs-player combat today. The good news is that the way I’ve implemented it, combat against a player is almost identical to combat against a monster. This simplifies implementing the combat system significantly.
Turn sequencing is going to work with a sequence number. Each player is has a combat sequence number, starting at zero. The rules work as follows:
- Player A can only attack player B, if A_Sequence <= B_Sequence.
- When A attacks B, the game sets A_Sequence = B_Sequence + 1
- The solution is symmetric (if B attack A, then the same rules are applied)
I have not implemented the “timeout” for slow players yet. Right now, the sequencing will cuase you to wait until your opponent has made his turn before you can make yours. However, I will be adding some kind of timeout (30 seconds? 60 seconds?) to keep a “slow” player from starving out a “fast” player.
In the case that you are attacking someone who is not online, the game will proceed at full speed, as if you were attacking a monster.
On an unrelated note, Randy Sommerfield has generously offered me the domain landofdevastation.com. I’ll probably take him up on the offer, but we have yet to work this out for certain.
Jan 6, 2000: Transparent Image Support
NETLOD will support layering transparent GIF’s together to create monster pictures. The way this will work is as follows:
- Each terrain type will have an optional 320×200 “bigpic” assigned to it as a combat background. For example, the forest and mountains will likely have different backgrounds.
- New monster pictures will be designed as transparent GIF images, with background set to the transparency color.
- Monster pictures can now be layered. For example, the picture leather.gif;bounty.gif;forest.gif could layer leather armor on a bounty hunter in a forest.
- Monster pictures can be set to automatically choose the current terrain background, thus we could have our bounty hunter automatically appear in whatever terrain the user is standing in.
This will not only increase the visual quality of the game, but also make life easier for the artists, as they will not need to draw a background for each and every monster picture, rather they gain access to a shared collection of terrain backgrounds.
Similarly, I am working on a system for having multiple terrain layers. For example, we could draw one instance of a “desk”, and then place it on the floor tile of choice.
BETA UPDATE: I am working hard on getting the first public beta ready to go. I decided to hold it back a week or two in favor of getting it a little more polished up for the initial test….
Jan 4, 2000: Finishing up the combat system, new weapon/device ideas
I’m working on various odds and ends related to getting the combat system finished. For example, getting the player to “die” properly so he can be resurrected, or re-created.
I’ve been thinking of adding some general attribute bonuses to the device system. For example, each device could be given Str, Dex, and/or Agl bonuses that would go into effect whenever the item is equipped. For example, a “Kevlar Armor of Might” would be a kevlar armor that increased your strength when equipped.
Another thing that would be nice would be monster specific to-hit bonuses. For example, a “Graviton Sword of Loki Slaying” that would have a +15% bonus when used on a Loki creature. This may be somewhat difficult to code up. I’ll have to think more about it.
Continuing this idea, we could have a weaponsmith (as in Classic LOD) that could actually add monster specific bonus to weapons. For example, modifying a standard razorlance to do increased damage against robot/droid monsters. We could have named weapons where a player can create a custom weapon, add some special touches, and give it a name, i.e. “LokiSlayer”.
Dec 29, 1999: Unix Server
It was an exhaustive effort, but the server side of NETLOD can now be used under both Linux and Windows. This is essential because many web servers are running Linux, and those are an ideal place to deploy LOD. In theory, it ought to compile on my own ‘raq’ server at www.landofdev.com, and give us some good bandwidth.
Dec 27, 1999: Misc
I started working on some of the misc devices today. Stealth field generators were the first as I’m tired of getting repeatedly attacked while wandering the wastelands. Coding up the SFG’s was fairly simple, though I did go to some effort to instrument the HTML parser with some additional client side scripting (an ‘if’ statement) that should make future devices easier to write.
Next up were the miniraft and cryo-unit. Of course, you don’t actually ‘use’ a miniraft or cryo-unit, so that part was easy…
Next came the LRScan device. I decided to use a map size of 11×11 for the LRScan as this seemed to look good and fit the display. LRScan makes use of the HTML window and thus has to display its output using HTML. This presents a problem with overlaying the obj/base/camp icons. Maybe we’ll just eliminate those in favor of making them available in the scanner device instead.
I’ve rewritten the simple stub protocol engine to use TCP, so the game is now ready to be split into two pieces (client and server) if necessary. I need to study latency and see how it affects game play.
Dec 23, 1999: Combat System
The combat system is coming together. The design is quite similar to classic LOD, but with a few extensions to support concurrent multiple players and multiple monsters. The way it’ll work is as follows:
- You encounter a creature in the wastelands (i.e. random combat), and the combat window will be displayed.
- The combat window includes a 320×200 monster picture, as well as a series of quick buttons (lr hit, sr hit, parry, run, surrender, etc). Also present is a scrolling combat log.
- You will get one long range hit at the start of combat, after that your LR weapon is unusable for the duration. Ditto for the monster. If you go straight to the SR weapon, then you will not be able to use your LR weapon.
- If multiple creatures are present (i.e. other players and/or monsters), then you can scroll through them and pick the one you want to fight.
The combat system is nearly completed with weapons, armor, etc working exactly the same as classic LOD.
I have placed some screen shots online:
Dec 15, 1999: The Future of LOD
I’ve had some people ask why I don’t try something more ambitious, such as an online world equivalent to Fallout or Baldur’s Gate. I have to admit, I would love to do such a thing… However, I do believe in taking steps. LOD wasn’t the first door game I wrote — there were many others that came before it. They served as stepping stones that were a necessary learning process towards the ultimate goal.
I have designed NETLOD to be extensible. Although our first graphical terminal is going to have the classic 7×7 graphical display, I’d like to eventually experiment with some other ideas. We can try enlarging the number of cells — 15×15 or more. We can try enlarging the tile size to add more detail. We can swap out the 2D graphics and put in a 3D projected view (like Fallout/Baldurs). We can add spot animation. Only time will tell what happens.
I’m also convinced that we can put together the most diverse online world out there. We did it for the BBS world with the original LOD, and we’ll do it with the Internet world with the new LOD. LOD has always been a fan-supported effort. I only designed a few monsters and drew none of the graphics — you people did the rest. I only came up with a handful of devices — the others were user suggestions, and of course I only wrote one dataset.
In the end, I think we can do better than the commercial game designers — they’re just after a fast buck. It might be NETLOD2, or Super-NETLOD, or god knows what before we’re state of the art, but we will get there. Its players like you that make the difference.
Game Progress
Now that I’ve rambled on about the future of LOD, it’s time for a game update. I worked on the monster system yesterday and today. My day job has been cutting into my programming time again, so progress has not been as good as I had hoped for. I’m still very anxious to see my character get killed by an Ant Man for the very first time…
I’ve decided to make monsters functionally identical to players. In the original LOD, players had one type of “user record” whereas monsters had a specialized “monster record”. This was a two-fold problem: 1) Player vs Player combat had to be special cased from Player vs Monster combat and 2) Monsters could be customized as much as a player. This was done to save memory back in the old DOS days.
In NETLOD, players and monsters are very nearly the same. This means as soon as I get Player vs Monster combat working, Player vs Player combat ought to fall right out of the general case — very nice.
I also ended up rewriting some parts of the player management code. Before I was loading players to and from disk on demand and this took up just too much system resources. I switched to a cached method where player records (and monster records) are automatically read-cached and delay-written. This improves performance significantly.
I decided to up the map window size from 5×5 to 7×7. This is about double the area (49 square cells vs 25 square cells). IMO, it looks much better and makes LOD seem more like a graphical game than a text game. The drawback of course is slower refresh from the server and more draw time on the client.
Also, I’ve made the tough decision of reducing the standard inventory items from 18 to 16. The reason being that I really want the inventory display to fit in two rows in an 800×600 display. With 16 items, I can do a table of 8×2. With 18, I had to do a table of 6×3, which really ate up some of our vertical real estate.
A note about file formats
I’ve adopted a file format very similar to the windows INI format. In fact, it is probably identical. This file format is used for everything — monsters, players, devices, etc. There are several advantages to this:
- ASCII formats are system independent — a base 10 number always looks the same, as opposed to binary formats where we get big-endian vs little-endian, 32-bit vs 64-bit, floating point problems, etc. The Internet people have realized this and that’s why many Internet protocols (SMTP, NNTP, POP, HTTP, etc) are in text.
- Windows has support built in for this format, so I can throw together a simple player editor, device editor, etc for Windows. I’ve also written my own interface routines for the INI files, so that everything will work in Unix.
- It’s extensible. We can add new INI sections and still maintain backward compatibility.
- It’s self describing. The INI sections and tags name the data items, so a generic editor can probably be written very easily.
The problems with any ASCII based format are of course space and parsing. A binary number is a very compact representation, but a base-10 ASCII string is not. CPU power needs to be dedicated to converting between the two. I believe that this will not be a problem as we just don’t do IO that often.
NETGalwar?
People have been asking me for a net version of Galactic Warzone. Heck, why not — if NETLOD works, then maybe I’ll give it a shot. I don’t see much of a way to “modernize” GW, but for those two really want to play classic GW, I’ll see if I can try something. I don’t think it’ll take much time to do, but I am backlogged on projects, so look for it around January, 2001.
Dec 13, 1999: Medkits and Rations Working
Anxious to get started on the combat module, I’ve implemented medkits and rations so there’s at least some way to heal your character! Implementing these simple items was not difficult in and of itself, but there was some infrastructure that needed to be figured out for the general “use an item” system.
Basically, each item will have an HTML page that is displayed when you want to use it. That way, if a dataset designer wants to create a custom item, then he/she can create a custom html page and have some pretty decent control over what things look like.
My provider got the routing problem with the IP addresses fixed, so the website is now online and working reliably.
Dec 12,1999: Gterm, Combat
Been working on some of the display issues with GTerm. The window can now be resized and all the controls scale accordingly. IMO, It doesn’t look quite right yet, but I’m still working on it… I’ve considered raising the default map window size from 5×5 tiles to 7×7 tiles. The obvious advantage is double the viewpoint area (49 squares vs 25 squares). The disadvantage is more on-screen real estate being used up, and of course slower refreshes from the server.
My designs for the combat system are coming along well, and I’m anxious to begin work on that aspect of the game. Once combat is implemented, we’ll have something that is actually “playable” at some level. Getting the basics done for combat should only take about two weeks if I don’t get distracted, so I’m setting a preliminary goal of Christmas. Then the first public beta ought to be ready first week of January.
DNS is now configured for the website, but I’m getting some intermittent routing problems with the latest block of IP addresses my provider gave me, so the site is on hold until monday….
On a side note, I received Ultima9 in the mail yesterday and briefly started playing it — unfortunately, my 450MHZ-PIII, 128MB ram, and 16MB Matrox MGA400 aren’t up to the task of handling the graphics of this beast, and I’m going to have to either wait until Origin gets their D3D patch out or I buy some better (?) hardware. On the positive side, the game also included Ultima 1-8, some of the best RPGs ever written.
Dec 8, 1999: Getting the Site Ready
I’m working on setting up the site ready to go online today. The domain landofdevastation.com is already in use. In the interests of getting my site online quickly, I’ve registered both land-of-devastation.com and landofdev.com. As soon as I get DNS setup, I’ll be putting it online.
Dec 7, 1999: Game Progress
Any RPG can be divided into various “modules” that comprise various aspects of the game. I consider the following to be the logical divisions:
- Map: Let the player move around in the compass directions and via the pylon navigation system.
- Inventory: Be able to buy, sell, equip, drop, and get items.
- Invocation: Be able to use the objects — what does a medkit do? What do rations do?
- Player: Remember who the player is, his attributes, location, and be able to log him in and out of the system.
- Combat: Where the action takes place — be able to kill anything and everything you encounter in the game.
Right now, the map and inventory systems are pretty much complete. You can move around the world and distribute inventory items with glee. I’ve started in on the player system so that we can log different people in and out.
The invocation and combat systems will prove to be the most difficult and time consuming. LOD has over 50 different kinds of objects. Various parameters expand these 50 basic types into over 350 different objects. I’ll start with simple things such as medkits and rations. Complicated things like the hypervault and waypoint manager will probably be last. Fortress devices are being completely thrown out in favor of a complete redesign of the fortress system. Weapons and other combat items will be implemented when I implement the combat system.
Dec 4, 1999: Ramblings on Combat
I’m still working up a design of the combat system. I intend it to be “modeless” in the sense that you’re never really in a specialized combat mode. In classic LOD, you enter combat mode and you fight until either you or the monster is dead. In Net-LOD, I want there to only be one mode — the “wandering the wastelands” mode. If you encounter a monster, you can shoot at him, but you can also pick up and drop inventory, walk(run?) away, log out, or whatever.
So what are the complications?
- How do turns work? I don’t like realtime combat, so we’re not going to do that. I suppose the monster will be “paused” until you make a move, then it is free to hit you. Then the monster will be paused again until you make your turn.
- How does this work with multiplayer interaction? If we have players A, B, and a monster M, do the turns go A,M,B,M, or A,B,M, or what?
- What if two online players are competing and one of them is “slow”. Does the fast player have to wait for the slow player, or does the slow player forfeit his turn if not completed fast enough?
- What about long range vs short range weapons? I have some ideas here — all combat will start with a monster at least 1 square away from you. If you maintain this one square distance, then either you or the monster may use LR weapons. However, if you and the monster should move into the same square, then you must use SR combat.LR weapons will impose a cycle delay whereas short range weapons can be used immediately. For example, it may take 3 turns for your Plasma Rifle between shots. Otherwise, people might be tempted to vaporize some poor monster with repeated LR shots when the monster can’t get close enough for hand-to-hand combat.
- What happens if you successfully evade a monster by walking/evading him? Does he stay there for a while?
- When multiple players fight a monster, who gets the experience points? The person who makes the final kill-shot?