Hi, I am currently working on a game but once I get some free time, maybe I like to start a small project which is to provide a community web-based game development platform. I am at the initial "conception" stage and tyring to see if it is worthwhile to pusue this and any feedbacks would be appreciated. The thing I want is a web site that provides a central location for users to sign up using SSO mechanism (such as Windows Live ID, Yahoo BBAuth, OpenID, etc) and - provide *game developers* basic API for getting user identity for his/her game - provide *game developers* ability to register their games (such that it will show up in the list of free games) - provide *game users (gamers)" with list of free games - the games can be sigle-player, but encourages multi-player by providing basic match making features imagine, today, to build a simplest multi-player web-based games, you have to manage user accounts/password etc. My service will take care of that part so you can focus on writing game logic. For example, you have a HTML based game (hosted somewhere of your choice). When certain things like a user winning, it makes HTTP forms submition to my service to write to the score board. There are security issues, which I am thining using time-spamped encrypted token passed around (via query string, forms field, etc.) so that game developers can validate it. (and maybe setting up a common secret key between game develper and my site, for symetric encryption, etc.) I have started mental exercise to see if its feasible, and I think it is. I just need to learn more about requirements. Thanks for reading up to this. Apprecaite any feedback, if any. -yoshi

Kenneth,

Thanks for your great input.

Your point about handling OpenID by yourself is valid and that it self won't add much value to my service. I haven't done OpenID yet, but Windows Live ID and Yahoo BBAuth were so easy that it takes a day or two to set it up... by anybody. Clearly, I would need to add more than that.

As for trust and reliability, I would almost have to commit to data center and promis some sort of written mimimum guarantee, I suppose. That would be one hurdle to go over. Your feedback reinforces that point - and that might be too high for me to go over, at least in the initial stage. Anyhow, point taken.

Traffic. You are saying that develpers would tend to go to "established" portal rather than a new service that nobody knows about yet. This tendency is stronger for a single player simpler games. Point taken. My feeling after your input is that perhaps I should completely focus on "multi player games" that and forget about "single player games" - a quick googling tells me that there thousands of free game portals already established.

Kenneth, right now I am struggling to understand how "multi-player web-based games" are architected. I am a professional ASP.NET developer so I understand the basic web-based applications. Whether you use HTML, &#106avascript, Flash, Sliverlight (and PHP, ASP.NET, etc. for server side), you have to solve the "stateless" nature of web application. In particular, one of the online users performs an action, which causes some state change on the server side, the only way to get that user's action reflected on other users views is by having a polling mechanism from user agents... correct? Sorry, if this is a dumb quesion - I just want to establish a solid fact here.

If that is the typical web-based multi-player game architecture, then my API has to be designed around that architecture.

Your other inputs: basic match making + some sort of user-to-user communication palform (chat), and attractive UI, seem essential to me to. Thanks for affirmation.


by the way, the game I am developing right now is a client-server app using TCP based on Socket (it used to use DirectPlay but I pulled it out as MS dropped it from the DirectX package). I was thinking I would add support for TCP with binary formatted protocol for future, but do you think there might be more people interested in?

Sorry for a huge message (should chuck it up, I suppose)

thanks.

Kenneth,

Thanks again for detailed reply to my queries.

I never knew the term PBBG, but now I do. You pointed me to several useful links and basic concepts/technologies. I will be busy reading these articles for a while.

I am also going to play some of the PBBG out there to get a feel for requirments, and I probably should write one.

I am still not quite sure how a user who is looking at a page (static) gets the updated world when another modified it... without some sort of polling. Maybe I just don't understand the types of games written in PBBGs. Say, if I were to write a chess game, unless I refresh the browser (to make a HTTP request), I am staring at the stale world data.

Anyway, I have lots of readings/researches. Hopefully, it will come clear gradually.

Thanks,
-y

Hi thethanghn,

I just looked at your site quickly and looks like you have build a ton of features there. All by yourself? Cool! I don't plya Yugio (what a shame, I am Japanese and grew up there and it was on Shonen Jump magazine... I was just leaving Japan when Yugio started so never got into..)

Anyway...

Yeah, I've been continueing my research on this. I learned what Reverse AJAX is and especially Comet (slow loading) technique that web-game devs can use to build more real-time game.

But my main focus is to build a tool that help build games... not game itself. Here is what I see so far

A web-based games can be broken down to these components:

a. User account management service
b. User scoreboard service
c. Match making service (for multiplayer)
d. Data storage service "P" part of PBBGs
e. Business logic service (the actual game rules and logics)
f. Presentation layer (views, shapes, pages, animations, sounds etc.)

What game developer want to spend most of time is in 'e' and 'f', I think.
'a' is boring but hard and users may have more registance (the feeling you have when you have to provide your name, password, etc to just use a service)

'b' and 'c' might be specific to games, but I think it can be abstracted. Like your Duel system, its 1-on-1, right? For some games, its 2x2 (say, veritual tennis). Some are "free-for-all" up upper limit. And multiplayer team based ones. I think we can support most of these.

'd' is also boring. I just want to "save" data and move on.

So, what if a framework takes care of all of these...?

[Framework]
a. User account management service
b. User scoreboard service
c. Match making service (for multiplayer)
d. Data storage service "P" part of PBBGs

[Your Game]
And you can implement the following at your web site anyway you want.
e. Business logic service (the actual game rules and logics)
f. Presentation layer (views, shapes, pages, animations, sounds etc.)

Obviuosly, there has to be a communication between [Framework] and [Your Game]. If we restrict the communication between these two to HTTP, then many poeple will be able to write games. (I wouid also like to have TCP protocol but that's for later)

That's what I got in my head so far.

Kenneth,

Yeah, I just did a quick design write up to discover what it would take to build a simple 2-player tic-tac-toe game (sort of mental exercise to handle signing up, match making, game setup, game start, game update, game ending, recording result, etc. using a simple web-based game with ajax/comet).

It is becoming clear to me that abstracting "storage" layer (and above) is just not going to be feasible. Maybe I can serve certain type of games, but creating a virtual database using physical database (while keeping performance reasonable, as you pointed out) is not trivial.

I am gradually shifting from concepts to design/implementation, and hitting lots of issues.

Scoreboard service, which already have lots of variations, is probably where I can realistically stop. I still think SSO, user account management, matchmaking are doabine.

thanks for keeping an eye on this thread!

-y