CORDIAL MINUET ENSEMBLE

context fabric

Member

Registered: 2015-02-21

Posts: 23

Documentation of CM's code

I know some of you have already poured through CM's code to create your own custom interfaces. I was wondering if we could start compiling a community documentation to ease the learning curve for others (like me!) who want to do the same.

Im going to be diving into Jason's source this weekend, before then, if anyone has any suggestions on working through it and building my own UI I would greatly appreciate it!
Also Ill share anything I learn here if anyone is interested in this idea.

..

Member

Registered: 2014-11-21

Posts: 259

Re: Documentation of CM's code

Custom interfaces? I'm not aware of anyone modifying the source code for any purpose like that, other than possibly ClockForm (the person, not the bot) might have added an API for their bot.

I've spent a little while poking around the TCD and CM sources. But I can't think of much useful I could say that you wouldn't learn in 20 min of looking around for yourself. Basically, each *Page class represents a different activity/module of the program (such as the deposit money screen). Pages contain their own logic most of the time, but never talk to each other, instead, switching between pages and transferring data between them is handled by the drawFrame function in game.cpp.

Also, be aware that minorGems isn't just a set of low level libraries; it also handles things like parsing all the files in settings/ and handling some keyboard input (eg typing on the screen that pops up when you try to quit). Finally, most of minorGems (e.g. all the UI code) isn't used.

context fabric

Member

Registered: 2015-02-21

Posts: 23

Re: Documentation of CM's code

I should have been more specific.

What I want to do is give myself tools for analyzing the game board before the first pick, and after all susequent picks. I can display simple text data back on the command line but I want to be able to graph my data using CM's existing methods.

I will be attempting to do all of this from scratch tomorrow (Its my day off ) but figured I would ask first so Im not reinventing the wheel.

jasonrohrer

Administrator

Registered: 2014-11-20

Posts: 802

Re: Documentation of CM's code

Yeah, .. is right on.

Start in game.cpp (CordialMinuet/gameSource/game.cpp).

This file both implements and calls parts of the minorGems/game/game.h platform independent game framework that all of my games use (a platform independent wrapper for networking, graphics, sound, and user input).

game.cpp splits the game up into multiple GamePages, and keeps track of the current one.  It checks that page every frame to see if its status has changed, and if so, executes the page change-over logic, and then sets a new current GamePage.  For example, if they click DEPOSIT on the MenuPage, that will take them to the DepositPage, but if they hit CANCEL there, it will take them back to the MenuPage.

The main logic for the actual gameplay all happens on PlayGamePage, which is the page that you go to after joining a game when the game starts.  That page is actually pretty hairy, because it processes a bunch of different protocol responses (most of the other pages just handle one protocol request/response).  That page also computes and draws the graph.  There's a lot of code in there.

context fabric

Member

Registered: 2015-02-21

Posts: 23

Re: Documentation of CM's code

Thanks, both of you, I was able to find what I was looking for.

It seems for what I want to do, using CM's existing graphics code, isn't really an option without some major surgery.

So what I've done is added an Adapter class that essentially forwards updates to a StrategyAnalysis module when a new grid is generated or a players choice is commited. Im then rendering any visual graphs in a separate window with a separate openGL context.

As for my original topic, and the title of this thread, a documentation of the different protocols used to communicate with the server would be the most useful for people wanting to create custom clients.  Im not expecting to get a response detailing any of these but I'll share what I learn if anyone else is interested.

Last edited by context fabric (2015-02-23 08:36:53)

jasonrohrer

Administrator

Registered: 2014-11-20

Posts: 802

Re: Documentation of CM's code

There's an extensive document in server/protocol.txt

This doesn't necessarily spell out the order in which things happen, but every server call is documented there.  It's all straight HTTP, with simple text responses back.

context fabric

Member

Registered: 2015-02-21

Posts: 23

Re: Documentation of CM's code

Thank you very much!

context fabric

Member

Registered: 2015-02-21

Posts: 23

Re: Documentation of CM's code

Ive been going through the server protocols and Im having trouble understanding the sha1 hmac.

Im using openssl in a linux terminal to generate the sha1 hmac.

echo -n "sequence_number . hash_version_number" | openssl sha1 -hmac "my_account_key"

Im confused about what hash_version_number actually is and how I should represent it and sequence_number (as ascii, hex, ect).

Thus far Ive assumed hash_version_number was the clients version number (ie. 15), and used 0 for the dummy sequence number.

Ive been doing the hmac as so.

echo -n "015" | openssl sha1 -hmac "my_account_key"

Then I just send it all to the server.

http://cordialminuet.com/gameServer/server.php?action=check_user&email=my_email@email.com&sequence_number=0&account_hmac=hmac_from_code_above

But Im DENIED. Im not sure where my confusion is, but maybe the answer will seem obvious tomorrow.

jasonrohrer

Administrator

Registered: 2014-11-20

Posts: 802

Re: Documentation of CM's code

From the server source:

$cm_accountHmacVersion = "13";

That number only changes when protocol changes completely break the old version.  It turns out that v13 clients can still connect to the v15 server without breaking.

Once I add the amulet stuff, both version numbers will go up to 16, because older clients won't be able to connect.

Yes, the server SUGGESTS that you upgrade to v15, but a modified client could ignore that, or an already-connected client that's still connected during the upgrade process.  When the hash changes, old client messages will start becoming DENIED.

But you're correct that it's ascii for those numbers, and your SSL pipe above should be correct if you put the 13 in there.