On 4/4/2012 1:06 PM, Miles Fidelman wrote:
BGB wrote:
On 4/4/2012 9:29 AM, Miles Fidelman wrote:
- game-like simulations (which I'm more familiar with): but these
are serious games, with lots of people and vehicles running around
practicing techniques, or experimenting with new weapons and
tactics, and so forth; or pilots training in team techniques by
flying missions in a networked simulator (and saving jet fuel); or
decision makers practicing in simulated command posts -- simulators
take the form of both person-in-the-loop (e.g., flight sim. with a
real pilot) and CGF/SAF (an enemy brigade is simulated, with
information inserted into the simulation network so enemy forces
show up on radar screens, heads-up displays, and so forth)
For more on the latter, start at:
http://en.wikipedia.org/wiki/Distributed_Interactive_Simulation
http://www.sisostds.org/
so, sort of like: this stuff is to gaming what IBM mainframes are to
PCs?...
Not so sure. Probably similar levels of complexity between a military
sim. and, say, World of Warcraft. Fidelity to real-world behavior is
more important, and network latency matters for the extreme real-time
stuff (e.g., networked dogfights at Mach 2), but other than that, IP
networks, gaming class PCs at the endpoints, serious graphics
processors. Also more of a need for interoperability - as there are
lots of different simulations, plugged together into lots of different
exercises and training scenarios - vs. a MMORPG controlled by a single
company.
ok, so basically a heterogeneous MMO.
reading some stuff (an overview for the DIS protocol, ...), it seems
that the "level of abstraction" is in some ways a bit higher (than game
protocols I am familiar with), for example, it will indicate the "entity
type" in the protocol, rather than, say, the name of, its 3D model.
however, it appears fairly low-level in some ways as well, using
magic-numbers in place of, say, "entity type names", as well as
apparently being generally byte-oriented.
in my case, my network protocol is currently based more on the use of
specially-compressed lists / S-Expressions (with the compression and
"message protocol" existing as separate and independent layers).
the lower-layer is concerned primarily with efficiently and compactly
serializing the messages, but doesn't concern itself much with the
contents of said messages. it is list-based, but theoretically, also
supporting XML or JSON wouldn't likely be terribly difficult.
the upper-layer is mostly concerned with the message contents, and
doesn't really care how or where they are transmitted.
I originally considered XML for the message protocol, but ended up
opting with lists as they were both less effort and more efficient in my
case. lists are easier to compose and process, generally require less
memory, and natively support numeric types, ...
most entity fields are identified mnemonics in the protocol (such as
"org" for origin, "ang" for angles or "rot" for rotation). entity types
are given both as type-names and also as names for 3D models/sprites/...
I personally generally dislike the use of magic numbers, and in most
cases they are avoided. some magic numbers exist though, mostly in the
case of things like "effects flags" and similar (for stuff like whether
an entity glows, spins, ...).
however, this doesn't mean that any strings are endlessly re-sent, as
the protocol will compress these (typically into single Huffman-coded
values). note that recently encoded values may be reused.
beyond entities, things like geometry and light-sources can also be
synchronized.
nothing obvious comes to mind for why it wouldn't scale, would probably
just split the world across multiple servers (by area) and have the
clients hop between servers as needed (with some server-to-server
communication).
probably, free-form client-to-client messages would also make sense, and
maybe also the ability to broadcast messages more like in a chat-style
system. this way, specialized clients could devise their own specialized
messages.
(currently, I am not doing anything of the sort, mostly focusing more on
small-scale network gaming).
...
(if by any chance anyone wants code or specs for any of this stuff, they
can email me off-list...).
I had mostly heard about military people doing all of this stuff
using decommissioned vehicles and paintball and similar, but either way.
I guess game-like simulations are probably cheaper.
In terms of jet fuel, travel costs, and other logistics, absolutely.
But... when you figure in the huge dollars spent paying large systems
integrators to write software, I'm not sure how much cheaper it all
becomes. (The big systems integrators are not known for brilliance of
their coders, or efficiencies in their process -- not a lot of 20-hour
days, by 20-somethings betting on their stock options. A lot of good
people, but older, slower, more likely to put family first; plus a lot
of organizational overhead built into the prices.)
fair enough.
probably not as much need to emphasize graphics though, since it
probably isn't really being sold as much on its "photo-realism" and
similar, unlike a lot of commercially-made games?...
so, less work for the graphics artists and 3D artists and similar to do.
(nevermind work recreating various geographic locations or similar...).
then again, maybe some of this could be assisted with satellite photos
and stand-ins and similar, sort of like with "Google Earth" or similar?...
or such...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
