It is currently 22 Aug 2019, 18:26
   
Text Size

Traversable Game State/Engine Code

Post MTG Forge Related Programming Questions Here

Moderators: timmermac, friarsol, Blacksmith, KrazyTheFox, Agetian, CCGHQ Admins

Re: Traversable Game State/Engine Code

Postby KrazyTheFox » 18 Sep 2014, 13:31

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):
Untitled.png
User avatar
KrazyTheFox
Programmer
 
Posts: 725
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Traversable Game State/Engine Code

Postby excessum » 18 Sep 2014, 13:41

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...
excessum
 
Posts: 177
Joined: 21 Oct 2013, 02:30
Has thanked: 0 time
Been thanked: 19 times

Re: Traversable Game State/Engine Code

Postby KrazyTheFox » 18 Sep 2014, 14:00

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.
User avatar
KrazyTheFox
Programmer
 
Posts: 725
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Traversable Game State/Engine Code

Postby drdev » 18 Sep 2014, 14:53

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.
drdev
Programmer
 
Posts: 1957
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 564 times

Re: Traversable Game State/Engine Code

Postby elcnesh » 18 Sep 2014, 14:58

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 :P I think it'd just be a shame if they wouldn't be compatible.
elcnesh
 
Posts: 290
Joined: 16 May 2014, 15:11
Location: Netherlands
Has thanked: 34 times
Been thanked: 92 times

Re: Traversable Game State/Engine Code

Postby KrazyTheFox » 18 Sep 2014, 15:04

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 :P 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).
User avatar
KrazyTheFox
Programmer
 
Posts: 725
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Traversable Game State/Engine Code

Postby Agetian » 18 Sep 2014, 16:07

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
Programmer
 
Posts: 3341
Joined: 14 Mar 2011, 05:58
Has thanked: 641 times
Been thanked: 495 times

Re: Traversable Game State/Engine Code

Postby KrazyTheFox » 19 Sep 2014, 02:44

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. :P

I'll be sure to create a branch as soon as it's possible to so people can jump in and help out.
User avatar
KrazyTheFox
Programmer
 
Posts: 725
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Traversable Game State/Engine Code

Postby Myrd » 28 Nov 2014, 06:39

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
 
Posts: 87
Joined: 24 Nov 2014, 05:58
Has thanked: 4 times
Been thanked: 31 times

Re: Traversable Game State/Engine Code

Postby KrazyTheFox » 02 Dec 2014, 02:53

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.
User avatar
KrazyTheFox
Programmer
 
Posts: 725
Joined: 18 Mar 2014, 23:51
Has thanked: 66 times
Been thanked: 226 times

Re: Traversable Game State/Engine Code

Postby Myrd » 14 Dec 2014, 19:35

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.)
Myrd
 
Posts: 87
Joined: 24 Nov 2014, 05:58
Has thanked: 4 times
Been thanked: 31 times

Re: Traversable Game State/Engine Code

Postby elcnesh » 14 Dec 2014, 20:13

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
 
Posts: 290
Joined: 16 May 2014, 15:11
Location: Netherlands
Has thanked: 34 times
Been thanked: 92 times

Re: Traversable Game State/Engine Code

Postby Myrd » 15 Dec 2014, 18:25

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...
Myrd
 
Posts: 87
Joined: 24 Nov 2014, 05:58
Has thanked: 4 times
Been thanked: 31 times

Re: Traversable Game State/Engine Code

Postby elcnesh » 16 Dec 2014, 08:52

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
 
Posts: 290
Joined: 16 May 2014, 15:11
Location: Netherlands
Has thanked: 34 times
Been thanked: 92 times

Re: Traversable Game State/Engine Code

Postby drdev » 16 Dec 2014, 15:02

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.
drdev
Programmer
 
Posts: 1957
Joined: 27 Jul 2013, 02:07
Has thanked: 189 times
Been thanked: 564 times

PreviousNext

Return to Developer's Corner

Who is online

Users browsing this forum: No registered users and 5 guests


Who is online

In total there are 5 users online :: 0 registered, 0 hidden and 5 guests (based on users active over the past 10 minutes)
Most users ever online was 287 on 31 Mar 2019, 04:11

Users browsing this forum: No registered users and 5 guests

Login Form