Greetings, gamedev.net!

This looks like a wonderful forum- one I hope to learn from but also contribute to. I am not so much a "game designer" or "coder" as I am a project manager. I suppose I am a "coder" in the crudest and most rudimentary sense of the word (as you will see.) I am looking for some advice (or help, for any that might be interested) on how to proceed with development on a game I have been working on since 2006.

Through a series of very fortunate events an associate of mine and I discovered a "board game" believed to have been played by the ancient Aztecs; a game thought to have been lost to antiquity. An accounting guy by trade, In my spare time I created an interpretation of the game as a card/board game of which I produced a prototype in 2007 and demonstrated at the 2007 TGIFCon in Orlando to great reviews. I then took a three-year hiatus from development to get married and domesticate myself and leave the accounting world to pursue a career as a business systems analyst.

Not to bore you with any more of the details of my personal life, we have decided the best way to promote the game is to develop the game as a social/casual online game, so I have undertaken the massive project of trying to develop a prototype of the game using my limited skills in.... VBA. That's right, VBA. I actually designed the game to play using Microsoft Access. Why? Well it is the only real language I knew at the moment- i'm really lost when it comes to class/object understanding. Anyway, I am very motivated to move forward to produce a viable prototype that can be played in head-to-head over a network.

[attachment=3723:Game.jpg]


I already have most of the game working now in Access, but I need to create a far better framework (such as to not use database tables as stacks for a deck of cards or a hand.) So I guess what I am looking for as far as advice goes is suggestions on my next steps (Focus on learning better coding, advice for developing a front-end, integrating into a website, etc.)

Thanks in advance!

Dangermoose
Peoria, AZ

First off: Welcome to the forums!

Secondly: What do you want to get out of this project? Do you want to practice being a game programmer, or do you want a game programmed? With a thought out set of rules (which I assume you have since you were able to make a prototype), an experienced developer could be paid to bang out an online card game prototype in no time at all.

If you'd like to give it a go yourself then you've got to define how you want the game to work from the user's perspective. There are quite a few technologies you could use for making a web based card game, and some behave differently. You might use Flash for the front-end with a PHP/MySql backend if you need some real responsiveness, for instance. If the game allows some delay between user action and game reaction, you could use HTML5 (maybe even not 5) and ajax for the frontend, and maybe python on the server. I'm sure the forum is full of people who know better than I do what is best for this sort of thing,

[quote name='dangermoose' timestamp='1309308400' post='4828894']I guess what I am looking for ... is suggestions on my next steps (Focus on learning better coding, advice for developing a front-end, integrating into a website, etc.)

If you could narrow down all that into some discrete questions, that would probably better net you some good answers. How to ask good questions
[/quote]

Sorry, Tom... you're right, I didn't really ask a good question. Thanks for the hyperlink...

I guess I have a few questions: I know a little about coding but the object-oriented stuff confuses me- and I don't find the "Class Rectangle()" examples at all helpful. Do you know a good tutorial or book for someone like me to better understand objects/classes and best practices for OOP frameworking? Also, would anyone have recommendations on an easy-to-use SDK for modeling cartoon-style characters in 3D? And finally, has anyone ever put together a sucessful business plan for a game they have developed and might they have any suggestions for someone looking to develop one?


Thanks again,

-Moose


(p.s. - BTW Tom, I just realized, your website (Sloperama) was really a great information resource for me while I was designing the game board, cards and instruction manual back in 2007! Thanks for that!)

First off: Welcome to the forums!

Secondly: What do you want to get out of this project? Do you want to practice being a game programmer, or do you want a game programmed? With a thought out set of rules (which I assume you have since you were able to make a prototype), an experienced developer could be paid to bang out an online card game prototype in no time at all.

If you'd like to give it a go yourself then you've got to define how you want the game to work from the user's perspective. There are quite a few technologies you could use for making a web based card game, and some behave differently. You might use Flash for the front-end with a PHP/MySql backend if you need some real responsiveness, for instance. If the game allows some delay between user action and game reaction, you could use HTML5 (maybe even not 5) and ajax for the frontend, and maybe python on the server. I'm sure the forum is full of people who know better than I do what is best for this sort of thing,

Koobs,

Thanks for the response! I think at this point what I really need is a consultant to look at what I have and give me some advice on what I would need to do next. Although I'm very do-it-yourself and still want to learn better backend coding as well as develop some artistic talent on the frontent, I think I'd really like to hire a programmer and/or artist to help me finish. My goal is to get the game released before Dec 21st 2012 (as that is the end date of the Aztec calendar would have a great marketing tie-in )

Your suggestion about Flash with PHP/MySQL is intriguing to me as I already have much of the backend code in MS Access now. I have some MySQL administration experience so I don't think that would be a stretch for me to understand. If I can pick your brain a little on this idea?

The idea I have for this project is have people log into a gaming and information site that keeps and maintains some basic user info, game statistics (wins, losses, points accrued, etc.), and maintains a "locker" of sorts for power-ups, achievements, rankings, etc. On the site they can challenge players, play against a computer opponent, learn how the game is played, "watch" a match (ladder matches).

If I were to go with Flash and PHP/MySQL - when a match is being played between two people, what would the model look like? (Again, forgive me, the only thing I know less about coding is web development...) Would MySQL server handle not only login information but also live gameplay (tblCards, tblHand1, tblGameBoard, etc.) or would there need to be some intermediary server that would have to have an instance generated on a server that both clients would have to log in? or would one of the clients have to act as a game server?

Again, thanks for the advice!

-Moose

You've got a lot of options and we're quickly leaving my realm of experience, but here's how I would do it (more experienced forumites, feel free to jump in!)

I would try to avoid Flash by doing as much as possible with other web standards. It's getting easier everyday to make interactive websites without resorting to learning Flash programming (which is kind of ugly, IMHO). I'm thinking HTML and JavaScript, using an established JavaScript library (jquery?) for the ajax stuff (handling updates on the webpage without the user having to reload the whole page). This goes on the frontend and runs in the user's browser.

The browser would connect to the webserver in the standard fashion, where a LAMP(Linux, Apache Webserver, MySql, PHP) stack would be waiting. I'd go with LAMP because of its maturity; there are tons of resources for learning to work with this stuff. I myself prefer a higher level and more object oriented framework like Ruby On Rails, but I think you may be more comfortable with PHP without an object oriented background (just a hunch, I could be wrong).

The webserver (Apache, in this example) would run PHP scripts that live on the server to generate the webpage that the user sees. The PHP scripts have access to the MySql database, so they would be the only ones that would actually talk to the database. To see a list of achievements, for instance, the user may navigate to www.example.com/achievements.php in their browser, Apache would execute achievements.php which would use database queries to pull a list out of the MySql server and generate an HTML list from the results, which would then be sent back to the user as a plain old HTML file.

For a two player game, I imagine it would go something like this. A player would click on whatever to make a move which would fire off a request using ajax to the server with POST parameters indicating which player, what move, etc (/move.php?userId=...). The server would handle the request with a PHP script that would update the database. The other player would either poll with ajax or wait for the server to notify the player with comet (like ajax, but different. google can fill you in on the specifics). Either way, the other player would make a request to get the state of the board (/gamestate.php?gameId=...), which would fire off some PHP to query the database and return the board state to the JavaScript running in the browser, which could then update parts of the page to reflect the first player's move.

At this point, I'd look for a framework. You could implement the whole site yourself, but you'll get off the ground more quickly with some help from a framework like Zend or CodeIgniter (these are for PHP, there are equivalents in other languages). These handle a lot of the boring and tedious details of building a website. They may also be able to help you with a database layout that will work well for backing a website.

I've skimmed over a lot of details, but that should give you a place to start. Let us know if you have any more questions.

tl;dr - JavaScript/ajax frontend, LAMP backend

You've got a lot of options and we're quickly leaving my realm of experience, but here's how I would do it (more experienced forumites, feel free to jump in!)

I would try to avoid Flash by doing as much as possible with other web standards. It's getting easier everyday to make interactive websites without resorting to learning Flash programming (which is kind of ugly, IMHO). I'm thinking HTML and JavaScript, using an established JavaScript library (jquery?) for the ajax stuff (handling updates on the webpage without the user having to reload the whole page). This goes on the frontend and runs in the user's browser.

The browser would connect to the webserver in the standard fashion, where a LAMP(Linux, Apache Webserver, MySql, PHP) stack would be waiting. I'd go with LAMP because of its maturity; there are tons of resources for learning to work with this stuff. I myself prefer a higher level and more object oriented framework like Ruby On Rails, but I think you may be more comfortable with PHP without an object oriented background (just a hunch, I could be wrong).

The webserver (Apache, in this example) would run PHP scripts that live on the server to generate the webpage that the user sees. The PHP scripts have access to the MySql database, so they would be the only ones that would actually talk to the database. To see a list of achievements, for instance, the user may navigate to www.example.com/achievements.php in their browser, Apache would execute achievements.php which would use database queries to pull a list out of the MySql server and generate an HTML list from the results, which would then be sent back to the user as a plain old HTML file.

For a two player game, I imagine it would go something like this. A player would click on whatever to make a move which would fire off a request using ajax to the server with POST parameters indicating which player, what move, etc (/move.php?userId=...). The server would handle the request with a PHP script that would update the database. The other player would either poll with ajax or wait for the server to notify the player with comet (like ajax, but different. google can fill you in on the specifics). Either way, the other player would make a request to get the state of the board (/gamestate.php?gameId=...), which would fire off some PHP to query the database and return the board state to the JavaScript running in the browser, which could then update parts of the page to reflect the first player's move.

At this point, I'd look for a framework. You could implement the whole site yourself, but you'll get off the ground more quickly with some help from a framework like Zend or CodeIgniter (these are for PHP, there are equivalents in other languages). These handle a lot of the boring and tedious details of building a website. They may also be able to help you with a database layout that will work well for backing a website.

I've skimmed over a lot of details, but that should give you a place to start. Let us know if you have any more questions.

tl;dr - JavaScript/ajax frontend, LAMP backend

Ok! I'm getting it! This helps out quite a bit, Koobs. Thanks. A couple of quick follow ups tho-

Although this is a card game and, thus a turn-based game, there is an element in the game that requires the opponent to see a _MouseHover event from the player on the game board, that would probably be too taxing for AJAX/JavaScript implementation- and even if it were possible the motion would not be terribly fluid. (though couldn't the _MouseHover calls be handled with UDP and actual game play be handled with TCP? Or do I even know what I'm talking about?) If web standards are an issue I agree I'd rather steer away from flash, however, with an intent to make this cross-platform, aren't their AJAX/JavaScript limitations with mobile phones, or would the client for those have to be more of an "app" (written in, oh, perhaps Python?)

Thanks again!

-Moose

If you don't intend to profit off the game:
Since you've stated you don't have much programming experience, I'd recommend you take a look at Flash (I hate myself right now -- many programmers find Flash abhorrent, but non-programmers think it's the greatest thing in the world). Flash is used to play Facebook games and watch Youtube videos, for your own reference. There's also a handful of well-known sites that host collections of flash-based games for your convenience. I'd rather not list them as many are infested with malware, but you can find them if you look.

If Flash isn't for you, then perhaps Java is. Once upon a time, Java was frequently used for the same things that Flash is used for. The client for the MMORPG RuneScape is written in Java (i think the game sucks, but that has nothing to do with it being written in Java). Java is commonly used in teaching programming nowadays, but it is also used for development for many mobile devices (see: J2ME, Google Android, Amazon Kindle).

If you intend to profit off the game:
Java may still be an option for you. As I said, Google Android uses Java (in conjunction with its own APIs) as the preferred means of development. Many games in the "Android Market" go for about $2.00, so you can make a little money from it -- but unless your game winds up being the next Angry Birds; it's not likely to make you a wealthy man.

If you want to stick to PC, there's a large number of options. My recommendation is to not try to use fancy 3D graphics and stick with 2D, then to use C++ and SDL. SDL remains my preferred development library for 2D games. It's portable (Windows, Linux, Mac OS X; with some extra work on your part, iPhone, Pocket PC / Windows Mobile, Palm Pilots, some older Samsung Phones, and Google Android), simple (SDL stands for "Simple DirectMedia Layer"), and fairly efficient. The beta version of SDL has not yet caught on (that's what I'd recommend if you had prior C/C++ experience), but the last major release version of SDL is a very commonly used library for open-source games, and numerous tutorials (LazyFoo has the best, IMO) exist for it. You can distribute via Steam; they take a little off the top but you'll get much more money in the long run because more people will be made aware of and try your game.

Being able to show the opponents mouse position puts you into the realm of "real-time games". This is still possible, but makes everything harder since you will have to deal with lag and such. In dealing with lag and such, tools used to build real-time games are more complicated. You are right about UDP being a better fit here, unfortunately there is no (good) way to get ajax to talk anything but TCP. Even then, the webserver isn't really built for bouncing messages from one user to another quickly, so that'll have to change also. With that in mind, let's look at some options for the frontend.

I agree with nfries on a number of counts. Flash is back on the table as an option, and so is Java. If you go with a desktop download-then-play application, C++ and steam might be a good way to go, although C# and steam may be better so you don't have to inflict C++ on yourself (here be learning curves).

Flash is still an ugly language, but it has a large install base and has seen a lot of use in browser games. Flash also doesn't do UDP, but it can do TCP in a faster way than ajax.

Java is not a bad language. It is easy to pick up for beginners and there is almost nothing it can't do. It has a pretty large install base, but less than flash IIRC. You get some cross platform support as well. You'll get Windows, Linux, Mac with one version of the program. It can run either from the desktop or from the browser. To run on an Android phone, you will need to write in java. You'll have to tweak a few things from the PC version, but a lot of code can be reused. I would aim for a separate phone app instead of running from the phone browser. Also, how will the mouse hover work on a phone?

Now the backend. Unfortunately, a webserver will not do for the realtime elements, so you'll have to come up with your own server. You get to choose any language you like for this; they can all be made to work. There are a lot of pitfalls in making your own server, including dealing with security vulnerabilities, the strain from lots of users, memory leaks, etc. All the problems get worse with more users. Writing robust, public-facing servers is well outside my expertise, so you'll have to ask someone else for help there. I would imagine you could make your life easier by keeping all the ancillary functions like achievements and match-making on the webserver and keeping the game server itself small and simple, maybe even try a peer-to-peer setup. I'm just speculating here though.