Sunday, December 5, 2010

jsplatformer Part 1 - Figuring out Links

Experimenting with using Google Sites as a way to host both code files and final runnable version of the tutorials.

This is an addendum to my earlier post, jsplatformer Part 1 including links to individual code files and working examples of the final pieces.


Both versions use the same Image file

HTML5 Canvas

Here we have the html and javascript files that go together.



Your browser doesn't support the canvas element.

Next, figuring out the Flash posting....


Here we have the mxml file that is used to produce the swf and the actionscript file that it references for the actual 'game' logic.


Monday, November 29, 2010

A danger of hyped releases.

Taking a break from the tutorials for a different kind of post. Ok, in reality I am on the train and have discovered tutorials written for 'web' languages often are heavily dependent on having an internet connection and getting access to API documentation offline is kinda sucky.. so anyway! This is not going to be one my more coherent posts since, well, trains are not the most distraction free environments, but let us see what I come up with.

I have no idea how universally this applies, but I have noticed a recurring pattern in when I tend to stop playing games. Often games that have an update cycle will, from time to time, move from 'little' updates to something 'big'. This big set of changes will often be hyped and talked about for months with speculation about which features will make it in and how they will work.

Now, one of the problems with speculation.. what gets implemented will never live up to people's imaginations. Often the developers will have the same basic ideas but discover that they did not have the time to implement them or the balance could not be worked out or the feature would simply consume too many resources to execute.

This results in a highly anticipated expansion that, for many, is not as good as they hoped. Now, when it comes out, you usually have plenty of people happy with it anyway and many pointing out that people should not complain (which ends up just making the complainers more annoyed… trivializing feedback is rarely a good way to silence it).

So here is what happens with people like me at least. Usually by the time a major update is in the works current features are a little stale, so the hype serves as a reason to 'stick around'…. I tend to get wrapped up in the discussions about features, sometimes even logging on to test servers to get a taste of how things might start panning out. I can see which features are making it in (sometimes, depends on the game and openness of testing) but hold out hope that 'awesome' features make it in. Here is one of the initial problems… I tend to care about features many other gamers do not… I am not a big 'graphics, combat, and scores' person, which is what most developers cater to… so features I am looking forward to usually get cut in order to get those in.

So I walk away with that initial disappointment.. 'skipped over again'. This was a big problem with EVE, every cycle they promises interesting industrial content but it always got pushed off for combat type stuff. When updates are frequent this is not a big issue, but when updates are big and infrequent the next cycle feels very far off, usually interrupted by at least a cycle of working out bugs related to the new features. Thus, disappointment combined with a feeling of hope being a long way off, results in stopping playing.

Minecraft is my current example. Big halloween update that took months (when updates used to be weakly) that ended up containing nothing of real interest.. mostly things related to fighting (which is odd since it kinda sucks as a FPS) and making things more 'hard core' for the score-oriented people. I played it maybe a week after that and just.. sorta… stopped.

Again, I am not sure how universal the lesson is, but the one I take away from this is one should stick to small, frequent updates rather then highly publicized major updates, at least from the perspective of keeping existing players. I think one of the reasons companies tend to like these big updates is they tend to have marquee value.. something big and different to coax in new players or get older ones to return. For minecraft this makes a lot of sense since it is a 'pay once' game.. for EVE I am less sure since the game depends on keeping players over a long haul. So I guess ultimately it will come down to what the purpose of the update….. gaining new players or keeping an existing community happy.

I think.. I think with games like EVE we are seeing a bit of a problem with business models. Even being a fairly seasoned company at this point, subscription games are still a fairly new area that 'conventional wisdom' is still being sorted out. Even as their internal teams figure things out they will have a constant influx of marketers and executives that adjust even slower, and as more jobs are on the line innovation and risk taking tends to decrease.

I think this is something that a lot of these 'Facebook' and similar games have started to figure out since they have less bureaucratic overhead and thus can adapt quicker. As I watch those games (and older ones like pardus), updates tend to be small and fairly frequent, which I think is one of the reasons they tend to have pretty good retention relative to their complexity. The biggest problem they have is people burning through all the content quickly and leaving, which could be fixed by having a larger team and keeping updates coming.

And now I am pretty much out of battery and track, so this seems like a good place to wrap up.

*humms happily* ask not for whom the mp3, may toll it tolls for thee…. your doomed the moment I cease to sing….

Friday, November 26, 2010

jsplatformer Part 1

Ok! First part of this experiment. For this piece I will use Drawing an Image to the Canvas with JavaScript. Let me also take a moment to mention how much I detest those sites that use javascript to alter the text you try to copy out of their page. Creepy.

Anyway. This tutorial goes over the basic task of displaying an image to the page and then bouncing it around. I decided to start with this since it was (a) simple and (b) I already know some flex and believe I can accomplish the same task.

Before I start going over my solution, I want to talk a little about tools. I have never felt it was fair to ask people first learning a new technology to also learn a new IDE at the same time, which Flex tutorials are rather heavy on. So for this I stuck to very basic tools.

For Canvas, I used vim and Safari. For Flex I used vim, Safari, mxmlc (the Flex command line compiler) and Adobe's stand alone player.

Secondly, I want to make it clear, I am a newbie to both these technologies. I am sure there are better ways to do things, built in tools, add ons that make things easier, etc..... I do not know any of these things yet. I am still figuring out what things are needed to accomplish a task and which things are simply things some tutorial author did that LOOK necessary but are not.

Now, on to the actual stuff I wrote. Obviously for Canvas I followed the tutorial pretty closely so the files are only a little different from what was on the page. Sadly I am still working out how to post code to blogger, so the formatting is less then stellar.

For canvas I had three files (including the image)


<html lang="en">
        <title>JavaScript Platformer 1</title>
        <script type="text/javascript" src="jsplatformer1.js"></script>
        <canvas id="canvas" width="640" height="480">
            <p>Your browser does not support the canvas element.</p>


// target frames per second
const FPS = 30;
var x = 0;
var y = 0;
var xDirection = 1;
var yDirection = 1;
var image = null;
var canvas = null;
var context2D = null;

window.onload = init;

function init()
    image = new Image();
    image.src = "file:/./jsplatformer1-smiley.jpg";
    canvas = document.getElementById('canvas');
    context2D = canvas.getContext('2d');
    setInterval(draw, 1000 / FPS);

function draw()
    context2D.clearRect(0, 0, canvas.width, canvas.height);
    context2D.drawImage(image, x, y);
    x += 1 * xDirection;
    y += 1 * yDirection;

    if (x >= 450)
        x = 450;
        xDirection = -1;
    else if (x <= 0)
        x = 0;
        xDirection = 1;

    if (y >= 250)
        y = 250;
        yDirection = -1;
    else if (y <= 0)
        y = 0;
        yDirection = 1;

For Flex, there were a few more files but not many:


<html lang="en">
        <title>JavaScript Platformer 1</title>
            <param name="movie" value="Simple1.swf">
            <embed src="Simple1.swf" width="640" height="480">


<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx=""
  styleName = "plain"

            public function initApp():void
            public function enterFrame(event:Event):void

  <SimpleCanvas id="canvas" width="100%" height="100%" themeColor="#ffffff" />

package source {
    import mx.core.UIComponent
    import flash.display.Bitmap

    public class SimpleCanvas extends UIComponent
[Embed(source = '../assets/jsplatformer1-smiley.jpg')]
public static const SmileImage:Class

        private var SmileBmp:Bitmap = null;

        private var xD:int = 1
        private var yD:int = 1

        public function init():void
            SmileBmp = new SmileImage()
            addChild( SmileBmp )

        public function onTick():void
            if (SmileBmp == null)

            SmileBmp.x += 1*xD;
            SmileBmp.y += 1*yD;
            if (SmileBmp.x + SmileBmp.width >= width)
                xD = -1
            }else if (SmileBmp.x <= 0)
                xD = 1

            if (SmileBmp.y + SmileBmp.height >= height)
                yD = -1
            }else if (SmileBmp.y <= 0)
                yD = 1


Ok, enough of the raw code, onto some comments. The core logic is the same, which is not surprising. The differences were more in feel.


Canvas won when it came to simplicity. 2 code files to Flex's 3, and information was not as duplicated (for instance, the size of the Flex frame had to be put in multiple locations). Canvas was much more 'start up and go', one had to worry much less about how they were going to do things or how to structure their project.

This also gets into my chief complaint about Flex so far. Flex has many ways to do the same things,.. it feels like a language that has been extended over the years in order to accommodate programmers rather then programmers adjusting to it. This kind of flexibility is good for development, but it makes life for the newbie difficult. I went through 3 different flex tutorials, each one did things sufficiently differently that lessons from one could not easily be applied in others, and figuring out why something did not work was difficult because only a few comments might discuss the way that particular author was doing things.

For instance, loading and image. Canvas seemed to have a way to do it, Image() and then set the source.

Flex, first you have 3 different ways to embed an image, plus there were people talking about a 'loader' API you could also use. Images could be (and in different examples, were) loaded as Bitmap, Sprite, FlexSprite, FlexBitmap, UIComponent, BitmapData, or MovieClip. In various examples they might be added directly to the canvas or immediately embedded in a temp container which in turn was added, with no real explanation of why people were doing this.

There is also the issue of mxml vs as. mxml is for layout and UI, as is for logic.. so you have two different syntaxes for the same functionality, with the intent being the mxml syntax makes layout easier while actionscript makes logic easier, but at first glace figuring out why you have to completely different syntaxes for the same language can be a bit confusing.


Flex was better about explicitness. With Canvas, I guess the whole js file was either converted to a class or processed as some kind of procedural program where it looks for key symbols and links to them. This 'by convention' approach makes things simple, but feels a bit like a big gray room where you are not sure what else might be in there. Flex had things contained within a nice clean class, everything outside language keywords had to be imported (so the split between API and language was much clearer), and entry functions were explicitly defined in the mxml file. You got a much better sense for how things fit into a larger framework.

I admit, I like Flex's explicitness.


This one is a good example of 'what do you want to use it for?'. Flex produces self contained applications, either for embedding in a web page or running as a desktop application. All interaction with a larger system probably needs to be done via APIs to things like XMLRPC or sockets. However, Flex has no knowledge of the page in which it exists.

Canvas is integrated into the web page, so you can use the main html page for layout and can pass information (like buttons and forms) from the page to the Canvas. I am guessing this also means the Cavans probably has access to other page information so you can adjust what is going on inside the Canvas according to the page, which might contain other technologies like Django linking to a database.

So Canvas feels like a dedicated web technology designed to work with other web technologies... Flex feels more like Java did... it can be run through websites, but is not really 'part' of them.

Asset Management

Canvas dynamically loads its assets, including pulling them from remote (and remotely managed) locations, and it does this very naturally. Since it is not 'compiled' till someone views the page it can delay as long as possible.

Flex needs to pre-embed images into it's self contained file, so it needs to know ahead of time what each image will be (and seems to convert each asset to a named class?). This brings up the concern of 'what if you do not know till compile time?'... do you need to name EVERY image or is there some way to grab an entire directory? I am guessing there is some kind of html API within Flex for grabbing content off the web and displaying it, but I doubt it is as natural.

So I have concerns about Flex, but these feel like 'newbie/easy' concerns that have solutions later on. Again, Canvas's integration with the rest of a site gives it some clear advantages if you need that kind of structure.

So, this was the very first attempt to compare them. Next up... jsplatformer Part 2!

Wednesday, November 24, 2010

Flex vs HTML5 Canvas

Looking back at this nearly abandoned blog, I can see that I have talked off and on about sitting down to learn Flex. In my defense, I actually have learned bits and pieces of it so it has not been all talk at least ^_^

The point of this post though... which is better to learn? When I ask people this, I tend to get two basic answers.. "Learn Flash" or "Learn Canvas". No one ever seems to recommend Flex, which oddly enough kinda endears it to me.

Flex/Flash seem to have the current mindshare... lots of people using them, lots of tools built around them, lots of help advice out there. On the other hand the are closed source, and Flex suffers from not just duplicate APIs, but finding Flex specific help (as opposed to Flash), esp outside a specific IDE, is hard. Flex also has AIR and a standard player on every machine.

Canvas is new, it is not really standardized (and each browser has its own implementation), a lot of stuff is still missing, help is infrequent, and the APIs are not very mature.

Now, I am not learning this for a job or any particular project.. and I have no time scale... so why not learn both?

For this experiment I have choosen two online tutorials, one for each language..

Matthew Casperson's FlexFighters and.. well... Matthew Casperson's jsplatformer. Hrm, only while typing this did I notice they were by the same person. That should make this more interesting.

Anyway, the idea will be to attempt both tutorials in both languages and get a feel for how the two languages solve the same problems. I guess we will see how far I get.

Monday, August 16, 2010

Freeman's Mind

A recurring pattern of video game/movie crossovers, I believe we can generally agree, is that they tend to be of rather poor quality.

Movie writers struggle how to shove video game plots into their traditional 'movies must have X, Y and Z to be successful' templates..

Video game producers end taking overused game mechanics, dropping in movie related assets, and making a game with no real innovation and unusually limited content.

End result, cross overs almost always fail... to a significant degree this is probably because movie people are making movies and game developers are making games.. neither ever seem to know enough about the other medium to make the transition.

On an amateur level though this might be changing.... via machinima....

Take Freeman's Mind by Accursed Farms. Video game based (Half-Life 1)... in fact, the whole series could almost be a person simply playing the game.. no additional mechanics, no additional graphics. It is currently on episode 29 (with each episode being between 5 and 10 minutes long), so all put together it is movie length.... and importantly, it is entertaining. With nothing more then the video game there is sufficient monologue and plot to be interesting. Granted, there is no love interest.. no comedic sidekick,.... none of the elements screenwriters seem to think a movie 'needs'.

Rooster Teeth's 'Red vs Blue' is another example. It has gone on for 7 seasons now and has a massive following. It is more complex then Freeman's mind, requiring an actual plotline separate from the video game, but it is still a video game based series that translated well and people actually enjoy.

I wonder what would happen if these machinima outfits actually had a real budget and professional voice actors (or even actors+sets+etc). Even a small budget....

Friday, May 7, 2010

Alcan Highway

It is not often I run into such a visible example of what I would like to see in a 4X game, but I think this documentry on The History Channel shows one:

"Modern Marvels - The Alcan Highway"

So what does this have to do with 4X design? Getting away from the specific engineering of the project, it has a number of interesting logistical and strategic elements that I would love to see come out naturally in a game. Namely:

At the time, Japan was a major force in the Pacific Rim, but only in terms of naval force. There were worries that they would attack the US mainland with the major worry being Alaska. Alaska was easily accessible, poorly defended, and geographically isolated from the mainland. The only way it could be reenforced would be via moving troops in ships, at which point the troop carriers would have to content with the Japanese Navy, which could probably stall them long enough to dig in. So here we have element one: strategic footholds that getting reinforcements to is difficult (most 4X games treat travel as very quick).

So the US&Canada decided to build a highway that ran from the lower US, past several Canadian airfields, to Alaska. This was a major project, not something you can do over and over. So the scale is another issue, 4X games, it only takes so long before you can tile the entire map with roads or rails, so the cost of infrastructure tends to be high early on and dirt cheap later on. I am not sure how to offset that, but something needs to scale the costs so that major strategic builds do not end up tiling the whole map.

Lastly, in order to actually run such a massive project, it was cheaper to build an entire associated oil infrastructure, including wells, refining, and distribution, right off the road construction. This would be another interesting element, logistics where getting resources to massive projects other then 'use 50 shields' is a real consideration.

So ideas ideas ^_^

I think this would also be a good example of how a 4X game could be moved into an MMO type domain. Logistics has the potential to be quite complex, a game unto it'self. In EVE, even though it was painful and boring, people still would play pure logistics roles for years at a time. Imagine what it would be like if someone built a game where logistics was interesting rather then tedious?

Wednesday, May 5, 2010


For some reason when I tried to title this post, blogger tried to autofill 'Every Kiss....'. I have no idea where that came from.

I have decided (yeah, for the nth time) I am done with EVE. I have been playing less and less, and EVE is a bad game to set down and come back to. The OSX client has been getting progressively worse (and I wager in the next expansion it will get even slower), the exploration interface is borked, etc etc.

What did in me in though was a random wardec from an alliance with half a dozen corps in it. Wiped out my staging platform which contained some ore and my freighter. It is a recoverable loss, but recovery just does not sound fun this time. It took ages to get to the point where mining Bar was less tedious because of the platform, and going back to a more tedious task just to get back to being less tedious, is not appealing right now.

I think one of the other blog entries from that contest pointed out, in terms of play, EVE really sucks. The whole package can be fun because the final rewards give you a thrill, but pretty much all the gameplay elements, when taken in isolation, are not fun to actually do.

I always felt that the wardec mechanic was a bad one, and a bad mechanic just kicked over my sandcastle. Even worse, it worked because I do not get a chance to log in every day, which is frustrating. So I have deleted my apps and canceled my accounts.

Not a rage quit, no carebare tears, just sorta, done.

And with that, I am probably done with multiplayer games for the foreseeable future.

Friday, April 30, 2010

OSX vs Windows as a Game

A quick follow up (or at least related) thought from the gender post the other day....

One of the things that comes up when talking about gender inclusiveness in game design in the concept of 'dominating the technology'. Fighting and beating the technology the game is embedded in as opposed to playing and beating the game itself. This usually takes the form of figuring out hidden mechanics and such.

Then today I saw yet another 'Mac vs PC' argument, this time on a game site. I have noticed that tech males and male gamers seem especially venomous towards OSX over the years and wondered why this is.

So I started thinking about the OS as a type of game. The OS provides the rules and mechanics, individual apps and capabilities provide the actual gameplay. Think of the OS as the engine and games as the assets. If one goes by this analogy, OSX could be seen as 'too easy' by males. There are not many secrets to figure out, nothing complicated to fight, no real way to distinguish the hardcore from the softcore... you take your app, drag it across, and run. One does not fight with OSX, one uses it as a tool. There is nothing to figure out.

Windows on the other hand, is dripping with secret knowledge and requires constant exploration and fighting. Windows is 'challenging', there is always something to show off so people know that you have 'found tricks' in the OS that make the gameplay easier, similar to, say, the bunny-hop in HL. Playing games in windows is similar to figuring out what the limits of the physics engine or the meta behavior of the AIs in a FPS,.. sure you can just play the game, but to be 'good' you need to understand the underlying engine and play against it too.

I wonder if there is an actual pattern here, or if it is pure conjecture?

Monday, April 26, 2010

Entertainment Merchants Association (EMA) v. Schwarzenegger

The topic has been so heavily discussed that there it not much I can really add myself.....

Apparently the Supreme Court has agreed to hear the case, which has both great potential for good, and disaster.

On the one hand, if they rule in favor of the EMA, this may FINALLY put to bed the myriad of laws politicians have been passing over the last decade attempting to regulate game content and sales. These laws have universally been shot down by the courts, but have never made it to the highest court in the land, and having an actual SC decision might dampen their enthusiasm for illegal laws.

On the other hand, if they rule in favor of Schwarzenegger (which given John Paul Stevens's retirement and some of the Bush appointees, is a possibility), it would relegate an entire class of communication, anything 'interactive', to a second class status that does not enjoy 1st amendment protections. It would be the equivalent of, in the early part of the century, ruling that movies were not protected because moving pictures are not expressive art (which was argued at the time).

So in many ways, this is the big one.

Sunday, April 25, 2010

Gender Inclusiveness in CCP's EVE Online

I have been looking for a reason to start posting again, and The EVE Blog Banter Special Edition: The Ladies of New Eden seemed like a good start, so I hammered out a quick response:


Gender inclusive game design. It is something the game industry has been struggling with from day one. Game design in general suffers from an institutional problem. A certain type of male was generally playing games in the 80s and 90s; they grew up, and they founded companies, and they made more games like what they wanted to play. They made those games for people like themselves, and considered a game a success based off that demographic. Males, 15-35 years of age. The industry perceives these as the only people who really buy games, thus they make games for these people, so only they buy the games.

Every once in a while the industry tries to reach out to female gamers. Generally when someone tries to pitch such a project they are told that ‘girls do not buy games’, and if they do get funding (usually a small amount) and marketing (usually a small amount), the project ends up going poorly. Males are put in charge of critical parts and they try to build games based off what ‘they’ think girls want. The result tends to be dull games that no one wants to play, which is then pointed to as further proof that girls do not play games, and they go back to developing games for 15-35 year old males. Rinse lather repeat.

Now, the industry is up against some real problems. For starters, games tend to be a big piece of how young males socialize. They provide a common point of connection that they can discuss and use to position themselves within their peer group. This happens because, well, lots of males play the games, so you have a chicken and egg problem. Males connect to males because other males play the games. Females do not build these connections because not enough of their peers are playing. You need a critical mass to really start selling games.

Critical mass aside, you have another problem. Little boys are encouraged to play with technology. Parents buy them mechanical toys, buy them computers, praise them for solving technical problems. On the other hand, girls are given social toys, they get the hand-me-down computers, and most importantly, they are taught to interact with technology as a tool to be used for developing other skills. They are not encouraged or taught to ‘play’ or challenge the technology, just use it. This has effects down the road when they get into games. We will touch more on this later.

The last institutional problem is pure design assumption. There was a study years back where they asked children (male and female) to make a game. They separated the people into 3 different groupings. One grouping was told to design games for little boys. One grouping was told to design games for little girls. The third grouping was told to design games for ‘children.’ What surprised the researchers was that the games designed for little boys and ‘children’ in general were structured the same, while the games designed for little girls were structured differently. What did this show? It showed that there is a male-normative effect going on; unless a group specifically is told to think in terms of girls, they defaulted to thinking in terms of boy behavior. The lesson to pull from is that thinking ‘we are going to design games for people, not males!’ is not good enough. When developers think this, they end up designing games for males.

The main thing to pull from this background is that making a game for female players is not a trivial matter. It is not just a game problem, or a company problem, or even an industry wide problem. Anyone trying to address this is up against such fundamental problems as institutionalized sexism and the very way that girls are raised by society. It can be done, but do not expect huge returns for a few minor tweaks and a couple pink bows.

A secondary thing to keep in mind is that people vary a great deal. In making a game that is more inclusive to females, you also open it up to more males. Done right this does not have to make a game any less fun, or even less safe. Women enjoy the same killing and bloodlust as the guys, it just needs to be structured a little differently.


In a way, it actually comes as a bit of a surprise that EVE turned out with the gender skew it did. In many ways, EVE is the spiritual successor to Ultima Online. UO was credited with being one of the more inclusive games of its time. The RPGs that it originated had significant female followings due to their story, character development, and rather importantly, multiple solutions for how to solve problems. UO reached an unheard of female population of 15% during a time when girls in general probably made up, at most, 1% of the gamer population. EVE should have built off this success and was positioned to do something significant. CCP did do something significant with EVE, no argument there, but when it comes to building a game that girls can get into, they did not just fall on their face; they fell on their sword and disemboweled themselves. 5%? Today? That is beyond abysmal, considering current statistics are between 40 and 60%.

So what can be done? Even the simple answers might not be easy.


The biggest way to improve things is not a feature, it is not a bell or a whistle, it is not a change in the game at all. It is a change in the company. Look at any game that has a good balance of male and female players and you will find one consistent feature in the company: women in positions of power. Women in the development teams, women in the Q&A teams, women in management. Not token women around so you can say you have women in your company, not small quiet things that sit there and do their job, and not ‘one of they guys’ women. Women with real influence on the path a game’s development takes, women who are listened to, women who make decisions. Also of importance, they have a significant number of women so they get a variety of perspectives (since, as should be obvious, not all females are the same), enough to break up the group-think and have them be less easily bowled over by the ‘prevailing wisdom.’

Men who sit around and try to design games based off what they think women want rarely develop games that actually match what women want to play. While human resource issues are considered rather boring and unsexy to developers, if you want games that attract significant numbers of female players, long term, this is the only way to get there.

EVE specific issues.

Despite the overwhelming importance of changes in corporate culture, there are some technological changes specific to EVE that potentially could make the game more inclusive. Even with a shift in corporate culture, eventually it has to come down to changes in actual mechanics.

Fighting the Technology

Earlier I spoke a little about how little boys are taught to compete with (and ideally, dominate) technology, while girls are taught to use it for other goals. One of the ways this comes out in game design is that developers build games so that the mechanics have to be explored. They expect players to get a kick out of finding hidden features, explore the mechanics, find new ways to do things. This is often touted as ‘developing skill,’ but often it is a matter of figuring out how the game actually works as part of play.

Female players tend to resonate with this poorly. Rather then being something wonderful to explore, it is pure frustration with no real reward other then getting to help counter advantages other players might have. Fighting games are a classic example of this effect going on. Fighting games are built with lots of hidden moves that you find out about via either (a) randomly bashing the controller or (b) leaving the game to look them up on external sites. This has resulted in many frustrated female players that quickly discover that even if they are good at the game, ‘secret knowledge’ that male players tend to pick up render them uncompetitive and the process of getting this information is just not fun, so they stop playing.

This is actually one of the easier things to address; the solution is pretty well documented actually. Documentation. Extensive in-game help and new player experience. There is a general assumption that wikis and external sites fill this role, but they do not do it well from this perspective. Female players, especially early on, are more likely to get frustrated and quit a game then go to external forums/wikis to find information on how to play the game. Often it is suggested that people should just ask in newbie chat, or go get help, but history has shown that female players are simply less willing to do this (again, this gets back to childhood training). This also gets into our next issue, in-game behavior.


There is not much CCP can do about this one, but it is a huge issue. In the late 90s there was a research study done involving student access to educational material at the University of Phoenix. They looked at educational forums that were linked to classes and how males and females interacted on them. In theory both groups had equal access to the resources and equal reason to be there, and it was assumed that gender access would even out pretty quickly. It did not. In fact the result were pretty sharp.

Females tended to structure their posts around empathy. They tried to build connections with the other students. Male posters, on the other hand, used harsher language filled with put downs and similar attempts to denigrate other posters. At first the female students attempted to interject into the conversations but were quickly ‘slapped down’ and pushed out of the thread. The few females who did keep participating got an even worse fate... they tended to be ostracized by both the males and the females, resulting in being cliqued out of the resources. Both players and developers tend to underestimate just how much of effect this ‘locker-room banter’ has on female players. It is not even a case of needing a thicker skin; anyone who has watched female argument can see how vicious they can get. It is a case of how enjoyable the behavior is. Males (or at least, many males) get a kick out of this type of behavior; females on the other hand find it unpleasant and intimidating. Abuse is easy to put up when you enjoy it, but it is game breaking when you do not. EVE, unfortunately, strongly encourages abusive behavior. This brings us to….

Kill Stats

It is assumed boys love stats. An important stat in EVE is the ability to compete indirectly via ranking oneself against other players in raw numbers like number of kills. This is a common element in many on-line games, and it tends to have a single recurring result; it drives away female players. On the one hand it is a ‘reward’ they tend to not care that much about. On the other hand, it tends to encourage male players to kill for no in-game reason. Not only is it immersion breaking, but it encourages in-game harassment for no in-game benefit. It is the currency of kicking over other people’s castles. It gives positive feedback for actions that serve only to make the game less fun for other people.

This gets into the entire issue of ‘why do we kill?’ in EVE. In null there is conflict over territory, but only about 20% of the EVE population is playing that game. In the rest of EVE, there is little in-game reason to PvP. PvP is a sink; it is costly with little reward. That small reward ensures that the people doing the PvP are going to do it for out of game rewards. Changing this can make the game more inclusive right there.

How? Increase the cost of failure for the aggressor is one piece. EVE’s PvP is structured around rewarding the aggressor by making it as cheap as possible for people seeking to kill to do so, while putting the costs on the victim. The net result is resources leaving the game, but it is disproportionally on the victim rather then the attacker. This sends a pretty clear message for what the player ‘should’ be doing, and taking wealth away from others just for the sake of hurting them tends not to be a female thing.The other piece is to increase the reward for the attacker to compensate for the higher cost. A classic way to do this is allow the capturing of cargo or the salvage (retrieval of a complete, repairable ship) of ships. This would encourage people to pirate for in-game reasons and spread the possible costs around so that a successful attacker gets a good in-game prize while a failing attacker gets a significant in-game penalty. This mechanism would also increase (from effectively zero) the possible payoff to the victim since they could salvage the attacker’s ship.

Conflict Resolution

This might sound like a PvE issue, but it applies to PvP too. Outside null, there really is only one way to resolve a conflict: blow the person up. It is often said that you can pay someone off (so extortion), but realistically since there is no contract mechanism is in place, paying someone off will rarely result in an actual resolution. More often then not it will simply result in loss of ISK and a loss of your ship/goods/POS.

Females (and many males) tend to prefer more then one way to resolve a situation. Games with large female player bases tend to have ways to resolve a situation that do not involve killing. They might involve sneaking past a monster, or distracting the guard with a decoy, or bribing an official to give you the widget that was going to go on the transport.

On a PvE side, this could be accomplished via more varied missions...both missions with multiple solutions and missions where you are doing something non-combative like scanning people down or having to go remote-rep a ship that is damaged or under attack, or even having to run a blockade.

On the PvP side this could be accomplished via a system where negotiation with players or corps has a legal (and enforced) effect in the game. The game is too wide, and players policing players does not work when anyone can roll a new alt (or for that matter, have multiple alts waiting in the wings) at the drop of a hat. Giving CONCORD the ability to enforce some contracts between player corps might give player corps some new ways to resolve conflicts.

Null Lite

Null sec has a lot of potential for female players since it is player story driven. It is the area of the game with the most social connection, most diplomacy, most room for really interacting with other players. Player corps, the social unit of EVE, simply have too little meaning outside null sec. For many players all they are good for is setting up a research POS, but come with the risk of wardec harassment. Finding ways for player corps to be useful and relevant through all levels of the player experience would increase the social aspects of the early game and give it context. At the moment, isolation tends to bring more rewards then working together.

More types of anchor-able structures in high sec might help here. Small corps setting up small bits of infrastructure that help the group beyond research would encourage these small groups of players working together. This also opens up the ability for players to have some visual impact on the universe. Null sec alliances have the ability to shape space, but outside that all players have are POSes with disconnected modules. While EVE is hardly a decorating game, treating POSes as a decorating project could keep some players interested.

There is also the issue of fleets. Fleets are one of the early ways for players to work together and build connections. Fleets have a problem though, they are all or nothing and require a significant amount of trust. Fleeting with strangers (and thus, helping strangers) is dangerous since as soon as you ‘fleet’ you are a target with no CONCORD protection, which discourages players from working together. The minor change of ‘fleeting does not remove CONCORD protection’ could have significant impact on strangers socializing in the game.

Penalties - Learning Implants

One of the differences in how how males and females tend to play games is how they react to penalties for failure. Games that resonate with males usually include ‘death’ or other ‘return to start’ mechanisms while games that resonate well with females on the other hand tend to adopt a ‘prevent from advancement’ mechanism instead. Failure either pushes you back or stops you from moving forward. A somewhat abstract difference but it can have a significant impact on the game’s enjoyment for females.

This is a hard thing to address in EVE since the game is built around the idea of ‘real loss’. One of the reasons WoW does so well is the player risks so little when they fight, while in EVE they lose so much. Insurance is usually brought in to mitigate the effect of loss in EVE, but it is debatable how much this really does for anyone other than the attacker. For attackers this works very well; if they know they are going to attack they can plan well ahead, switch to a cheap implant clone, fly cheap ships, carry no cargo.

For the defender insurance is not worth so much. Defenders will generally be flying with normal implants (which control how quickly you advance in the game) and often have cargo. Insurance does not cover implants, and does not cover cargo. Cargo, being shipped, is meant to be lost, that makes sense. With learning implants the defender generally has the choice of always flying with cheap implants or risk losing expensive ones in a random encounter they have no control over. Loss with lack of control effects everyone, but it tends to especially hit home with female players.

The solution to this is to make learning implants like SP, that simply stay with the character. Players can still take risks with implants that impact the actual conflict, but the penalty for being attacked is decreased.

Social elements that will not help.

There are a lot of ideas floating around based off what males think women want. The most popular meme right now is that women want social games, and if you want women to play you need ‘social’ elements to the game. Since EVE is already a very social oriented game and that does not seem to be ‘working’ people are focusing on some rather surface ideas about how women socialize and hoping that those ideas will help. The two common examples are Incarna and EVEGate.

In Incarna, people are assuming that girls need a ‘human like’ thing to relate to, so if you have human avatars in the game, women will feel more comfortable and thus flock to EVE. The problem here is that, as described, Incarna does not really do much. It is a place to hang out when you are station camped, a glorified net-meeting. Unless there is some compelling game-like content in there that gives women something to DO in this new environment, most will not be impressed with it and seek out games that either do the pure-social aspect better (like Second Life) or have compelling avatar based content (like WoW).

EVEGate on the other hand tries to be more ‘facebook’ like. People have noticed that facebook games are popular, especially among women, so the theory goes that if EVE has a facebook like component to EVE that women will flock to it. This is what we generally call ‘cargo-cult development’; trying to duplicate the success on something based off surface similarities with no real depth or understanding about why it was actually successful.

Other resources

In the end, there are better resources then blog posts for this topic. There have been numerous studies done on how to make inclusive games, and several good resources.

For starters, there is Sheri Graner Ray’s excellent book Gender Inclusive Game Design which goes over a wide range of differences between male and female players. The book also has extensive references to various studies and papers that go over specific issues and the science behind them.

There is also the IGDA Women In Game’s working group which has regular workshops at GDC where such issues are discussed.


Gender inclusive game design is not a trivial matter. Anyone attempting it is up against some pretty deeply engrained social issues that are beyond their power to control or change. Even things within the developer’s power are wider in scope then simply adding a new feature or changing a little window dressing. Appealing to a wider audience requires changes in corporate culture, hiring practices, and shifting thought about what elements are ‘required’ to make a good game.

However, making a game gender inclusive, and making a game that still appeals to the traditional male base are not mutually exclusive. By putting thought into what makes a game unattractive to female players, one also gains other male players and potentially even improves the experience for the traditional base. This results in more profit for the company, and happier players all around. Change can be scary, but this is a type of change that can be win-win.

CCP’s EVE is innovative and built off doing unusual things for a less then mainstream audience. Some view this as something that results in EVE being locked in to niche design constraints that make it impossible for it to be inclusive without destroying what makes it unique. Personally, I think that puts EVE in a unique position where it could shift to be more inclusive, not lose the things that made it unique in the first place, and potentially make it special in even more ways.

There is, however, a fundamental problem with asking the EVE player base how to attract women. As was described in the first section, one of the ways the industry got into this mess in the first place was players becoming developers and then designing the games that they would play or what they THINK other people will play. The people that CCP should be talking to are people who are not even playing EVE in the first place.

Lastly, part of the rules is that you need to include links to other posts. I am not sure why this is, but I will respect it and link to the last few on the list above me, since they are probably not linked much already:

Getting More Eves in Eve Online (recommended read)
Be a man! Fight back!
In Search of the Sisters of Eve
52 days of Eve Online
Bringing the Sisters to EVE
Your agent has ended your mission for not attainin...

Saturday, April 24, 2010

Testing Again

I wonder if some of the new facebook features caused old ones to stop working?

This is one of the problems with companies that try to keep on the 'cutting edge', their stuff stops working, online help and documentation becomes wrong, etc. I think this is why a lot of the web2.0 technology is a bad idea, or at least immature. These people can not develop APIs or protocols that last 6-12 months, yet they seek to unseat systems that have been functioning robustly for decades?

I think before you try to throw out the old, you should at least demonstrate that you can build something equally stable and consistent.


Assuming I followed the directions correctly, this should post to facebook.