October 2001
- (no subject) J C Lawrence
- Lum the Mad is closing--sort of Koster, Raph
- Questing (was: Request for ideas) Eli Stevens
- Questing (was: Request for ideas) Joe Andrieu
- Questing (was: Request for ideas) Matt Mihaly
- Questing (was: Request for ideas) Sellers, Mike
- Questing (was: Request for ideas) Vincent Archer
- contract games/markets (was: Request for ideas) Bruce Mitchener
- DEV: Peer-to-Peer MUD Phil O'Donnell
- DEV: Peer-to-Peer MUD Dan MacDonald
- DEV: Peer-to-Peer MUD Robin Lee Powell
- DEV: Peer-to-Peer MUD Justin Rogers
- DEV: Peer-to-Peer MUD Adam Martin
- DEV: Peer-to-Peer MUD Frank Crowell
- Psychology and game design (Was Geometric content generation) John Hopson
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Dave Rickey
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) Matt Mihaly
- Psychology and game design (Was Geometric content generation) Ola Fosheim Grøstad
- Psychology and game design (Was Geometric content generation) rayzam
- in-game vs web-based boards (was: Geometric content generation) Freeman, Jeff
- State of the RP: Verant's attempt at a RP Server Eric Rhea
- New MMP Networking Architecture Lee Sheldon
- New MMP Networking Architecture Adam Martin
- New MMP Networking Architecture Bruce Mitchener
- New MMP Networking Architecture Ling Lo
- New MMP Networking Architecture Norman Nunley, Jr.
- Mucking about in time Eli Stevens
- Mucking about in time Travis Casey
- Mucking about in time Adam Martin
- Mucking about in time John Robert Arras
- Many MUDs in one? (was: Geometric content generation) Ian Collyer
- Many MUDs in one? (was: Geometric content generation) Matt Mihaly
- Many MUDs in one? (was: Geometric content generation) Robin Lee Powell
- Pueblo still kicking Jon Lambert
- FWD: Call for papers: AAAI symposium on AI and Interactive Entertainment Robert Zubek
- Game Theory Introduction Ling Lo
- MUD-Dev digest, Vol 1 #438 - 22 msgs Phil O'Donnell
- Uniqueness of Games Adam Martin
- Uniqueness of Games Ling Lo
- Psychology & Player Motivation (was Geometric Content Generation) Sasha Hart
- Simulation, just how much? (was: Uniqueness of Games) Derek Licciardi
- Laws of Competition Matt Mihaly
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Brian Hook
- UDP Revisted Bobby Martin
- UDP Revisted Brian Hook
- UDP Revisted Dave Rickey
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Dave Rickey
- UDP Revisted Travis Nixon
- UDP Revisted Amanda Walker
- UDP Revisted Brian Hook
- UDP Revisted Ben Greear
- UDP Revisted amanda@alfar.com
- UDP Revisted Brian Hook
- UDP Revisted Travis Nixon
- UDP Revisted Daniel.Harman@barclayscapital.com
- UDP Revisted Travis Nixon
- UDP Revisted David H. Loeser Jr.
- UDP Revisted Adam Martin
- UDP Revisted Bobby Martin
- UDP Revisted Bobby Martin
- UDP Revisted Kwon Ekstrom
- UDP Revisted Bruce Mitchener
- UDP Revisted Bobby Martin
- UDP Revisted Bruce Mitchener
- UDP Revisted Daniel.Harman@barclayscapital.com
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Brian Hook
- Procedural content generation John Buehler
- Procedural content generation Hans-Henrik Staerfeldt
- Procedural content generation lhulbert@hotmail.com
- Procedural content generation Travis Nixon
- Procedural content generation Ola Fosheim Grøstad
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Daniel.Harman@barclayscapital.com
- Procedural content generation Freeman, Jeff
- Procedural content generation Matt Mihaly
- Procedural content generation Ola Fosheim Grøstad
- Simulation, Christopher Allen
- Simulation, Travis Casey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Kennerly
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Robin Lee Powell
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Brian Hook
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Daniel.Harman@barclayscapital.com
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Vincent Archer
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Derek Licciardi
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) John Buehler
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dave Rickey
- MMORPG Comparison (UO, EQ, AC, AO, DAoC) Dan Burke
- Simulation, Adam Martin
- UDP Revisited Daniel.Harman@barclayscapital.com
- UDP Revisited Brian Hook
- UDP Revisited Mats Lidstrom
- UDP Revisited Jeremy Gaffney
- Simulation Revisited Dave Rickey
- TCP Vegas Adam Martin
- Procedural content generation, randomness Adam Martin
- Procedural content generation, randomness Brian Hook
- Content authorship Adam Martin
- Content authorship Ola Fosheim Grøstad
- Content authorship Travis Casey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Eli Stevens
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Dave Rickey
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Ola Fosheim Grøstad
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Robin Lee Powell
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Daniel.Harman@barclayscapital.com
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Neufeld, Don
- DAoC dev team (was: MMORPG Comparison (UO, EQ, AC, AO, DAoC)) Brian Hook
- DAoC dev team Dave Rickey
- SSL vs. SASL (was: UDP Revisted) Bruce Mitchener
- MUD-Dev digest, Vol 1 #445 - 27 msgs Paul Schwanz
- MUD-Dev digest, Vol 1 #445 - 27 msgs Travis Nixon
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Freeman, Jeff
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Koster, Raph
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Koster, Raph
- Proposed Law Ola Fosheim Grøstad
- Proposed Law Jon Lambert
- Proposed Law Paul Schwanz
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Paul Schwanz
- Proposed Law Madman Across the Water
- Proposed Law Travis Nixon
- Proposed Law Mark Eaton
- Proposed Law Sami Kosonen
- Proposed Law Madman Across the Water
- Proposed Law Andrew Hefford {Coregen}
- Proposed Law Dan Burke
- Proposed Law Matt Mihaly
- Proposed Law John Buehler
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Proposed Law Ian Collyer
- Proposed Law Matthew Estes
- Proposed Law Matt Mihaly
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Ola Fosheim Grøstad
- Proposed Law John Buehler
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Adam Martin
- Proposed Law Matt Mihaly
- Proposed Law Paul Schwanz
- Quality Testing Michael Tresca
- Quality Testing John Buehler
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Nathan F. Yospe
- Quality Testing Michael Tresca
- Quality Testing Koster, Raph
- Quality Testing Dave Rickey
- Quality Testing Dave Rickey
- Quality Testing Derek Licciardi
- Quality Testing Dave Rickey
- Quality Testing Michael Tresca
- Quality Testing Dave Rickey
- Quality Testing Jeff Cole
- Quality Testing Robin Lee Powell
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing J C Lawrence
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Dave Rickey
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Michael Tresca
- Quality Testing Daniel.Harman@barclayscapital.com
- Quality Testing Paul Dahlke
- Quality Testing Dave Rickey
- Players Controlling Monsters rayzam
- High Level Architecture Adam Martin
- Networking architecture overview Brian Hook
- Networking architecture overview Dave Rickey
- Networking architecture overview Brian Hook
- Networking architecture overview Amanda Walker
- Networking architecture overview Brian Hook
- Networking architecture overview Bobby Martin
- Networking architecture overview Daniel.Harman@barclayscapital.com
- Connection Stats Ben Tolputt
- MUD-Dev digest, Vol 1 #443 - 12 msgs Dr. Cat
- Fourteen forms of fun Ola Fosheim Grøstad
- Fourteen forms of fun rayzam
- Fourteen forms of fun Sasha Hart
- Fourteen forms of fun Jon Lambert
- Fourteen forms of fun David H. Loeser Jr.
- Fourteen forms of fun Matt Mihaly
- Fourteen forms of fun Ola Fosheim Grøstad
- Incorporating Plot/Backstory/Scenario Design Tools Nathan F. Yospe
- Extreme Programing Ling Lo
- DAoC dev team Lars Duening
- Documentation Adam Martin
- Documentation Brian Hook
- English grammar thoughts Par Winzell
- English grammar thoughts Kylotan
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Jasper McChesney
- English grammar thoughts bruce@puremagic.com
- English grammar thoughts Marian Griffith
- English grammar thoughts Travis Casey
- English grammar thoughts Robert Zubek
- English grammar thoughts Robert Zubek
- English grammar thoughts Travis Casey
- English grammar thoughts Chris Gray
- English grammar thoughts Jon Leonard
- ADMIN: The code documenting/commenting thread J C Lawrence
- Players Controlling Monsters David H. Loeser Jr.
- Players Controlling Monsters Brian Hook
- Players Controlling Monsters John Buehler
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Freeman, Jeff
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Derek Licciardi
- Expectations of in-game reality Lars Duening
- Expectations of in-game reality Paul Schwanz
- Expectations of in-game reality Nip
- Expectations of in-game reality Ian Collyer
- Expectations of in-game reality Adam Martin
- Expectations of in-game reality Michael Tresca
- Expectations of in-game reality J C Lawrence
- Expectations of in-game reality Matt Mihaly
- Expectations of in-game reality Daniel.Harman@barclayscapital.com
- Expectations of in-game reality Eli Stevens
- Expectations of in-game reality Marian Griffith
- Expectations of in-game reality Travis Casey
- Expectations of in-game reality Sami Kosonen
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Lee Sheldon
- Respecting NPCs J C Lawrence
- Respecting NPCs Sami Kosonen
- Respecting NPCs Travis Nixon
- Respecting NPCs Matthew Estes
- Respecting NPCs Chris Gray
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Michael Tresca
- Respecting NPCs Freeman, Jeff
- Respecting NPCs Travis Nixon
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Michael Tresca
- Respecting NPCs Daniel.Harman@barclayscapital.com
- Respecting NPCs rayzam
- Respecting NPCs Joe Andrieu
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Joe Andrieu
- Respecting NPCs Michael Tresca
- Respecting NPCs Adam Martin
- Respecting NPCs Lee Sheldon
- Respecting NPCs T.A.J.BARTON
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Adam Martin
- Respecting NPCs Madman Across the Water
- Respecting NPCs Travis Nixon
- Respecting NPCs J C Lawrence
- Respecting NPCs John Buehler
- Respecting NPCs lazarus@ourplace.org
- Respecting NPCs Colin Coghill
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs J C Lawrence
- Respecting NPCs Phillip Lenhardt
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs J C Lawrence
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Bruce Mitchener
- Respecting NPCs Norman Nunley, Jr.
- Respecting NPCs J C Lawrence
- Respecting NPCs Brian Hook
- Respecting NPCs J C Lawrence
- Respecting NPCs gamaiun@yahoo.com
- Respecting NPCs Ola Fosheim Grøstad
- Respecting NPCs Matthew D. Fuller
- Respecting NPCs Timothy Dang
- Respecting NPCs gamaiun@yahoo.com
- TECH : RMI (was UDP Revisted) Daniel.Harman@barclayscapital.com
- TECH : RMI (was UDP Revisted) Bobby Martin
- Chatbots Adam Martin
- TECH: UDP Revisted Bobby Martin
> From: Bruce Mitchener <bruce@puremagic.com>
> Bobby Martin wrote:
>>> From: Bruce Mitchener <bruce@puremagic.com>
>>> I was curious as to what sorts of advanced features you had in
>>> ARMI and the documentation didn't really go into much detail
>>> beyond some usage notes.
>>> Do you have any support for pipelining of requests?
>> No, although TCP (which I currently use) buffers packets for up
>> to 200 ms before it sends the buffer.
> Mmmm, this isn't quite what I was thinking about when I wrote
> that.
I was hoping it wasn't, but I couldn't figure out where you were
going so I just took a shot in the dark ;)
> If I fire off 3 message sends in a row, and TCP is the transport
> in use, what happens? Do all 3 get sent to the remote end right
> after each other and then responses are returned, tagged with some
> request identifier as they happen? Is there an ordering imposed
> on the return of requests? (Say that you send off messages 1 and 3
> to object A, and message 2 to object B. Object B takes a long
> time in responding. Does that delay the return of the result for
> #3?)
There is no 'order of reply' imposed. To impose such an ordering
would throw away a lot of the gains you make by using asynchronous
method calls. You get a response as fast as the little packet can
make his way back to you. :)
> Or, similar to that, what happens if one method call returns a
> very large bunch of data. Will that hold up following method
> sends, or do you break data into chunks similar to what BEEP and
> HTTP/1.1 can do to multiplex a single channel?
I'm not sure how to answer this one. If the Socket's output stream
is feeding you a large block of return data on one thread while you
try to send a block of message data to the input stream on another
thread, it just gets handled however Java Sockets handle it. I
haven't done anything special.
For UDP, once again, currently we don't do anything special. A
block of return data that big was probably thrown away anyway since
UDP is very bad at handling large blocks of data. Currently our UDP
implementation is _very_ naive; it just sends whatever blocks you
send it and assumes they get there. I suggest only using it for
small packets for which guaranteed delivery is not required, like
object position updates.
> Finally (for now :)), do you share the transport connection, or do
> you establish new ones frequently (like per-object, per-method
> send, etc)?
For UDP, all comms happen over one port. In TCP, there is one
connection per client, and that one connection is re-used for all
objects & method calls on that client. Later, the guaranteed
delivery & ordering calls will also all happen over one port.
> But, on the point that you brought up, do you have control over
> that 200 ms buffering from Java? (To turn off nageling or whatever
> you might want to change.) Is the 200ms delay proving troublesome
> at all? That seems like a fairly high penalty to pay in terms of
> latency for any distributed communication.
Java Sockets don't allow changing the delay, but they do allow
turning nagle's algorithm. I currently don't do that and the Cosm
clients & server seem to communicate in a quite timely fashion. It
is easy for you to manipulate the Sockets if you like (although
right now it would require changes to the ARMI source, which is
open).
>>> How about for monitoring message traffic or requests for
>>> debugging, checking load balancing, etc?
>> Currently in the works, but not there right now.
> What sort of stuff is in the works? :)
Number of bytes per second per client, number of bytes total per
client, ping time. The number of bytes is also separated by input &
output. Henke, the programmer working on the monitoring, tells me
that it's done. I haven't seen the code yet.
>>> What sorts of security or authentication do you support?
>> Currently, none :( It is fairly trivial to add an encrypting
>> message filter, though. You can filter messages that you send
>> any way you like.
> What sort of model are you thinking about though? Is this mainly
> for communication between trusted peers? Or might it be used in a
> more hostile environment with foreign (or user-written) code
> involved?
I intend to use it in Cosm which is a hostile environment since I
expect the users to try to crack the server.
My plan for security was actually on top of ARMI rather than part of
it, though. To log in, the user's client requests a token from the
server. The server remembers what token it sent. The client
encrypts the token with the user's password, and that token is sent
back with the login request. The server encrypts the token it sent
with the user's password and compares that with what it got back,
and if they match, the login is successful.
I hadn't thought too much about hijacked connections, but we can
periodically reply to a message and break the connection if there is
consistently no response or a response that indicates that the TCP
originator didn't really send the message.
If you like, you could tunnel all the ARMI messages over an SSL
connection pretty easily. I will test that at some point but I
expect it to use up enough CPU that I won't go that route. I will
probably leave the filter in CVS for others to use, though.
>>> Can you compare your packing overhead to that of RMI or other
>>> systems? Do you compress your datastreams?
>> We don't currently formally compress data streams. I have done
>> some sampling of RMI throughpuut versus ARMI throughput; ARMI was
>> about 10 times smaller for the method calls I tested. This
>> definitely needs more formal testing.
> and later in your post, but moved here for ease in replying ...
>> I have implemented production compression systems before, and I
>> can tell you that you will almost certainly need tailor made
>> compression (i.e. just write clever serialization code) for any
>> significant gains. Lots of small information packets are hard to
>> compress, unless you take large production runs and analyze them,
>> then compress assuming the usage patterns don't change too much.
>> Most compression mechanisms require that every block of data you
>> compress has a table describing how to decompress it, and for
>> small blocks the table takes up more space than the amount you
>> gain by compressing. If you analyze large production runs of
>> data, the tables can be static and just sit on either end of the
>> connection.
> With respect to serialization strategy being more important than a
> traditional compression algorithm, I definitely agree. Brad
> Roberts and I made some changes to Cold about 2-3 months ago that
> changed how we serialized some bits of data and objects for
> storage into the DB. Those changes managed to take a DB that was
> roughly 2G and drop it to about 1.6G in size, which was quite
> nice. (It also had the interesting impact of reducing our
> fragmentation of free space on disk as more objects were now small
> enough to fit in the minimum block size, consuming more of bits of
> free space floating about that previously used to just contribute
> to wasted space. Those gains aren't accounted for in the numbers
> that I gave above.)
> Regarding throughput, you say that messages were smaller. Were
> the round-trip times also less? Or roughly similar?
I'm sorry, I don't have data on that. That's a darn fine thing to
add to our performance monitoring tool, though, and we will make it
so.
I intend to get all this data on some simple RMI vs ARMI and put the
comparisons up as documents in the ARMI project.
One thing to note is that since ARMI uses ids instead of fully
qualified names to refer to class and method names, the first call
to a method will be much slower than later calls. This is because
the client must ask the server what those ids mean the first time it
gets them, and the answer is the fully qualified name. This little
exchange makes ARMI slower than RMI for the initial method call, I'm
sure.
Also, we have ourselves slated to write an armic. Right now, all of
the method call translation happens dynamically, which is very
flexible but not the speediest thing in the world (although,
frankly, we don't see the slowdown in Cosm). We will write an armic
that examines each class to be shared and writes explicit proxy &
skeleton code as a compile time action instead of run-time.
>>> Any more information to explain in more detail how/why ARMI is
>>> great is welcome. :)
>> Offhand I don't know what I can tell you about why ARMI is great
>> that isn't listed on the web site. Main attributes are:
>> 1) Your method calls can be asynchronous (your app doesn't stop
>> and wait for the return value from a method call until you need
>> the return value.)
> Will you provide some higher level support to be used by a caller
> of an asynchronous method to help deal with the failure cases that
> might result, or any sort of syntactic sugar/glue to help deal
> with the complexities that arise from a more asynchronous model?
Yes, we will be changing from a 'use the message id to request
waiting for the return value' model to a 'just ask for the return
value from the returned ReturnValue object' model soon. We will
also probably support exceptions 'returned' and timeout returns when
the message is lost, but that is not planned soon. The ReturnValue
should be put in within the next couple of weeks, I think.
> Some cool work in this that has been done is in the E programming
> language. (Disclaimer: that work probably is from predecessors to
> E, but that was my first exposure to this and I can't credibly
> cite which predecessor it might have been.)
[SNIP a bunch of cool E stuff]
I hadn't seen this before; superficially it looks very similar to
what I'm doing with ReturnValue. I will examine it further and see
if there's more that I can steal from them.
>> 2) I use ids for the class and method instead of the huge
>> descriptors that RMI uses.
> Does that change the security profile of your protocol at all?
> (Is there a good reason that RMI uses large descriptors?)
I don't see how it would. And I can't imagine why RMI uses large
descriptors, except maybe to cut the cost of those first few method
calls. Oh yeah, for Cosm, the methods called won't change very
often. I will put those in a text file so both sides can know about
the class/method <-> id mapping and thus bypass the exchange on the
first call. This will be optional for other ARMI users.
>> 4) <not implemented yet> You can choose whether a method call
>> is guaranteed or not. Currently you either use UDP for
>> transport and all method calls are non-guaranteed but fast, or
>> you use TCP for tranport and all method calls are guaranteed
>> but slower (but still much faster than RMI).
> How will you do this? Will it be something that is decided at a
> method call site? Or will it be per-method (and globally
> decided)? If the latter, will you have some sort of IDL that
> provides that info, a registration process, or something else?
It will be per-method, with an optional XML configuration file that
tells which methods should be non-guaranteed. There may also be a
per method-call method that makes the next method called on that
thread non-guaranteed, but I don't personally have a need for that. - The function of NPCs in novels versus MUDs Ola Fosheim Grøstad
- RE: Koster, Raph
- RE: Joe Andrieu
- RE: Marian Griffith
- RE: gamaiun@yahoo.com
- RE: Daniel.Harman@barclayscapital.com
- Violence Matt Mihaly
- Quality Testing (and community) Ola Fosheim Grøstad
- ADMIN: Recent outages J C Lawrence
- [ECOSYSTEMS] Fishing in the real world Adam Martin
- [ECOSYSTEMS] Fishing in the real world Daniel.Harman@barclayscapital.com
- [ECOSYSTEMS] Fishing in the real world Hans-Henrik Staerfeldt
- [ECOSYSTEMS] Fishing in the real world Ian Collyer
- [ECOSYSTEMS] Fishing in the real world Dave Rickey
- Statistics Ben Chambers
- Statistics Eli Stevens
- Statistics Adam Martin
- Statistics Hans-Henrik Staerfeldt
- Statistics John Buehler
- Statistics Ben Chambers
- Statistics Ben Chambers
- Statistics Travis Casey