Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
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 / Networking & Multiplayer / Re: RMI or Sockets for networked game on: 2012-07-02 09:21:53
The second biggest problem of RMI is the distributed garbage collector. RMI will cause full GC's every once in a while, likely to cause hickups in your game.

That's interesting, does that apply to the server and/or client side?
2  Game Development / Networking & Multiplayer / Re: What do Java game developers use for Database persistence? on: 2012-06-19 07:14:18
I think you're right in that the ORM impendance mismatch is probably better bridged by generating classes from relations than the other way around. It's a cool concept your friend is pursuing! But it also hinges on the tools available within the language, making queries and such easier. And the two-step cross-language compilation process is always going to feel like a hurdle.
3  Game Development / Shared Code / Effective Execution Statistics on: 2012-06-13 08:27:08
As designer of a highly scalable system I'm always trying to get good execution statistics data. Even from the frequent short test runs I'm doing during daily development. For instance, how long time have the simulation threads spent executing each simulation tick? How much time is spent persisting/loading data? What is the client IO volume?

For a long time I was manually adding statistics measurements to the code in the way lots of people do - calling System.currentTimeMillis() or nanoTime() at some execution points and logging the time spent. But this was cumbersome, unclean, ad-hoc and the results (lots of logged values) were difficult to interpret.

I finally ended up writing a relatively simple but effective and efficient statistics collector and printer. My objective was to emulate the logger in simplicity: Put the measurements to the collector in a single line just as you would put a string to the logger:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
public class IOPacker {
  public static final Logger LOG = Logger.getLogger(IOPacker.class);
  public static final StatCompiler STAT = StatCompiler.getStatCompiler(IOPacker.class);
  ...
  public void pack() {
    long startTime = System.nanoTime();
    ...
    STAT.putSample("Pack time [ms]", (System.nanoTime()-startTime)/1e6);
  }
}


To output the compiled statistics, I execute this line before the program exits:
1  
StatCompiler.logAllStats(LOG, Level.INFO);


The output for the above is:
1  
Pack time [ms]: sum: 3 326; avg: 11,9 (sd +- 48,6); count: 279; min<med<max: 5,5 < 8,2 < 823,2



Just like for a logger, the implementation needs to be as fast as possible. This is not terribly hard. But then there is the concern for memory: in a long application run, the amount of held data shouldn't grow indefinitely, even though we want the information to encompass the full run!

In this solution, the memory size grows with the order of magnitude between the smallest and the largest data point, but not with the number of data points. As long as there is a lower boundary on the smallest data point precision we care about, and since we only create buckets when a sample actually hits them, there rarely needs to be more than a few dozen buckets. In other words, after a warm-up period the memory usage for each metric is effectively constant regardless of program run length.

I wrote a longer blog entry about this here:
http://mmoarch.blogspot.se/2012/06/effective-execution-statistics.html

The code can be found at:
https://gist.github.com/2854260
4  Game Development / Networking & Multiplayer / Re: Database for gameserver on: 2012-06-08 07:40:56
Hello, back again, I got a question, Me and some friends are creating a Game where there (hopefully) will be 1000 user's online.
...
or is mysql(or h2) + hibrenate enough for that amount of people?

I have made a similar design & development journey and from my point of view I'd definitely recommend this:

1) You'll want to end up using an SQL-DB. That is superior once you're in production (and large scale tests), it's a mature technology and there are so many tools to inspect and work with the database directly.

2) You might not want to start out with writing the SQL persistency though. This adds a lot of overhead while you're still engineering the game, changing game entities and redesigning. On the other hand, it may not be wise to postpone the persistency layer entirely unless you're quite experienced in writing database persistency. You risk having to rewrite parts of the server design once you actually design the persistency layer if you haven't thought about those issues beforehand.

3) The above can be an argument for using JPA such as Hibernate or EclipseLink. But I have used both and I really regret it! They can perhaps be good for business applications but they really have the wrong performance profile for game servers (or I dare say any simulation application). They are good for getting 'some' DB objects out from the DB, modifying them, and then saving them again in a reliable manner. They are not good for applications constantly manipulating a large set of world data. And while JPA makes the actual translation of individual object field members to DB columns much easier, in spite of JPA's objectives to insulate developers from DB issues you will end up having to really think about DB modelling while doing your class modelling. In short - for the very early, small prototyping JPA can be neat. But don't use it for the full game. (And if you must: Use Eclipse-Link rather than Hibernate.)

4) If I were doing my design journey all over again, I'd start with a clearly defined persistency layer with a small API to load, store etc game data. The first implementation would be to simply write to files as simply as possible, perhaps using Java's serialization. Then later when the game design doesn't change that much anymore, I'd replace it with a custom JDBC back-end.
5  Game Development / Performance Tuning / Re: ArrayList vs LinkedList on: 2012-06-07 17:32:01
Sounds like there would be some case for writing a new linked list implementation backed by one or a small set of arrays, now that the RAM cache misses is such a major performance factor. I.e. in order to avoid new object creation for each link, maintaining cache locality, and yet offer fast insertion and deletion.
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (16 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (42 views)
2014-08-19 09:29:53

Tekkerue (41 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (26 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (73 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org 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‑gaming.org
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!