1
\$\begingroup\$

I am planning some small games that will all rely on a single system of Lua scripts to manage some unified data about:

  1. Some achievements that are common to each game.
  2. The player's progress in completing the achievements.

Players would need to have these three parts on their system to play:

  • This small set of three unifying Lua scripts.
  • A single data file containing a list of challenges and the status of the player's progress in completing each.
  • At least one of the small games.

The three Lua scripts manage the player's progress data file:

  1. One script tells the game which challenge the player needs to complete next.
  2. Another script updates the data file with information about the player's progress.
  3. A final script calculates statistical information about the player's progress. A game can check use this script and decide which of this information it will show to the players.

So far, I am having the games execute the Lua scripts and using stdout to communicate information between the games and Lua scripts placed in a bin directory, which seems to work well on Linux, but I need a solution that works equally on Windows, OS X, and mobile devices and that will not be a challenge for players to install. Is this a more preferred method?

  • Other developers using different programming languages should be able to easily connect their games to this system.
  • Everything is stored locally, nothing uses the Internet.
\$\endgroup\$
  • 2
    \$\begingroup\$ I don't understand your architecture. You have whole separate processes comprising your game and the scripts run outside those? \$\endgroup\$ – Sean Middleditch Nov 14 '13 at 8:30
  • \$\begingroup\$ Is it an online game or completely client-sided? \$\endgroup\$ – Philipp Nov 14 '13 at 8:58
1
\$\begingroup\$

I understand you want to provide a local system for challenges and achievements.

Usually this type of functionality is managed by servers which require the games to exchange data across the internet. I would recommend going this way too.

But you will always need to keep thing locally when the connection is down or when you need to cache the data. Usually you build a library which will provide this cache in a file.


If you really want to keep this functionality local (on the computer) then you could try using a standard data storage system (file or SQLite) in a default location and write the data from each game to the storage.


If you want to handle some logics on the receiving end and you don't want to do this from your games, then indeed, you will have to run your service.

If you want a multi platform solution you will need a library to abstract the communication across processes.

In that case you are looking for a cross platform IPC library like boost::interprocess. If one day you need to run the main component as a server you will want to switch to boost::asio.

Also if you want to make the dev of your apps simpler by decoupling the different parts I would look at Google's Protocol Buffers. It makes IPC much simpler as the messaging protocol of your main app can evolve without breaking compatibility with the other apps.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.