Request for Comment: Is SGS valid for this?

Ok, let me preface this by saying there are really only two key reasons I’m considering SGS for the following small project:

  • As you might have picked up from some other posts, SGS is a technology I’m looking to use for a future project. I’m not ready to dive into that yet because I’m still working on the design and also I need to get some completed, smaller scale projects under my belt first. However, with SGS in my strategic plan I would like an excuse to start learning it soon.
  • SGS offers a lot of the foundation already bundled in to some degree or another. I would not need to reinvent the wheel for logging in, player persistence, chat, client/server communication, object store, etc.

That being said, here’s the issue. I’m wrapping up the design work on a smaller scale game and am ready to start getting my hands dirty. It will be a client/server game and I before i start down the SGS or non-SGS road I would really appreciate some guidance and feedback from members of the the SGS team or anyone else on this forum that has some working knowledge of SGS so far. As I mentioned in another thread, using a technology just because it’s there and cool is not always the right decision. 8)

The quickest way I can provide a framework for a discription is to say “think in terms of a collectible card game”. This is not a CCG-via-computer game however, but the game play is similar. Small groups of players ( 2 - 10 ) will join a game that will play out in a time frame between 30 minutes to 2 hours. The game is turn based, with each turn being broken into five distinct phases ( planing, execution, aftermath, etc ). During each phase the players are each able to take multiple actions, one at a time, in round-robin fashion ( A then B then C then A again, etc ). When each player has completed all their actions for that phase it moves on to the next phase. When all phases are complete, the next turn begins.

The game server should be able to have multiple “games” running at one time, but these do not equal multiple instances of the SGS running. Simply segregations of player interraction. A player can only participate in one “game” at a time of course. What I would like would be to have a lobby when the player first enters the game where they can see who else is there, chat and possibly even leave messages on a board ( such as “looking for people that can play between 8 and 12 gmt” ). Once a few players decide they would like to play a game togther, they go to a “room” to start. No other players can enter once the game starts and when a player is eliminated he leaves the room and returns to the lobby. *

Maintaining the CCG analogy, each player will have a large number of “cards” available to them. Some of these are unique for them (assigned when they enter the room ) and others are from one or more common “decks” and go to players on a first-come-first-served basis during the phases. Card objects may be played as a standalone entity ( like an army-unit ) or may enhance other objects ( like “resupply gives +1 to an army unit” ). All players in a room share a common battle map that they play and manuver thier objects on. Some objects are played “face down” where other players can only see that you have “something” there, and only you can see the details. However, most objects are “face up” once they go onto the map.

Also I would like the players to have the option of saving the game state, walking away and all of them coming back later. This is not a necessary feature since I’m trying to keep the games short, but it would be a major “plus” as it would allow for larger games ( such as 10 players ) to be spread out over time if they are going well rather than commiting to a 5 hour marathon.

Ok…now that you have taken precious time to read thru that ( thank you very much for doing so ) I would appreciate any guidance you may have. It would seem initially to me that SGS provides a good framework for the lobby and seperate play rooms as well as the chat,network, object store, etc as mentioned above. However, I’m not sure about the need to have multiple “games” running, one per room. Again, I believe I could do so since SGS will know who’s in a room ( player objects, a table object and a couple “deck” objects ) and what “cards” each has. With every action a player takes it would naturally generate an event to the SGS and only player actions will generate events ( no “global” events to worry about here ). The use of SGS will allow the game to start small and scale up if interrest is there. **

Am I missing any details about SGS that would make it difficult to use it as a framework for implementing a game of this nature? ???

As always, advTHANKSance !!! :slight_smile:


NOTES: * Note: One enhancement would be to allow players to enter a room as an "observer" and only be able to see the map. They can see all face up objects as can any player of the actual game, but cannot see any face-down objects. They can also watch the chat in the room but cannot send messages themselves. When a player is eliminated, they can be given the option of staying in the room as an observer or return to the lobby. The player vs. observer states is not going to be too hard of an addition but it is still not something I'm planning right away.

** Note: The game will be freeware and open source. As such it will never be intended as a revenue generator. A big part of its implementation is to serve as a proving ground for some interface, technology, and game play exercises for the larger project. So it will primarily just run on a private, quiet little server…but you never know what the future holds.

Your description has pretty similar semantics to the Stomping Grounds game - which according to the authors was a great fit for SGS. You might also consider the Game Gardens framework.

Kev

Yeah, it sounds just fine as an SGS approrite app. You coud look at the “BattleBoard” example for a simple example of this kind of game.

Kev & Jeff,

Thanks not only for the validation but for some examples to look at. THAT’s always a major life saver.