Browser Game. PHP, ASP Or.....

Firstly, whatever dynamic web language you're planning to you, you'll very likely need to consider a database as well. Assuming you plan to host your application online, chances are it will be cheaper to go the PHP / mySQL route because both products are open source and hosting is usually cheaper than for other technologies. In terms of hosting, ASP.NET is usually coupled with SQL server. ASP.NET is very easy to work with thanks to VS IDE but your overall running costs are likely to be higher.

Anyway, you'll probably need to start one step at a time, so I would suggest you get some simple web apps running first.

 

Whatever strikes your fancy I guess!

Assuming you go for PHP / mySQL, you could try writing a PHP page to load data off a table from mySQL (think football scores as an example) and proceed from there.

It's probably worth looking up a couple of tutorials for writing web applications in general and then narrow it down to a specific technology as a starting point.

 

You could take a look at
http://www.victorchandler.com/vc_games.jsp

Penalty! (our game)

and

Footbal 24/7


Also,
http://www.hattrick.org is unbeatable.

 

A great way to get started with apache,php, and mysql is to use XAMPP - which is a pre-built installation of all you need to have a database + webapp:

http://www.apachefriends.org/en/xampp.html

 

I've been writing web-based apps for the last 7 years (holy crap has it really been that long!?!?) and I definately suggest you go with PHP on a unix box of some kind (I recommend FreeBSD.)

As for a database, everyone jumps on the MySQL bandwagon, but personally I suggest and prefer PostgreSQL. Let's not start a flam war here of Postgres vs. MySQL, but there are advantages to each one and that's something you will have to research and decide. I think Postgres is faster, scales better, and is easier to use than MySQL, but that's just me. Postgres also offers *real* SQL transactions which are cirtical in business or financial apps. To be fair, MySQL does also offer transactions, but only in their high end not-free version.

Personally I think web-based apps, uhm, well, suck... Having been doing it for so long, it really becomes repetitive and boring. Trying to get HTML to act like an application and do things it was never meant to do can really get to you. You will spend most of your time making forms, collecting information, storing the information in the database, pulling the information back out, and formatting it for presentation. Did I mention this is terribly boring? There are some moments when you will enjoy it, maybe. If you like doing graphics then you will enjoy the page design part, but that becomes such a small part of the whole project that the enjoyment is short lived.

It is very hard work! You're going to need to know:

* Unix administration, setup, configuration (if you use a unix box.)
* How to maintain your server and keep is safe.
* Web server admin (Apache is recommended.)
* HTML, JavaScript, CSS, and the DOM.
* Graphic design and layout.
* A language like PHP.
* Database setup and admin.
* Data table design (do you know what I mean when I say "3rd normal"?)
* How to interface with a credit card processor (you are going to make money with this game, no?)
* How to deal with customers, chargebacks, fraud, etc..
* How to write apps such that you are not susceptible to session hijacking, SQL insertion, and session fixation attacks.

Did I miss anything? I also highly suggest you learn some form of MVC (model, view, controller) architecture and apply it. That alone will save you days or weeks of time! But, MVC is not something you learn overnight either.

All of this and more can be yours for only 7 years of your life! But wait, that's not all...

Sorry, got off a little there. All this and more is why I'm trying like heck to get out of web-based apps and write games. You will spend more time working on everything else and less time on the actual game. Also not to mention that no two browsers are alike, thus you will pull all of your hair out trying to make sure everything looks and acts the same across multiple platforms.

So, if you are still reading, I would suggest you start with getting your environment set up (Apache, PHP, database (Postgres or MySQL)), make a few tables in your database, and get familiar with collecting data from a form and then presenting that data. Make it anything you want, an address book, sports scores, trivia, whatever. After you're familiar with the mechanics, I would strongly suggest you either find or write a framework. A framework is basically all the foundation functions you will need on a regular basis, like session persistence, authentication, a database abstraction layer, permissions, templates, etc.. Think of it like a FPS game engine like the Doom3 or Unreal engines. Writing a web-based app without a framework would be like writing a FPS without an engine; it would be very hard and you would most likely end up writing your own engine first.

I hope this helps. I'm not trying to discourage you, just letting you know what comes with a dynamic web-based environment. As an indie you will wear many hats and have to know a lot about a lot of things. If you just want to make games, there are 1000's of better options.

Matthew

 

On a happier note than Matthew, it can definately be done, and it has some real advantages for your players. Most notably, your games can be played anywhere, anytime, with no download or installing... People can play at school, at work, at home, on their laptops in the airport... anywhere.

Don't ever discount the power of that. AOW: 4025 gets a large part of its draw from the fact that it is an online and persistent world that is played 100% through the browser. The players play from every location you can imagine. And many check in on their factions from on the road, on vacation, and all hours of the working day...

That being said, Matthew is right on the aspect of some of the tedium. You'll spend as much time writing out error checking, backend functions, and administrative tools as you will the actual game... However, the dynamic and real time aspect of the genre can be fun as well. Find a bug, fix it, upload it, and all your users are instantly updated... kinda nice in that respect...

Just keep in mind while designing your games, that there are inherent drawbacks to doing things on the web. Security demands can be rough on you at times, and your graphical power is severly limited. Also, if you have any inter-player interaction at all, protecting your data is of key importance. You have to plan your code to include lots of server-side checks, and most actions *have* to go through multiple page submits to the server to verify (client side javascript is easily hacked, as are any submitted form values, CHECK VALUES for accuracy before submitting to your DB).

I programmed AOW: 4025 in Cold Fusion, using MS SQL on the backend. I can't recommend CF enough. It does cost money, but the power, support, and security are top notch. Also, IMO, it is by far the easiest to learn, and quickest tool out there. CF was also designed with it being a Rapid Application Development platform, and it accomplishes that admirably in almost all aspects. I think you should at least consider it when deciding on languages. (You can get free developer versions of the server software at ColdFusion.com, it can connect to pretty much any database type.)

The one question you have to ask when choosing a DB, is how much power do you need from it? There is really a difference between MySQL, and MS SQL, or Oracle when it comes to scaling up to large numbers of players and transactions. MySQL is free, but you *will* eventually hit its ceiling if you push it hard and get popular. Much safer IMO to go with with a higher end DB solution, even though your costs will obviously increase. (MsSQL and Oracle both have developer/single-user versions as well for you development needs... so you can put off increased costs on all of this until you need a live web host)

 

Certainly it can be done, I was not trying to convey that. But trying to break into the indie business is already hard enough for a beginner, no need to make it even harder. Unless one is already set up to do web based apps (and had some real-world experience), I would recommend something a little less involved for the first game or two.

Also, the security ramifications are massive. If you don't understand totally what you are doing (a nice SQL insertion bug for example), you could lose your whole game in an instant. That's one thing you don't have to worry about when the game is installed on someone's computer.

Web-based apps are a totally different animal than desktop apps and anyone considering web-based should weigh their options carefully.

I did take a look at AOW: 4025, it looks pretty nice! You have done an excellent job to say the least. It makes me cringe just thinking about what you went through to get it working smoothly and looking like that. Good work!

Matthew

 

One of the best reasons to weigh the web option, though, is the reduced overhead to manage an MMOG. AOW does not require clusters of servers, or specially built client software. ColdFusion and MS SQL handled all of that architecture for me, and allowed me to concentrate on game elements, not to mention being vastly cheaper.

Granted, AOW is not a real time persistent MMOG. Actions are only taken when you hit a button to confirm an action in the game, and the game management stuff ticks off on a set schedule. But for strategy games such as AOW, or sports management sims like Alfred are planning, this works out just fine. For games designed with how the web works through a browser, it can be a huge plus for small design teams.

After all, I was able to create what you can class as an MMOG singly handedly (as far as the core gamecode goes) and on a shoestring budget, which is not something any MMOG client apps that I know of can really claim.

 

On a side note, has anyone tried writing a web-based game using AJAX?

Fancy names aside, it comes down to using the XMLHttpRequest object to load new data for a page without reloading the whole page. Combined with DOM scripting, you can write nice fast web-apps (such as GMail and Google Suggest).

I've been tinkering with it during quiet moments at work. I had no trouble getting a simple online tile based map that players could run around on and see each other, updating from the database 4 times per second, which really isn't that bad.

I'm thinking this could be ideal for turn-based games like a Civilization clone.

 

Why bother with DHTML if there's Flash?

 

AJAX sounds really good for stuff I might like to do... do you have any better resources, tutorials, or examples? I followed some links on that article and quickly sank far in over my head. There was a simple tutorial at here (linked from that article) which I almost followed, but frankly didn't know what files all the little parts should be in... never done any XML or CSS stuff. Maybe recommended reading?

 

emuLynx, well, Flash has it's good points and it's bad points like everything else, and won't always be ideal for what you are trying to do.

For example, Flash vector based, but I'm thinking ajax could be perfect for pixel art based games. Flash needs an IDE, ajax can be written in any text editor you like. Of course, on the other hand, Flash will be able to pull off a heap of grapical things ajax never will.

I personally intend to work on a project that uses both ajax and Flash...

Oh yeah, another idea for ajax; you could write the game engine in Javascript, for example, a simple RGP of some sort, then have all the 'rooms' or maps, datafiles etc, in .txt files, and people would be able to download and run the whole thing on their own computer. So there you go, one player games with a web language. You could even use cookies for a load/save system.

Hi Hamumu, yes I got bogged down on those tutorials too, but I ended up working out it's all a lot simpler than it sounds.

You don't actually have to use XML at all, you can retrieve plain text instead.

Here is a very simple example of it in action. Note the innerHTML function is depreciated but I'm a bit lazy so I used it anyways... This will run either online or on your computer:

Create a file called test.txt with the following in it:

Code:

Testing 1,2,3

Then create an html file, and stick this in it:

Code:

<html>
<head>
	<title>XMLHTTPRequest</title>

<script type="text/javascript">

var xmlhttp=false;

/* first we create out xmlhttprequest object. unfortunately there are three ways to do it, depending on which browser the user is using, and two of those ways are for IE... */

// this trys the two ways for IE, both use ActiveX to create the object...

try {
	xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
	try {
		xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
	} catch (E) {
		xmlhttp = false;
	}
}

// if our object still doesn't exist, then use the w3c way

if (!xmlhttp && typeof XMLHttpRequest != 'undefined') {
	xmlhttp = new XMLHttpRequest();
}

// here is one way to use the object:

function loadStuff() {

	// the url can be relative or full, and you can use GET or POST 
	xmlhttp.open("GET", "test.txt", true);

	/* the object has different 'states' depending on it's up too. Basically, you wait till it's state changes to 4, so we know it's recieved the data back, then we can use it. */

	xmlhttp.onreadystatechange = function() {
		if (xmlhttp.readyState == 4) {

			// stick whatever you want to do with the data once it arrives in here:

			// we are simply going to put the text into our div...

			document.getElementById('aDiv').innerHTML = xmlhttp.responseText;
		}
	}

	xmlhttp.send(null)
}

</script>

</head>
<body>

	<p>This is a page.</p>

	<p><a href="javascript:loadStuff()">Get more content</a>.</p>

	<div id="aDiv"></div>

</body>
</html>

Lastly: here is the above example online except instead of just returning static text, I'm grabbing a timestamp from a php file (which contains nothing but:

Code:

<?php
echo microtime();
?>

http://www.systemworks.co.nz/chris/xmlhttp/time.htm

So every time you click the 'Get more content' link, you get the current timestamp.

Cheers,
Chris.

 

Thank you very much! I see the POWAH!

 

Not a problem!