Finite State Machine

[andyleejordan]

Heh, this is pretty much what I did for the first assignment. It's not a chart (yet) but it is pretty much a Finite State Machine for a game turn (as seen by the Star System game anyways). It's this section. There is a key above it too.

It doesn't cover everything (I only had a few hours to do it...), but all the entities in the game are also just states, which can be easily added.

[andyleejordan]

But like I've been saying, a turn-based board game like Freedom in the Galaxy is a finite state machine, completely. That's all it is in fact. Which makes it very easily adapted to a programmed FSM through either that JSON state object, or a database holding the state. Transitions between states would either be Python methods that manipulate the JSON or the database, or even better, simple database procedures (assuming everyone else is comfortable with that). That takes care of the entire game engine, it just needs a communication layer and an interface layer.

[mein1156]

My two cents. I think a database is a good idea. I think the embedded database sqlite3 already comes with python and doesn't require any extra installation as long as we use the DB-API 2 interface that comes with python. It is fast for something small like our game and we have rollback compatibilities and save points in case some error or someone cancels, we can just rollback the game effortlessly, not to mention views, triggers, etc. Also has a lot of safety features we can't easily have using our own JSON.

[hallister]

We talked a bit about this in class today. We are going to use SnakeMQ as our communications library (more than likely the RPC implementation, but I haven't played with it much). Additionally, we will definatly be using a database, more than likely with SQLAlchemy as the underlying library, so we don't tie ourselves to one implementation.

We should have more implementation details soon, as we need to start working on it.

[andyleejordan]

@mein1156 I second using sqlite3, it'll be the easiest and honestly best implementation for our game. It also gives us the ability to use full SQL operations.

@hall5714 SnakeMQ looks perfect.

[hallister]

Both of you can checkout http://www.sqlalchemy.org/. It's an ORM for SQL (including sqlite).

[andyleejordan]

@hall5714

SQLAlchemy considers the database to be a relational algebra engine, not just a collection of tables. Rows can be selected from not only tables but also joins and other select statements; any of these units can be composed into a larger structure.

That's what we want, but can it do anything that you can't already do using SQL queries, or does it just make it easier?

[hallister]

It represents SQL tables as classes. Effectively we won't need SQL queries because SQLAlchemy generates them:

from sqlalchemy import Column, Integer, String

class User(Base):
    __tablename__ = 'users'

    id = Column(Integer, primary_key=True)
    name = Column(String)

    def __init__(self, name):
        self.name = name

    def __repr__(self):
        return "<User('%s','%s', '%s')>" % (self.name)

Now I can create a user and add them to the database:

from sqlalchemy.orm import sessionmaker
from my_cool_orm import User

Session = sessionmaker(bind=engine)
session = Session()

new_user = User('Justin')
session.add(ed_user)
session.commit()

So we now can have an SQL backend, without having to write SQL queries AND support multiple SQL engines.

[mein1156]

@hall5714 The good thing about using the DB-API 2 is that only the executed queries might be different between sql engines if something is specific. Also a plus, no extra libraries are needed, it all comes packaged. I'm biased though, maybe Andy will agree, I love writing SQL.

[Greg-Donaldson]

To be fair, my original thought with this game was to use databases instead of text files, and handle information retrieval with calls to a database, using SQL. I'm biased though as well (been working with SQL databases all summer).

[hallister]

@mein1156 Don't get me wrong I like SQL, but it would be a bad idea to write direct SQL queries for a project like this. ORM's work REALLY well for rapid development. For example, if I decide that there's something wrong with the scheme, I change the SQL and I change a single python class. If we write our own SQL queries, we have to change every query that relied on our original scheme.

Bottom line: SQL is cool, but speed (in terms of development) is what we really need. And SQL doesn't allow for speed. Besides, it is python so sudo pip install sqlalchemy isn't a big deal.

@Greg-Donaldson We will be using SQL. That said, only the backend is going to have direct access to SQL, while the client and ai will have access to the backend API.

[Greg-Donaldson]

@hall5714 Alright. Glad I am on backend then.

[cawaltrip]

Closing due to issue being resolved.