I am planning a turn based game (a sort of board game), and the backend will probably be done in Erlang. The game logic part seems to be a fit for a hierarchical state machine, but I'm not sure about how to implement that in Erlang.
Maybe I can spawn a separate process with each child fsm, not sure if this would work.
Another option would be to embed a scripting language or create a DSL for this purpose.
What do you think?
Thanks.
I am the original question author (in fact I would like to claim the question as mine, but I don't know how).
I already know about all the things OTP offers, gen_fsm included.
The idea is to use a HIERARCHICAL state machine, and gen_fsm is a plain state machine. To keep track of the game turns, phases, etc, I don't think a plain state machine as gen_fsm would be enough.
Anyway, I have been investigating further, and I think that I will use erl-lua so I can use Lua for all the game logic. Once it is working I can search for bottlenecks and move them to a C implementation or whatever.
#codecaster you can use gen_fsm to track the state and just build in an additional level of state inside the fsm state... however, erl-lua would work as well. I built a monitoring tool with it called erlmon - we had some trouble with erl-lua crashing so keep in mind it's not bug free. also with the new support for Nifs, i'm waiting for someone to write a new driver for lua that is nif-based - you might want to look around for that - i haven't seen anyone build one yet.
As a starting point, I would suggest you to have a look to the OTP design principles. You'll probably want to have a more detailed look at supervisors and generic FSMs.
Related
I've started helping with an open source game (based on Cocoa, Obejctive-C, Xcode). The existing game engine is already setup to allow the character to run around the world, encounter an enemy, and when combat is begun, a characterObject is called with the enemy unit object that is to be attacked. This characterObject has a default method of attacking the enemy.
I wanted to improve on this design by extending the program to allow others to develop a combatUnit plugin that would handle the combat actions in their own programmed way. This could open up the community to develop different styles of combat and come up with their own unique play style.
As I began to look into Plug-Ins and examples on how to build, most of the examples kept the plug-in relatively isolated from the internals of the rest of the program. And any data the plugin required would be passed into the routine(s) themselves.
However, in this case, a combat unit developer might want to have access to numerous external objects in the existing game: a developer might want to also know of any nearby enemy units to avoid any potential adds in a fight and would have to access several of the existing environment objects to get that data, the character might be in a group and the developer might want access to the group info and each players data to determine if they should heal, etc... Not knowing what a developer has in mind, it would be unfeasible for me to attempt to predict and pass in all potential info for them to use.
So, my question is:
Is this a good application for a Plug-In? If so, when developing the plug-in how do I open up the other objects for the plug-in developer to code against?
Is there another approach to solve this problem? Something else than a "Plug-in" that would be more appropriate for the code to have access to the game's objects?
Thanks for you help!
That’s a good case for making plug-ins. As an alternative you could compile the new objects directly into the game or use a scripting language interpreter. But with those you’d have to solve the same problems of how to give access to the internals of the game to the new combat unit.
The cleanest way to do this would be to define an interface to the game (either as a protocol or a base class) and pass that to the plug-in. Using this object the plug-in can then query anything it needs.
I know this is a pretty open question but I was wondering how people go about writing scripts that will "play" a game, or manipulate it in some way. I had been thinking that I'd try to get a working AI to play a game for fun, but don't even really know where to start. Are there any good resources to learn this? What are good languages to use? Once I have the language, how do I get my script hooked into the game? I was thinking of just trying simple flash games, if that helps.
Thanks a bunch!
Are you looking to "play" an existing game, or write some sort of a game that can then be scripted?
If the former, you find that game's API and start writing code in the appropriate language. E.g. Unreal-powered games use UnrealScript and ship with the tools so you can embed new functionality. You're pretty much dependent on the game creators leaving an "in" such as this...
...unless you want to get totally nutty and hack the executable itself to execute your own code somehow. For information on how to do this, search for information on game "trainers". I'm not sure what a great set of search terms would be, but I know a lot of games do have trainers released, so type in "trainer <my_favorite_game>" and see what you get?
You can do this quite simply in Java 6.
expose your objects/functions in your Java app into the scripting environment
For example you can expose your character or the game world into the scripting environment and allow the script to control it.
invoke script functions/methods from Java environment
Allow the script to customize behaviours, add new actions, etc. Another use of this is to override the default build in game rules and load your own house rules. Another use is as a macro facility. Typically this would be part of the main game loop
use the script as a data/level file
For example, in a game likes SpaceHulk where it is mission based, you can use a script to define a game specific DSL, and us this DSL to define new missions. When the game starts up, it evaluates the data file and create a model of the game.
To integrate a scripting engine into Java, simply do this
ScriptEngineManager mgr = new ScriptEngineManager();
ScriptEngine jsEngine = mgr.getEngineByExtension("js");
jsEngine.eval("print('Hello world!');
To expose an object into the script environment
jsEngine.put("avatar", avatarObject);
//An avatar object is now available in myscript.js
jsEngine.eval(new FileReader("myscript.js");
To invoke a function in the script
jsEngine.eval("function hello(name) ... ");
Invocable inv = (Invocable)jsEngine;
inv.invokeFunction("hello", "Fred");
One of the problem with scripting is that, the script has access to your entire application. You can restrict what the script can 'see' by setting a classloader when you create the ScriptEngineManager instance.
Java 6 comes with a bundled JavaScript engine. However I prefer Groovy and loading Groovy basically mean changing 'js' in getEngineByExtension() to 'groovy'.
I know that a lot of people say that Java is not fast for games, but if you are writing turn based games or social games like Farmville then I think it is more than adequate.
For C/C++ based games, I think the preferred script engine is Lua. I've not used it so I cannot comment on it.
The best way to do that is to use the API provided by the game, if there is one. The Civilization games, for example, come with a very complete modding engine that allows you to script whatever you want. The same can be said for Age of Empires and a variety of other games.
Simple flash games, though? That'll be tough. Those don't generally provide any supported way to script, so you'll be left with simulating input. It'll be tough.
The easy way is to control mouse and keyboard functions with autoit. You can also read out information from your screen, but it is a bit limited It is good to just check if things changed or check whats on a certain area of the screen if you know there are a limited amount of possibilities. Not so easy to read and interpret text. Autoit is excelent to automate games like farmvile. I have also made blackjack bots for online casinos. And use it for small but mundane and repeating (manufacturing) tasks in RPGs. Dont expect to build an AI for an RTS or FPS though.
Autoit is easy to find with google. A fast and small download. Excelent documentation and you can learn it in days.
The hard way is what people wrote about above here i guess. Interacting with the game data. Searching information on that is what brought me here. I see its with C++ or Java. While the languages are all similar and you can use them all after learning 1, these come with complicated software environments that take lots of time to learn. The possibilities and chances to make something really reliable are much much greater though.
as opposed to writing your own library.
We're working on a project here that will be a self-dividing server pool, if one section grows too heavy, the manager would divide it and put it on another machine as a separate process. It would also alert all connected clients this affects to connect to the new server.
I am curious about using ZeroMQ for inter-server and inter-process communication. My partner would prefer to roll his own. I'm looking to the community to answer this question.
I'm a fairly novice programmer myself and just learned about messaging queues. As i've googled and read, it seems everyone is using messaging queues for all sorts of things, but why? What makes them better than writing your own library? Why are they so common and why are there so many?
what makes them better than writing your own library?
When rolling out the first version of your app, probably nothing: your needs are well defined and you will develop a messaging system that will fit your needs: small feature list, small source code etc.
Those tools are very useful after the first release, when you actually have to extend your application and add more features to it.
Let me give you a few use cases:
your app will have to talk to a big endian machine (sparc/powerpc) from a little endian machine (x86, intel/amd). Your messaging system had some endian ordering assumption: go and fix it
you designed your app so it is not a binary protocol/messaging system and now it is very slow because you spend most of your time parsing it (the number of messages increased and parsing became a bottleneck): adapt it so it can transport binary/fixed encoding
at the beginning you had 3 machine inside a lan, no noticeable delays everything gets to every machine. your client/boss/pointy-haired-devil-boss shows up and tell you that you will install the app on WAN you do not manage - and then you start having connection failures, bad latency etc. you need to store message and retry sending them later on: go back to the code and plug this stuff in (and enjoy)
messages sent need to have replies, but not all of them: you send some parameters in and expect a spreadsheet as a result instead of just sending and acknowledges, go back to code and plug this stuff in (and enjoy.)
some messages are critical and there reception/sending needs proper backup/persistence/. Why you ask ? auditing purposes
And many other use cases that I forgot ...
You can implement it yourself, but do not spend much time doing so: you will probably replace it later on anyway.
That's very much like asking: why use a database when you can write your own?
The answer is that using a tool that has been around for a while and is well understood in lots of different use cases, pays off more and more over time and as your requirements evolve. This is especially true if more than one developer is involved in a project. Do you want to become support staff for a queueing system if you change to a new project? Using a tool prevents that from happening. It becomes someone else's problem.
Case in point: persistence. Writing a tool to store one message on disk is easy. Writing a persistor that scales and performs well and stably, in many different use cases, and is manageable, and cheap to support, is hard. If you want to see someone complaining about how hard it is then look at this: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
Anyway, I hope this helps. By all means write your own tool. Many many people have done so. Whatever solves your problem, is good.
I'm considering using ZeroMQ myself - hence I stumbled across this question.
Let's assume for the moment that you have the ability to implement a message queuing system that meets all of your requirements. Why would you adopt ZeroMQ (or other third party library) over the roll-your-own approach? Simple - cost.
Let's assume for a moment that ZeroMQ already meets all of your requirements. All that needs to be done is integrating it into your build, read some doco and then start using it. That's got to be far less effort than rolling your own. Plus, the maintenance burden has been shifted to another company. Since ZeroMQ is free, it's like you've just grown your development team to include (part of) the ZeroMQ team.
If you ran a Software Development business, then I think that you would balance the cost/risk of using third party libraries against rolling your own, and in this case, using ZeroMQ would win hands down.
Perhaps you (or rather, your partner) suffer, as so many developers do, from the "Not Invented Here" syndrome? If so, adjust your attitude and reassess the use of ZeroMQ. Personally, I much prefer the benefits of Proudly Found Elsewhere attitude. I'm hoping I can proud of finding ZeroMQ... time will tell.
EDIT: I came across this video from the ZeroMQ developers that talks about why you should use ZeroMQ.
what makes them better than writing your own library?
Message queuing systems are transactional, which is conceptually easy to use as a client, but hard to get right as an implementor, especially considering persistent queues. You might think you can get away with writing a quick messaging library, but without transactions and persistence, you'd not have the full benefits of a messaging system.
Persistence in this context means that the messaging middleware keeps unhandled messages in permanent storage (on disk) in case the server goes down; after a restart, the messages can be handled and no retransmit is necessary (the sender does not even know there was a problem). Transactional means that you can read messages from different queues and write messages to different queues in a transactional manner, meaning that either all reads and writes succeed or (if one or more fail) none succeeds. This is not really much different from the transactionality known from interfacing with databases and has the same benefits (it simplifies error handling; without transactions, you would have to assure that each individual read/write succeeds, and if one or more fail, you have to roll back those changes that did succeed).
Before writing your own library, read the 0MQ Guide here: http://zguide.zeromq.org/page:all
Chances are that you will either decide to install RabbitMQ, or else you will make your library on top of ZeroMQ since they have already done all the hard parts.
If you have a little time give it a try and roll out your own implemntation! The learnings of this excercise will convince you about the wisdom of using an already tested library.
What do you prefer (from your developer's point of view) when it comes to implement a business process?
A Business Process Management System (BPMS) or just your favorite IDE with the needed tools and frameworks (a reporting tool for example)?
What is from your point of view the greatest Benefit of a BPMS compared to an IDE with your personal tools and frameworks?
OK. Maybe I should be more specific... I got to know one specific BPMS which should make it easy to implement a business process by configuring rules. But for me as a developer it is hard to work with the system. I would like to work with text files which I can refactor and I would like to be able to choose the right technology or framework for the job I have to do. Instead the system forces me to configure.
There are rules where I can use java, but even then I have to stick to the systems editor without intellisense etc.
So this leads me to the answer of my own question - I would like to use the tools I am used to instead of having to learn how to work with a BPMS (at least the one I know) because it limits me more than it helps. The BPMS I know is a framework from which it is hard to escape! At this time, I would prefer a framework like Grail over any BPMS I know.
So maybe the more specific question is: do you feel the same or are there BPMSes which support you in beeing a developer and think like a developer or do most of them force you to do your job a different way?
In my experience the development environments provided by BPMS systems are third rate, unproductive, and practically force you to write hard to maintain, poorly designed code (due to their limitations). Almost all the "features" (UI, integrations, etc) provided by the BPMS system I'm familiar with (the one sold by that company named for its database) were not worth the money we paid.
If you're forced to use BPMS, as a developer, my advice would be to build as much of your application in a conventional development environment, such as Java or .Net, build as little as possible in the BPMS environment itself, and integrate the two. The only things that should go in the BPMS is the minimum to make the business process work.
Not sure what exactly you ask, but the choice BPM vs. plain programming will depend on the requirements. A "business process" is a relatively vague term in software engineering.
Here are a few criterion to evaluate your needs:
complexity of the rules - Are the decisions/rules embodied in your process simple, complicated, configurable, hard-coded?
volatility of the process - How frequently does your process change? Who should be able to make the change?
integration need - Is your process realized using multiple heterogenous services, or is all implemented in the same language?
synchronous/asynchrounous - Is your process "long-running" with the need to handle asynchronous actions?
human tasks - Does your process involves human interaction, with task being assigned/routed to people according to their roles/responsibilities?
monitoring of the process - What is the level of control you want on the existing process instances being executed? Do you need to audit the actions, etc. ?
error handling - Depending on the previous points, how do you plan to deal with errors, or retry of faulty process execution?
Depending on the answer to these questions, you may realize that your process is closer to a simple state chart with a few actions and decisions that can be executed in a sequence, or you may realize that you need something more elaborated, and that you don't want to re-implement all that yourself.
Between plain programming and a full-fledge BPM solution (e.g. Oracle BPM suite which contains BPEL, rule engine, etc.), there are intermediate solutions such as jBPM or Windows Workflow Foundation and probably a lot of others. These intermediate solution are frequently good trade-off.
I have worked with Biztalk in the past and more recently with JBPM. My opinion is biased against BPMs for the following reasons:
Steep learning curve : To make a process work, I have to understand how the system and the editor works. It is hard enough for a developer to understand the system, let alone a business user. The drag and drop and visual representation is a great demo tool. It certainly impresses managers (who ultimately pay for it), but a developer's productivity just drops.
Non developers changing the workflow : I haven't seen one BPM solution do it flawlessly. Though it doesn't look like code, right click on the box and you do have to put some code, otherwise it is not going to work. So you definitely need a developer to do it. The best part is that it is neither developer friendly nor business user friendly, just demo user friendly.
Testablity and refactoring : It is virtually impossible to test drive a BPMS. You do have 'unit test frameworks' advertised, but most of them are hacks and hard to use. Recently I tried the JBPM one; I ended up writing a lot of glue code and fake workflow handlers to make it work. The deal breaker for me though is refactoring. If the business radically changes it's mind about how a business process should look, then good luck re-arranging the boxes, because just re-arranging them won't work, all the variables bound to the boxes also need to be re-arranged. I would prefer the power of the IDE and tests to refactor my business process.
If your application has workflow, then you could try a workflow library (with or without persistent state). It will still manage your workflows without all the bloat that comes with a BPM. If a business user needs to understand the code, then let the business prepare good process flowcharts and translate them into good domain driven code. Use cucumber style acceptance tests to make bring the developers and business together. A BPM is just something that tries to do too many things and ends up doing all those things badly.
BPMS-- a lot of common business case, use case are already implemented. So you just have to know how to use it. For common workflow, you don't even need to write a single line of code, though mostly you would have to write some scripts to cover things that are not yet implemented.
Plain programming-- just use the IDE to hack out the code. The positive side: more control. The negative? A lot of times are spent on rewriting boilerplate code. And you have to maintain them.
So in a nutshell, I would prefer a Business Process Management System. One that I would recommend is ProcessMaker. It features an intuitive process designer that allows you to design workflow with drag and drop. And you can always write trigger to extend the process functionalities. It's open source as well.
One of our next projects is supposed to be a MS Windows based game (written in C#, with a winform GUI and an integrated DirectX display-control) for a customer who wants to give away prizes to the best players. This project is meant to run for a couple of years, with championships, ladders, tournaments, player vs. player-action and so on.
One of the main concerns here is cheating, as a player would benefit dramatically if he was able to - for instance - let a custom made bot play the game for him (more in terms of strategy-decisions than in terms of playing many hours).
So my question is: what technical possibilites do we have to detect bot activity? We can of course track the number of hours played, analyze strategies to detect anomalies and so on, but as far as this question is concerned, I would be more interested in knowing details like
how to detect if another application makes periodical screenshots?
how to detect if another application scans our process memory?
what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
what other ways exist in which a cheater could gather informations about the current game state, feed those to a bot and send the determined actions back to the client?
Your feedback is highly appreciated!
I wrote d2botnet, a .net diablo 2 automation engine a while back, and something you can add to your list of things to watch out for are malformed /invalid/forged packets. I assume this game will communicate over TCP. Packet sniffing and forging are usually the first way games (online anyways) are automated. I know blizzard would detect malformed packets, somehting i tried to stay away from doing in d2botnet.
So make sure you detect invalid packets. Encrypt them. Hash them. do somethign to make sure they are valid. If you think about it, if someone can know exactly what every packet means that is sent back and forth they dont even need to run the client software, which then makes any process based detection a moot point. So you can also add in some sort of packet based challenge response that your cleint must know how to respond to.
Just an idea what if the 'cheater' runs your software in a virtual machine (like vmware) and makes screenshots of that window? I doubt you can defend against that.
You obviously can't defend against the 'analog gap', e.g. the cheater's system makes external screenshots with a high quality camera - I guess it's only a theoretical issue.
Maybe you should investigate chess sites. There is a lot of money in chess, they don't like bots either - maybe they have come up with a solution already.
The best protection against automation is to not have tasks that require grinding.
That being said, the best way to detect automation is to actively engage the user and require periodic CAPTCHA-like tests (except without the image and so forth). I'd recommend utilizing a database of several thousand simple one-off questions that get posed to the user every so often.
However, based on your question, I'd say your best bet is to not implement the anti-automation features in C#. You stand very little chance of detecting well-written hacks/bots from within managed code, especially when all the hacker has to do is simply go into ring0 to avoid detection via any standard method. I'd recommend a Warden-like approach (download-able module that you can update whenever you feel like) combined with a Kernel-Mode Driver that hooks all of the windows API functions and watches them for "inappropriate" calls. Note, however, that you're going to run into a lot of false positives, so you need to not base your banning system on your automated data. Always have a human look over it before banning.
A common method of listening to keyboard and mouse input in an application is setting a windows hook using SetWindowsHookEx.
Vendors usually try to protect their software during installation so that hacker won't automate and crack/find a serial for their application.
Google the term: "Key Loggers"...
Here's an article that describes the problem and methods to prevent it.
I have no deeper understanding on how PunkBuster and such softwar works, but this is the way I'd go:
Iintercept calls to the API functions that handle the memory stuff like ReadProcessMemory, WriteProcessMemory and so on.
You'd detect if your process is involved in the call, log it, and trampoline the call back to the original function.
This should work for the screenshot taking too, but you might want to intercept the BitBlt function.
Here's a basic tutorial concerning the function interception:
Intercepting System API Calls
You should look into what goes into Punkbuster, Valve Anti-Cheat, and some other anti-cheat stuff for some pointers.
Edit: What I mean is, look into how they do it; how they detect that stuff.
I don't know the technical details, but Intenet Chess Club's BlitzIn program seems to have integrated program switching detection. That's of course for detecting people running a chess engine on the side and not directly applicable to your case, but you may be able to extrapolate the apporach to something like if process X takes more than Z% CPU time the next Y cycles, it's probably a bot running.
That in addition to a "you must not run anything else while playing the game to be eligible for prizes" as part of the contest rules might work.
Also, a draconian "we might decide in any time for any reason that you have been using a bot and disqualify you" rule also helps with the heuristic approach above (used in prized ICC chess tournaments).
All these questions are easily solved by the rule 1 above:
* how to detect if another application makes periodical screenshots?
* how to detect if another application scans our process memory?
* what are good ways to determine whether user input (mouse movement, keyboard input) is human-generated and not automated?
* is it possible to detect if another application requests informations about controls in our application (position of controls etc)?
I think a good way to make harder the problem to the crackers is to have the only authoritative copies of the game state in your servers, only sending to and receiving updates from the clients, that way you can embed in the communication protocol itself client validation (that it hasn't been cracked and thus the detection rules are still in place). That, and actively monitoring for new weird behavior found might get you close to where you want to be.