8

I have been developing a Online Poker Game. But I keep hitting a wall. I want to implement Awards into the system, but I want them to be dynamic. Meaning I don't want to recompile for every award I would like to add.

I have thought about using Python code for each award. Then when the server checks to see if the user qualifies for the award it runs the python script with Jython (server is in Java and Netty NIO) and if the function returns a certain value I award the award to the user. Which could work but is there maybe a more efficient technique out there that will not force me to run hundreds of python scripts each time I need to check if a user got a award.

And when are the best times to do these checks? I have tought about a hook system where I will specify the hooks like ( [onconnect][ondisconnect][chatmessage.received] ). Which also could work but feels a bit crude and I will still have to run all the scripts from the database.

JJJ
  • 32,902
  • 20
  • 89
  • 102
Johann du Toit
  • 2,609
  • 2
  • 16
  • 31
  • 1
    In pure Java the dynamism you seek can be achieved using OSGi – earcam Aug 11 '11 at 11:11
  • Thought about it , so I create like a plugin system for the awards? Where every award is a Interface that the server calls in the Jar and then checks to see if the user should get the award. But what is the Performance hit on loading say 20 jars each with awards everytime I check? Or I could do caching ... mmmm – Johann du Toit Aug 11 '11 at 13:13
  • j.w. why are you concerned about loading 20 jars? This is a one-time penalty during server start-up (this is server code right?). Additionally, to efficiently load your classes from jar files, see: http://download.oracle.com/javase/1.3/docs/guide/jar/jar.html#Index%20File%20Specification – Drupad Panchal Aug 11 '11 at 18:57
  • Ok but how would I add awards as the server is running? I'm trying to keep it dynamic meaning no re-compile or restart. If possible. – Johann du Toit Aug 11 '11 at 19:08
  • OSGi allowes you to plug additional jars during application runtime. – bezmax Aug 17 '11 at 15:08

4 Answers4

6

If I were you, I'd have a totally separate process that grants awards. It runs perhaps once a day on the underlying database that contains all your player/game data.

Your core customer-facing app knows about awards, but all it knows about them is data it loads from the DB -- something like a title, image, description, maybe how many people have the award, etc., and (based on DB tables) who has won the award.

Your "award granter" process simply runs in batch mode, once per day / hour etc, and grants new awards to eligible players. Then the core customer-facing app notifies them but doesn't actually have to know the smarts of how to grant them. This gives you the freedom to recompile and re-run your award granter any time you want with no core app impact.

Another approach, depending on how constrained your awards are, would be to write a simple rules interface that allows you to define rules in data. That would be ideal to achieve what you describe, but it's quite a bit of work for not much reward, in my opinion.

PS -- in running something like an online poker server, you're going to run into versions of this problem all the time. You are absolutely going to need to develop a way to deploy new code without killing your service or having a downtime window. Working around a java-centric code solution for awards is not going to solve that problem for you in the long run. You should look into the literature on running true 24/7 services, there are quite a few ways to address the issue and it's actually not that difficult these days.

jkraybill
  • 3,339
  • 27
  • 32
  • Thanks some good tips. Nether even thought of having a separate process to handle award logic. Tried Googling for a bit of information but could not find anything useful, could you maybe point me to some literature as I'm really interested in seeing how to some companies achieve 24/7 Services. – Johann du Toit Aug 16 '11 at 07:49
  • I think the separation approach is the best. There's no reason you need to do the calculation every time you see the user, once a day is fine, and then the next time they log on the server sees that this person has been granted an award. – nflacco Aug 17 '11 at 14:56
  • Thanks. Made me think a little. Wanted to split it between you and the other answer but can only award one and you gave me the first insight. – Johann du Toit Aug 17 '11 at 15:16
  • Regarding true 24/7 uptime, the only real solution is OSGi, but you can fake it using load balancing techniques etc – earcam Aug 17 '11 at 15:23
3

There are a number of options I can think of:

  • OSGi as described above - it comes at a cost, but is probably the most generic and dynamic solution out there
  • If you're open to restart (just not recompile), a collection of jars in a well known folder and spring give you a cheaper but equally generic solution. Just have your award beans implement a standard interface, be beans, and let spring figure @Autowire all the available awards into your checker.
  • If you award execution is fairly standard, and the only variation between awards are the rules themselves, you can have some kind of scripted configuration. Many options there, from the python you described (except I'd go for a few big script managing all awards), to basic regular expressions, with LUA and Drools in the middle. In all cases you're looking at some kind of rules engine architecture, which is flexible in term of what the award can trigger on but doesn't offer much flexibility in term of what an award can lead to (i.e. perfect for achievements).
ptyx
  • 4,074
  • 1
  • 19
  • 21
3

Some comments to the answer with batch ideas: Implementing a Dynamic Award System

That batch processes can be on separate server/machine, so you can recompile the app or restart the server at any time. Having that new awards can be handled using for example the mentioned approach with adding jars and restarting the server, also new batch jobs can be introduced at any time and so on. So your core application is running 99% of the time, batch server can be restarted frequently. So separate batch machines is good to have.

When you need to deploy new version of core app I think you can just stop, deploy and start it with maintenance notice to users. That approach is used even by top poker rooms with great software (e.g. FullTiltPoker did so, right now it is down due to the license loss, but their site says 'System Update' :) ).

So one approach for versions update is to redeploy/restart in off-hours.

Another approach is real time updates. As a rule it is done by migrating users bunch by bunch to new version. So at the same time some users are using old version, some - new. Not pretty cool for poker software were users with different versions can interact. But if you are sure in the versions 'compatibility' you can go with that approach, checking user's client version for example on login.

In my answer I tried to say that you need not introduce 24/7 support logic to your code. Leave that system availability problems for hardware (failovers, loadbalancers, etc.). You can follow any good techniques you used to write code, only you need to remember that your crucial core logic is deployed not frequently (for example once a week), and batch part can be updated/restarted at any time if needed.

Community
  • 1
  • 1
Andrey
  • 6,526
  • 3
  • 39
  • 58
2

As far as I understand you, you probably do not have to run external processes from your application nor use OSGI. Just create a simple Java interface and implement each plugin ('award') as a class implementing the interface. You could then just simply compile any new plugin and load it in as a class file from your application at run-time using Class.forName(String className). Any logic you need from such a plugin would be contained in methods on the interface.

http://download.oracle.com/javase/1,5.0/docs/api/java/lang/Class.html#forName(java.lang.String)

MarianP
  • 2,719
  • 18
  • 17
  • I agree with your answer but, I would also like to add that using a standardized system (e.g OSGI) to load plug-ins relives the developer from the maintenance of such code. Class.forName(...) as an example is very easy to write, but when it comes to error handling, instance management becomes a nightmare and all of a sudden you are spending time on a problem which has already been solved (e.g, by OSGI) and not your game. – Drupad Panchal Aug 11 '11 at 18:49