Expand my Community achievements bar.

SOLVED

General Cocomo Questions

Avatar

Former Community Member
I'm going over the SDK and docs for Cocomo and have a few
questions:

1. There is the ability to create rooms, can any user do this
or only specific ones - its seems like in the documents creating
rooms is left to people with "owner" rights?

2. Is there anything that keeps track of a current list of
rooms and who is in them?

3. Can a limit be put on how many people can be in a room so
no more can join it?

4. Can any user join a room of their choice or does someone
with permissions using the "UserManager" have to place them in the
room themselves?



The reason I ask this is I'm envisioning a multi-player game
where:

1. Users log into the game and are dumped into a "lobby"

2. Users can see a list of other connected players as well as
a list of rooms - which is actually a list of available games.

3. Each game room is limited to 10 people so when a room has
ten people no one else can enter.

4. Anyone can create a room (aka: a game), and up to ten
people can join that room, the creator of the room (or game) can
boot people from the room if they choose to.

- that would be the general idea but I haven't dug enough yet
to understand if all this is possible with Cocomo. Any quick
pointers would be helpful.



Thanks,



Chad

1 Accepted Solution

Avatar

Correct answer by
Former Community Member
Hi Chad,



1. Yup, only account owners are able to create rooms. This
would include your server, which can call HTTP APIs to spawn rooms.

2. There are APIs to get the set of rooms on the service
(I'll let Raff speak more to this). That said, it's likely that
your server should be keeping track of what it's spawned and who it
has routed to those rooms.

3. See my answer above - when your server serves up a SWF,
it can use FlashVars or some other means to tell that SWF which
room to connect to. If your server is keeping track of what rooms
it has built and who it has routed where, you can build this
functionality.

4. This depends - "knocking" is one mechanism that forces
someone to allow guest users in, but mostly I'd manage this through
obscurity, using the methods described in 2) and 3) above.



For the workflow you describe, I think you could use a
separate room (or several rooms) as lobbies. From there, every
client in your lobby would ask your server for the list of active
rooms (rooms that still have capacity for more people). If they
wanted to create a new one, they'd ask your server to do so, and
send a message to everyone in the lobby to re-fetch the set of
rooms. For joining a room, they would need to ask your server the
URL for the room they chose, and connect to it. Your server would
keep track of who has requested to join, and potentially, if more
than 10 users have done so, take that room off the list of "active"
rooms.



For the "creator can boot people" workflow, what you're
looking for is the ability to make the person who requested a new
room to be made the "owner" of that room. To do this, you'd need to
use external authentication. See the section on "deploying
applications" in the developer guide for more details.



In short, this all seems possible to me.

thanks

nigel

View solution in original post

2 Replies

Avatar

Correct answer by
Former Community Member
Hi Chad,



1. Yup, only account owners are able to create rooms. This
would include your server, which can call HTTP APIs to spawn rooms.

2. There are APIs to get the set of rooms on the service
(I'll let Raff speak more to this). That said, it's likely that
your server should be keeping track of what it's spawned and who it
has routed to those rooms.

3. See my answer above - when your server serves up a SWF,
it can use FlashVars or some other means to tell that SWF which
room to connect to. If your server is keeping track of what rooms
it has built and who it has routed where, you can build this
functionality.

4. This depends - "knocking" is one mechanism that forces
someone to allow guest users in, but mostly I'd manage this through
obscurity, using the methods described in 2) and 3) above.



For the workflow you describe, I think you could use a
separate room (or several rooms) as lobbies. From there, every
client in your lobby would ask your server for the list of active
rooms (rooms that still have capacity for more people). If they
wanted to create a new one, they'd ask your server to do so, and
send a message to everyone in the lobby to re-fetch the set of
rooms. For joining a room, they would need to ask your server the
URL for the room they chose, and connect to it. Your server would
keep track of who has requested to join, and potentially, if more
than 10 users have done so, take that room off the list of "active"
rooms.



For the "creator can boot people" workflow, what you're
looking for is the ability to make the person who requested a new
room to be made the "owner" of that room. To do this, you'd need to
use external authentication. See the section on "deploying
applications" in the developer guide for more details.



In short, this all seems possible to me.

thanks

nigel

Avatar

Former Community Member
Thanks for the information Nigel. After spending most of
yesterday going over the API I can see how Cocomo is a very
promising project. I think it could be well suited to particular
games and applications and I'm going to continue working with it.



Chad

The following has evaluated to null or missing: ==> liqladmin("SELECT id, value FROM metrics WHERE id = 'net_accepted_solutions' and user.id = '${acceptedAnswer.author.id}'").data.items [in template "analytics-container" at line 83, column 41] ---- Tip: It's the step after the last dot that caused this error, not those before it. ---- Tip: If the failing expression is known to be legally refer to something that's sometimes null or missing, either specify a default value like myOptionalVar!myDefault, or use <#if myOptionalVar??>when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: #assign answerAuthorNetSolutions = li... [in template "analytics-container" at line 83, column 5] ----