Collectible Card Game Headquarters

silly freak wrote:Cool! Yeah, it's great how many things suddenly become possible when the game logic is organized into GameEvents - undo, network play, spectators, game recording, AI...

Speaking of network, how are you serializing GameEvents? Are you including the GameActions, or are you re-running the GameActions on the other side? Do you identify game states as well, or only events, i.e., will two engines be aware whether they are in the same state or not at a given moment?

I'll be creating a new Player interface (or adapting existing ones—I haven't looked into it yet) that will be implemented to handle input from various sources, one of which is networked players. The game will ask for an action from a player when priority is given. A UI player will simply get actions locally from the UI. A networked player will pass a serialized GameEvent (or occasionally a GameAction in the case of passing priority) back to the game that's requesting input. The networked player will negotiate the connection between clients, exposing none of the details to the UI or game state. As far as all of that is concerned it'll just be an AI player.

The received GameEvents will be executed on each Game (since they contain all the necessary actions already).

The engines won't be aware of the state of other engines (except for perhaps some sanity checking of the game state every so often to make sure everyone's playing the same game.

All of this is completely subject to change since I've hardly worked out any of the details since a lot of it depends on how the game will work and I haven't really gotten that far into it yet.

Unfortunately I don't have Photoshop at work, so here's a quick outline put together in GIMP (my apologies for the awfulness):

KrazyTheFox wrote:I'll be creating a new Player interface (or adapting existing ones—I haven't looked into it yet) that will be implemented to handle input from various sources, one of which is networked players. The game will ask for an action from a player when priority is given. A UI player will simply get actions locally from the UI. A networked player will pass a serialized GameEvent (or occasionally a GameAction in the case of passing priority) back to the game that's requesting input. The networked player will negotiate the connection between clients, exposing none of the details to the UI or game state. As far as all of that is concerned it'll just be an AI player.

The received GameEvents will be executed on each Game (since they contain all the necessary actions already).

The engines won't be aware of the state of other engines (except for perhaps some sanity checking of the game state every so often to make sure everyone's playing the same game.

All of this is completely subject to change since I've hardly worked out any of the details since a lot of it depends on how the game will work and I haven't really gotten that far into it yet.

Unfortunately I don't have Photoshop at work, so here's a quick outline put together in GIMP (my apologies for the awfulness):

Untitled.png

Do you have a specific plan or schedule on how you intend to proceed? It sounds like you have to essentially rewrite the entire game engine to support a common action/event API and integrate all that with the GUI and player interface. Add the wonders (or bugfest) that is multi-threading to the mix and it looks like you are pretty much creating a new game from scratch. This sounds more like a full time job or project that is going to take months from a dedicated team than a hobby at this point...

The actual work involved isn't quite that much, but there is a lot to figure out. The actual game loop is surprisingly simple. You are right that it is a huge undertaking regardless, which is why I'm estimating months at the very least. I don't quite have a plan yet, but I have been studying the engine a lot to help formulate one. Most of the UI stuff should remain the same as it is in Forge at the moment, due to the way I'll be gathering input. Again, though, right now it's mostly research with development to come later.

I've done a fair bit of game development in the past and it's pretty impressive what one person can do.

KrazyTheFox wrote:I've done a fair bit of game development in the past and it's pretty impressive what one person can do.

If it helps, I believe you can do it. I don't know what I'd have done if you hadn't helped me get the Android app build together. Besides, if I can get the Android app where it is today in just 8 months around working as a full-time software developer, there's no reason to doubt what another motivated developer is capable of.

Good luck.

Good luck! Once the new GUI code is a bit more stable I can definitely try and help here if you want

Just one question: will you hook it up to the Gui code I wrote or will you need something new? The first way we'll essentially have rewritten, well, everything I think it'd just be a shame if they wouldn't be compatible.

elcnesh wrote:Good luck! Once the new GUI code is a bit more stable I can definitely try and help here if you want

Just one question: will you hook it up to the Gui code I wrote or will you need something new? The first way we'll essentially have rewritten, well, everything I think it'd just be a shame if they wouldn't be compatible.

I have no idea. I'd like to keep it as compatible as possible; the less work that needs to be done the faster all this will come together. I'm just not far enough along to tell (nor have I looked at the new GUI code since I've been polishing up some of my existing additions to Forge before the next beta).

I definitely wish you the best of luck! It's a huge undertaking, but I do believe that it can be done, and I believe in your skills and your ability to see this project through! I'm sure that other developers will most certainly contribute to your code base as well once there is a certain initial structure released that it's possible to contribute to!

- Agetian

Agetian wrote:I definitely wish you the best of luck! It's a huge undertaking, but I do believe that it can be done, and I believe in your skills and your ability to see this project through! I'm sure that other developers will most certainly contribute to your code base as well once there is a certain initial structure released that it's possible to contribute to!

- Agetian

Thanks for all the encouragement, guys! It really does help.

I'll be sure to create a branch as soon as it's possible to so people can jump in and help out.

Just saw this thread.

I actually had a similar idea after looking at the Forge code and discovering that's not how the AI works.

Have you made any progress since this thread? I might be interested in helping out.

Myrd wrote:Just saw this thread.

I actually had a similar idea after looking at the Forge code and discovering that's not how the AI works.

Have you made any progress since this thread? I might be interested in helping out.

Not nearly as much as I'd have liked and not enough to really share yet. I've been away on a business trip for a month, then my dad came in from out of town for another week, then I had to work extra hours to make up for those lost when making sure he got around alright... so I've lost about a month of development time for Forge. I'll be getting up to speed on the changes since I last worked on it soon, after which I'll resume working on traversable engine. I still plan to make a branch for this once it's got the basics implemented.

I started looking at the code to see how the current code can be adapted to support some of these goals.

First thing would be getting rid of global state - for example the static playerCache inside the the Player class and similarly for card cache. (These are both reset when a new Game object is created). Instead of them being static, they should be associated with a Game (or a helper class on the game). I'll look at making some of these changes in the coming week and see where that gets us.

(While I believe the above refactoring would have many benefits - e.g. being able to run multiple games at the same time - either for simulation or even in the UI in different tabs - my actual goal is to see what's the minimum work required to make AI do basic action simulation - e.g. compare board state after playing spell X vs. after playing spell Y. I think this would already be a huge improvement over current AI - even with just looking 1 move ahead.)

Actually, making multiple games run simultaneously is a bit more involved, as a problem is that many GUI classes are singletons... Changing this is quite involved, as we'd have to create links between all the relevant classes.
(This doesn't change anything about the cache stuff, just a little sidenote )

elcnesh wrote:Actually, making multiple games run simultaneously is a bit more involved, as a problem is that many GUI classes are singletons... Changing this is quite involved, as we'd have to create links between all the relevant classes.
(This doesn't change anything about the cache stuff, just a little sidenote )

Fair enough, I'll keep that in mind.

I started to work on the above re-factoring, but before I proceed further, wanted to ask some questions.

First, is there some docs / comments somewhere that explains why we have separate *View classes? e.g. why there's a GameEntityView and GameEntity (e.g. why there's a PlayerView and a Player or a CardView and a Card) - as opposed to just having a single class. It seems the cache mechanism can get you the underlying GameEntity from its GameEntityView, so it's not clear why we have the separation.

The context for the question is I'm trying to move the caches to hang off the Game object, but while doing so I'm encountering cases where the Game object isn't accessible - so I need to add some members to plumb it through. But in doing so, I want to make sure I don't break some design goal in how the classes are currently structured. For example, would it be OK for a GameEntityView to have a reference to the parent Game? How about having a reference to the corresponding GameEntity? If the latter is OK, we may not need to have the caches it at all - since the view can just have a method to return its entity...

The view objects are to make Forge playable over network. Instead of serialising the entire game state, the server serialises the relevant view classes and sends those over the network. This means that these classes should definitely not have a reference to any game objects (including the Game itself)... But maybe Dan can comment a bit further here, as he created the current version of the view objects.

elcnesh wrote:The view objects are to make Forge playable over network. Instead of serialising the entire game state, the server serialises the relevant view classes and sends those over the network. This means that these classes should definitely not have a reference to any game objects (including the Game itself)... But maybe Dan can comment a bit further here, as he created the current version of the view objects.

Yes, that is the intent of them.