Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Game Play & Game Design / Re: Pathfinding on: 2003-12-31 11:50:19
Yeah, I'll try to keep em shorter from now on Smiley

I edited the last post to make it more clear. The articles I was refering to in the last paragraph are in those Game Dev Gems books or AI Game Wisdom. I can find the specific details if you are so inclined. Thanks!

2  Game Development / Game Play & Game Design / Re: Pathfinding on: 2003-12-30 20:21:43
Waypoints can make all the difference. Using multiple pathfinding techniques will almost certainly get you both the most accurate and fastest possible path.

For instance, you can have way points that connect all "rooms" together and use something like Dijkstra's (sp) algorithm to search between them. Then you can use a 2d array to build a table of the fastest way between these points. This table would be generated when the level is generated and saved as part of it. I can explain this in more detail if you are interested. I have a sample Flash app I wrote that illustrates this too. I can dig it up if you want it (it was just a prototype, so don't expect much Wink).

To handle pathfinding within a room, you would still use A* but for cross-room pathfinding, you could use the way points. Using the two of these together can give you some fast and natural looking paths.

The problem then is handling collisions with other characters. A* is really good at a changing environment and way points are not unless you re-calculate paths between them when things change.

There are several articles about mixing algorithms in the Game Developer Gems books by Charles River (I own every one of those books and recomend them to everyone interested in this stuff). Don't miss the AI Game Wisdom book either. If you need the specific article, let me know and I can tell you the book and chapter title.

For some other interesting reading in those books, hit the articles by the BioWare guys about "depth of field/area of concern" stuff and the Ensable Studio guys about determining threats and LoS on a tile-based map.


[edit: fixed a typo + made last paragraph more clear ]
3  Game Development / Networking & Multiplayer / Re: Data send format on: 2003-12-30 18:27:05
If much of the data is static then you could use XML to describe the map and then send an object of the dynamic data. This way you can maintain all the static maps via a convenient format. We do this using XML so we can have a simple editor generate "zones" or levels. This also lets you fine-tune levels or areas by hand if you want to.

If transmission speed is an issue, then you can simple "Zip" the XML using the Java libraries and be done with it.

If the data isn't static, DON'T USE XML Smiley I can't stand how so many projects use XML where is just doesn't make sense.

4  Game Development / Networking & Multiplayer / Re: Would Jboss and EJB be usefull ? on: 2003-12-30 18:20:13
JBoss isn't known for performance, so I imagine that would be a problem and I am hard pressed to see a need for EJB on a game. My experience with EJB has typically been pretty bad. The only exception would be MDB (Message Driven Beans) which work wonders. One thought though about MDB and JMS in general. If you have data that HAS to be updated in the database but isn't terribly time sensitive or can be delayed a little bit, why not throw it in a queue?

I mean think about it, you are running along the ground in your multi-player, tile-based world and suddenly get disconnected. You lose 20 minutes of game data in one shot. Crap! If the game were to set up to request a position save every 1 minute or some such and that request sits in a queue until serviced, you could easily tune the load on your database by increasing or decreasing the number of MDBs listening on that queue.

This is just one example, but queueing can be VERY useful for places where time isn't so important but it HAS to work.

I have used a similiar technique for several enterprise projects I have worked on where data had to be written to the database and we didn't want to consume all the processor of the server with it at one time. So we trickled out the updates based on CPU load. You would dump it in the queue and as CPU became available, we would then do some work.

Have fun!

5  Game Development / Networking & Multiplayer / Re: Manage Clients on serve side with java.nio on: 2003-12-30 17:52:25
Hello! I am new to this board and dang, I wish I knew about it a year ago! I suspect I will be back often Smiley

I saw this thread and wanted to speak up a bit. In Java 1.4+ it is fully possible to create a very powerful and scalable server.  Java NBIO is more then capable but the documentation is simply terrible. Many of the examples of NBIO online are very poor to say the least. Also, there were several cross-platform JDK bugs that are just now resolved (I believe).  Personally, I found NBIO to be quite confusing as well but that might be just me.

With much help from Ron Hitchens (author of the O'Reilly Java NBIO book) our chat server has been load tested to 5000 concurrent connections on Windows 2003 Server.  At that point, the OS simply started blocking all inbound connections (never really figured out why either).

After three unique versions of the server, the key learnings for a high performance server are pretty simple and really boil down to these two things:

1. You need to use NIO to managed all the incoming and outgoing data. We use a single thread to constantly poll everyone for incoming messages. Every connected client has a buffer they store partially completed messages in that is drained when a message terminator is received.

2. Use a thread pool to handle dealing with every transaction from the clients. If you think about it, each message from a client is a discrete unit of work. To that end, our server has a mapping of all types of transactions it handles. We take a message from the client and a worker thread then determines which handler users it, executes the handler, disposes of the message, and returns to the pool.

We have played with several other threading models from 2 threads per user (one for inbound data and one for outbound data) to a thread per room. Thread per room works pretty well, but can lag pretty bad when you get into lots of messages in a room. Private messaging of users cross rooms gets really messy too. The two threads per user option is by FAR the simplest but also the least scalable. It seems to crap out at about 300 or so users and the memory usage gets pretty extreme.

Be extremely careful with synchronization. This is by far the biggest problem we have. We are STILL squashing synchronization bugs where we get a deadlock on a single thread in the pool and things become unstable. It's very hard to isolate.

To handle room level messaging, you simply need to ensure the Room on the server knows all Clients inside of it. Then the room has a method like "sendMessageToRoom()" to iterate over the clients and send a specified message to them.

To handle private messaging, we use the username as a key in a HashMap at the chat server level. If you want to send a message to someone, you simply ask the server to look up the Client object from the HashMap and use the sendMessage() method on the client. This seems to work pretty well. The downside of the using a username as a key is that you have to "log in" first. The user doesn't have a username until after it connects AND logs in. This means that if you need to reference or message a user before they logged in, you have to provide another means for locating them. We handle this by requiring that login be the very first transaction called before all others. Anyone that breaks this rule is disconnected immediately. We also have a clean-up thread that disconnects people that have connected but not logged in after a configurable period.

Thus far everything described is completely protocol agnostic. Everything we do uses TCP entirely. A single channel between client and server. I suppose we could use a second channel via UDP or some such like many games but thus far it hasn't been much of an issue and so we haven't explored it too far.

To make it worse, we actually use XML as the format for all messages. I'm sure some of you are cringing, but hear me out. We have a very high performance and lightweight (interpret this as VERY SIMPLE Smiley) parser that we use on the server. This has proven to work great and be nice and simple for clients in multiple programming languages. In the next release of the server, we will support replacing this with a message interpreter of chose based on an interface. This will allow people to use more effecient message formats at the expense of simplicity.

bmyers mentioned the idea of using JMS. We found this intriguing and played around with it about a year ago. We used dynamic topics for rooms and it works pretty well but the machinery to handle keeping track of who and what was where became quite a chore. In the end, it proved overly complicated and performance heavy due to all the J2EE code involved. BUT, this might be a perfect solution depending on the requirements of a given game. One thing to keep in mind is that if this is an application on their machine or a signed applet, you can actually run the JMS server on each users machine to provide direct access between users in a P2P style configuration...

Woah! I just looked back at what I wrote and realized this this has become a rather lengthy tome Smiley ! Sorry about that, I hope this was helpful to someone! Feel free to contact me with any questions.

Mike Grundvig
Electrotank, Inc.
Pages: [1]
EgonOlsen (59 views)
2018-06-10 19:43:48

EgonOlsen (42 views)
2018-06-10 19:43:44

EgonOlsen (61 views)
2018-06-10 19:43:20

DesertCoockie (240 views)
2018-05-13 18:23:11

nelsongames (142 views)
2018-04-24 18:15:36

nelsongames (141 views)
2018-04-24 18:14:32

ivj94 (883 views)
2018-03-24 14:47:39

ivj94 (144 views)
2018-03-24 14:46:31

ivj94 (795 views)
2018-03-24 14:43:53

Solater (159 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!