ZenAndGames.com

A friend of mine directed me to this article written by a real life game journalist on getting media coverage for your indie game. Definitely a useful read for anyone who wants to make indie games that actually make splash (and you should be.)

I’m currently working on this myself for the game free online space game Starport. It’s been around for a few years now but we’re trying to get some coverage and help it grow more. Anyway I’ll share more about that game and what I’ve learned from helping market it later but for now get to reading this article.
How To Use And Abuse The Gaming Press And How The Gaming Press Wants To Use and Abuse You.

Sorry for the delay everyone I’ve been totally slacking off but I’m going to try and get all of these summaries of the sessions from the Austin Indie Game Conference written up quickly for you. Also if there are any errors in here I apologize and blame my memory giving out over the holidays

On Thursday morning the Gamecock heads were supposed to give a keynote but they couldn’t make it and VP Steve Escalante gave the presentation instead. Gamasutra already has a great write up on this keynote so I’ll just direct you there and give you my thoughts that may complement theirs.

Gamecocks Thursday Keynote

Steve says you must make sure that you are ready to do game development. Also you have to think about the other teams that you’re competing against to win those publisher dollars. Right now the opportunity to create original intellectual property and be successful with it is greater than ever as consumers are getting tired of the crappily done movie licenses and rehashed sequels, lots of players want fresh new games. Furthermore the digital space removes a lot of the barriers to entry that used to exist, with digital distribution a game can become successful even without breaking into the major retail channels. They feel that digital distribution portals like steam can sell 25% as much as retail which could turn a nice profit when you consider the portion of the game price that the retailer takes and the manufacturing cost of packaging materials.

The Gamecock group doesn’t believe that the giant budgets that exist now for major games are needed. By working smarter a game of equal quality can be created for a fraction of the cost. Included in this is outsourcing of some of the development work which lowers the budget and makes it more presentable. On the upper end Gears of War launched for $10 million so any more that that is certainly not necessary.

Steve also gave an example of the sorts of projects Gamecock is working with. He mentions that Dementium Ward for the Nintendo DS was made by 3 guys in only a few months and it went on to get very good reviews. They are also publishing Pirates Vs Ninjas for the Xbox Live Arcade which is being made by 3 guys and costs less than million to make.

The keynote also gave some great tips for people trying to get in with a publisher (or at least if you want to be published by Gamecock as they’re a bit different than most publishers). First you want to consider does your game appeal to a majority of gamers and can thus compete in the market. Also do you think your game will sell well enough to be in the top 20% of games that generate 80% of revenues. Another important thing is a good vertical slice (a playable demo) that you can show the publisher when you talk to them to help them get excited, this isn’t necessary always but can help tremendously. He also mentioned, however, that you should be looking to make the game you want to make and not the one you think will make the most money. Furthermore you should consider monetization methods during predevelopment if you plan on doing something fancy like ad supported gameplay or micropayments since revenue models can be extremely hard to switch near or after game launch if it turns out they won’t work.

Last week the Independent Game Conference was held in Austin, Texas. Last year I attended the same event and was able to get a lot out of some of the sessions so since I’m in Austin I made sure to attend the event this year as well. Once again several of the sessions were very informative and over the next week or so I’ll be transcribing my notes about them.

Sessions were held in two tracks, business and technology. I attended sessions of both tracks and will write my impressions on them soon. There was also a very interesting keynote by Richard Garriott on game design and research. The coolest part of the conference, however, was the game festival night where attendees can show off the games they’ve worked on and everyone can check it out. I was helping show Starport but I also checked out lots of cool games which I’ll probably be talking about here as well.

I attended the event last year as well, before I started this site, and I believe somewhere I have my notes from then so I’ll try to find them and write about some of those sessions as well because there were also some very good sessions last year. So stay tuned in the coming week or two I’ll post about the talks that were given and some of the games shown, I’ll update this post with links to them as I write them as well.

The internet is abuzz today with the announcement of the Google Phone open source platform called Android for cell phones. Here’s a description for the open handset alliance site

Android™ will deliver a complete set of software for mobile devices: an operating system, middleware and key mobile applications.

Now I’ve done my share of time in the cell phone game development trenches and have a better understanding of why cell phone game development is a nightmare than I’d like to. Android, however, looks like it could solve many of the problems that plague cellphone game development today. Let me elaborate a bit on the problems with cell phone game development and how Android may fix these.

The Problems with Cell Phone Game Development

First, let me give you a rundown with what I see as the greatest problems with cell phone game development.

1) Nonstandard and Buggy Platforms

The first problem is the standardization of the Java Virtual Machine (JVM) [I did most of my work on the Java side of cell phone game development but the Brew (C++) side faces many of the same issues]. Java was brought to cell phones with the intent of making this platform that is completely device independent where one could write their source code once and easily run it on devices from many different manufacturers without any changes. This ideal is fantastic and sounds great, the problem lies in the execution. Today the JVMs for the phones are still buggy in many serious places and each cell phone manufacturer makes their own JVM. Thus for every cell phone there are completely different bugs one must work around and the JVMs do not follow the Java standard very well at all thus source code must be modified conditionally for each set of devices one wants to distribute their game on.

2) Vast Differences in the Handsets the Their Resources

The second problem is the huge amount of differences in the various handsets available. I remember about a year ago I had what was advertised as a top of the line phone (a Sony Ericson s710a) it had a high resolution screen and lots of other nice gamer and multimedia features. When I got further into cell phone game development and actually looked up the amount of memory the phone had the results were laughable. It’s memory available was comparable to phones that were low end trash phones or those given out free years ago. This blew my mind. However, this isn’t a very uncommon problem in cell phones their hardware specs will generally make no sense. People owning that phone expect to be able to buy nice fancy new cell phone games, the phone however can barely count to 3 on it’s own without running out of memory.

More reasons this becomes a problem is the distribution method that cell phone companies use to get people on their networks. They offer really low end crappy phones (hardware wise) that are put into spiffy looking cases and marketed as nice devices. They give these phones out free or even pay you to take them with long 2 year contracts. 2 years is a huge amount of time when it comes to technology, especially technology that is innovating as fast as the cell phone market. What gadgets do you have that are over 2 years old? Furthermore since 80% of the people on any given providers network use these 2 year old low end pieces of junk if you want to make a nice new cell phone game you’re pretty much stuck catering to the low end otherwise you have so little a market and the cell phone providers don’t care enough to let you release your game. Which leads into the third problem.

3) The Pains of Distributing Games with the Major Cell Phone Networks

The third problem as I see it is distribution on the major networks. It can be very hard to get your game released onto the cell phone game market where you can actually sell the game. The phone networks like to control the content fairly tightly and if they don’t think you’re game is a good fit then they’ll shoot you down and won’t let you release the game. This makes cell phone game development especially troublesome for indies because this happens to even the major publishers for example I worked on a game for a major game publisher which was done over a year ago and I think still has not seen the light of day of the market. The networks also will require you make your game for the lower end handsets which means any fancy features or in depth gameplay you want to include will probably be cut unless you want to make multiple versions of the same game.

How the Google Phone Android System Solves These Problems

As you can see there are lots of problems with cell phone game development these days but it can still be a very lucrative market to explore and will only continue to rise in the future as more powerful phones reach the hands of the masses. The Google phone has potential to solve a lot of the problems of the industry lets see how.

1) Android Provides a Standard Platform that Many Manufacturers Plan to Adopt

Because Google intends to provide the operating system to many different manufacturers this could potentially mean that we finally get one single implementation of the JVM and no longer have to go through the nightmare of coding for all sorts of different bugs and “features” of each vendors JVM implementation. If Google does this right and the Android platform is widely adopted and deployed it could really be a new age of cell phone game and application development. The old hope of “right once, run anywhere” could become much closer to reality that before.

2) Android Could Create a Useful Set of Minimum Requirements

It’s not yet known precisely if the Android system will actually do this or not but it would be generally helpful if Google came up with some sort of minimum specifications for phones using the Android platform. For example it might state that there are tier 1 phones which have a certain speed of processor and amount of memory as a minumum (each phone may have more but would need this amount to be certified tier 1) then it could come up with other higher tiers of requirements giving the developers much clearer targets to develop for. This is more of an industry wide problem but something like this created by Google and adopted by the manufacturers who use Android could really go a long way. This would make many development nightmares disapear as development would become much more like developing for consoles (a few machines with a specified hardware specification) instead of the hundreds of devices each with different specs developers must consider these days.

3) Android Provides an Open Platform for Deployment

Google is promoting Android as a very open platform for anyone to develop on. They’re even releasing a SDK to the public in just a couple weeks from now. If done right this will provide a much more streamlined route to market for many developers and could make indie cell phone game projects much more of a reality. Developers could bypass the draconian system of having to run every application and game idea through the minds at the major phone networks (who generally aren’t game minded folks) which could breath new life into the possibilities for innovation within the cell phone game space. We could quickly go from lots of old arcade game ports and tired platformers to games that are really interesting and push the envelope of design. Also it could lead to much cheaper development on a whole which will also help indie developers who want to get into the cell phone game market. If done right this could make the cell phone much closer to the PC as a game platform and really open up the opportunities for cell phone game developers on a whole.

I’m Very Excited About Where The Cell Phone Game Industry Could Be Headed

Before this news about Android I had written off cell phone gaming as a tired and torturous industry to work in. Now, however, I have new hope that that industry can be reinvigorated and the best days could be ahead. If Google can do for cell phone development what it has done for the internet in the last few years we are certainly destined to see some great innovations come right to our pockets. Great and innovative games being just one benefit.

This morning I attended a talk given by Glen Van Datta, Director of Online Technology (SCE-RT) at Sony Computer Entertainment America (SCEA). His presentation was to the GamePipe Lab at USC and was about MMOG Technology Strategies that they use at SCEA.

Keep in mind that SCEA and SOE (Sony Online Entertainment) are pretty much separate companies and SOE does most of the MMORPGs (Everquest et al) but SCEA does do a lot of multiplayer online games for the Playstation systems including some upcoming larger MMOGs like the PlayStation Home virtual world. Thus the talk was not just about strategies for large persistent worlds but also for smaller world instances you may find in a typical multiplayer game.

Lots of this stuff is fairly technical and focuses on networking technologies and such but it’s certainly useful to know for anyone developing multiplayer games. This post will mainly be an overview of what was talked about and thus an overview of technologies for MMO and multiplayer games. I intend to go into much more detail about certain things aspects in later posts when I start wading more into this stuff myself.

Also one thing that was particularly interesting that was mentioned was that through experience the industry has learned that if one person cheats in an MMO game or is even perceived to have cheated to gain an unfair advantage, the game is likely to lose 100 players because of this one person.

MMOG Technology Strategies

The first thing to consider is the architecture of your typical modern MMOG. There is a game server that holds the world state that all of the clients will connect to, there is also a lobby server that the clients will connect to as well that does the matchmaking for the game. Sometimes there is also a community server which basically is a web based aspect to the game (such as the Armory for World of Warcraft) that players may connect to over the internet while they may not playing the game.

Game Server

Reliable UDP

Typically the developer will want to implement a reliable UDP system as TCP systems will generally not work well for real time games because of the bandwidth used to ensure packets arrive and in the correct order. Reliable UDP allows the developer to decide which packets are important enough to depend on and which can be safely ignored if they don’t arrive.

A reliable UDP system may provide a categorization of packets that allows the server to label packets as in-order, reliable or latency critical among other useful categorizations.

The typical connection in the US runs at 256KB/second up and 750KB/second down.

Filtering

The filtering system on the game server allows for networked LOD (level of detail) thus the server may choose not to send all information to a player. For example if a player can’t see another player they may not need to know all the information about that other player, or if a player can only see another player far in the distance then ever piece of information about what that player is doing may not be relevant. The filtering system allows the game server to make these determinations and save bandwidth by not sending irrelevant information to a player.

The filtering system can run at the sight level, the sound level or even the game object level where a particular game object may know that it doesn’t need very specific information about some other type of object. For example a Commander doesn’t need to know the specific details of each of his infantry units positions and movement trajectories but each of those infantry soldiers would since they are marching with one another.

Global Time Base

The global time base is a process by which all clients and the server are synchronized to some global time with some small acceptable variance. This allows for deterministic client calculations of when things should occur or end (for example you may receive the Blessing of Salvation buff in World of Warcraft, your client knows this lasts for 5 minutes and thus can show you when it ends without having to be notified by the server.) This can also be used to make position predictions based on trajectory of items in a game like bullets or other things as long as no other forces are acting on them that you don’t know about.

The global time base can also help when leveraging deterministic randomness, which is when a seed value is distributed to each client for their random number generator to make sure they are all synchronized. This ensures that for example the 3rd random number generated on each client that had the same seed value will be identical.

The global time base as well as many of these other technology strategies is also not needed for turn based or lock step gameplay.

Arbitration

Arbitration simply means that the server has to keep track of the state of the world and handle any inconsistencies in the clients views. For example one client may thing a door is open while another thinks a door is closed, without some way to figure this out this can be very important (depending on the game of course.) The server is responsible for pulling together all the information it can to solve these disputes, whether that means polling the clients to vote or keeping full track of the world state.

This stuff has to be considered up front and is a very important aspect for the game designers to consider. The developers must figure out what types of things are important and what are not, usually whether a player is dead or not is an important decision but whether or not some grass has been burned away or some leaves are blowing in the wind may not be as important to the users experience. Thus it is important to make these considerations during design so that the arbitration systems can be implemented as needed.

Distributed Game Servers

Game servers can become very loaded depending on how heavily trafficked your game has become. Some things can be either run together on the game server or offloaded onto external distributed servers to do the processing work needed. These things include NPC state information, AI behaviors, Scribe functions (logging, persistence information, debugging information), collision calculations and also dynamic effects such as polygon mesh changing (fully dynamic terrain meshes.) These are not the only things that can be offloaded, basically anything which you can write a subsystem for can usually be offloaded onto distributed systems that will scale better than trying to improve the capacity a single server box.

Lobby Servers

The lobby servers are the servers that perform matchmaking functions for the players as well as allow them to chat with one another and other functions. Lobby servers are typically less latency critical and are much more tolerant of lag and network traffic spikes, they also tend to use much less bandwidth. Usually TCP communication will be sufficient for lobby servers because of the somewhat non realtime nature of their functions. Lobby servers are also generally used to house friend and ignore lists as well as anti cheat mechanisms such as piracy detection and modded console detection.

Communication Servers

The web interface to the game is classified as the communication server. These can be wide and varied and can include many different things. For instance World of Warcraft provides the Armory as a window into their game world from from the web. From the Armory you can view players equipment, character builds and also information about their guild and lots of other stuff. Forums for games also tend to fall into this category. These services provide a way for the players to be involved with the game while away from the game, or to arrange groups and things for when they are playing. Web interfaces to MMO games are becoming a standard thing and tend to provide a good value and sense of attachment to a game for your players. Most any new MMO game would feel incomplete without some web infrastructure.

Testing and Production

Lastly testing is an important aspect to any game development but is especially important in MMO games where many players will be using your systems simultaneously and where exploited bugs are much more detrimental to a larger group of players.

Also production times are another important thing to consider. When you plan to develop a large MMO game you have to realize that production can take a long time, 3 years or more. Because of this it is very important to spend some time at the beginning really laying out your plans and considering what is the riskiest part of your technology plan. This time period will typically be 6 months or so and during this time you should do things such as develop gameplay prototypes, work on the riskier aspects of the game to determine whether your feasibility estimates are realistic or not and ultimately decide if you should invest much more time and money into the project after this initial stage.

MMOG Development

Ultimately MMOG development is a very complicated process. A multitude of technologies go into the creation of any multiplayer game and it is important for the involved in the development to have a good understanding of all of these technologies going into the project.

Well that’s about it, I think it was a good talk overall about the technologies going into MMOG games and I hope I’ve been able to pass some of the wisdom on to you. Let us know about any games you’re involved in making we’d love to hear about them.

Matt Sakey has written a great article for the IGDA on the use of Lean methodologies for game development.

“Waste” in development could be rework, unused assets, reversed design decisions, creative clashes, you name it. Largely it would be the product of poor planning, which, I’m sorry to say, does lead right back to the “business needs more proven process models” argument.

Lean methodologies are used in production industries to reduce waste in the process and ultimately make better products for cheaper. I think this is a vitally important concept for indie game developers operating on small budgets and this article is certainly worth a read.