Game Design, Programming and running a one-man games business…

Social games, unsocial methods

Posted on November 2, 2009

There is a current huge growth in ‘social’ games and ‘free forever!’ online games. I’ve seen a lot of online discussion trying to persuade people to jump on both bandwagons. I’ve never really liked them, or their methods, and today I encountered this:

(from) http://www.techcrunch.com/2009/10/31/scamville-the-social-gaming-ecosystem-of-hell/

quote:

A typical scam: users are offered in game currency in exchange for filling out an IQ survey. Four simple questions are asked. The answers are irrelevant. When the user gets to the last question they are told their results will be text messaged to them. They are asked to enter in their mobile phone number, and are texted a pin code to enter on the quiz. Once they’ve done that, they’ve just subscribed to a $9.99/month subscription. Tatto Media is the company at the very end of the line on most mobile scams, and they flow it up through Offerpal, SuperRewards and others to the game developers.

This does not surprise me. I had a go at super-popular ‘free’ social facebook game ‘farmville’ yesterday, to see what the fuss was about, and got a bad vibe from it immediately. This game is ‘free’, but that’s not strictly true. The game is totally designed around selling you in-game advantages by buying game-cash with real cash. In other words, it’s a grindfest where you can pay to avoid the grind. The game is also VERY insistent that you constantly let it spam updates to your facebook status on how you are playing, and you can only really do well if you drag your other facebook friends into play the game as your ‘neighbours’.

This is both a great piece of game design, and a terrible piece of game design. It’s great in that it achieves it’s objectives, cunningly encouraging you to market the game yourself in order to get gameplay advantage, and trying to maximise the amount of money extracted from you.

But, Its a terrible piece of game design in that the objective of the game designer was marketing and money, not fun. That really sucks.  I actually ‘disapprove’ in haughty terms. Someone’s business model has to be pretty cynical for me to say that, as a lot of indie developers consider me to be too hard-headed and business like, and not as much of an ‘enthusiast’ as the typical indie dev. I think that’s reluctantly true to a point. I live in an expensive part of an expensive country, and can’t afford to take my eye of the bank balance. I’m the sole breadwinner, so it’s not like I’m enjoying a sabbatical or a subsidised hobby. I need to run Positech like a business, or else I’ll be flipping burgers.

But! my business model is defiantly old-school in one respect: I aim to design FUN games, that people enjoy enough to pay me money to buy copies. I don’t look upon the people who buy my games as people to be milked of cash, exploited, or ‘leveraged as marketing assets’. To me, the positech games buyers are like a big extended club or enthusiasts group. We all like the same sort of games, and I’m lucky enough to be in the middle actually making the things, and shepherding the feedback and the enthusiasm so that games get made that everyone enjoys.  There are other indie devs with a similar attitude, such as wolffire,2DBoy, taleworlds etc. I think that you don’t get rich this way, but you get to enjoy making fun games for a really positive community.

I wish the more cynical people who are just trying to squeeze facebook profiles to extract cash would go off and do pyramid selling and boiler-room-sharedealing scams instead :( Leave game-dev to people who really enjoy making fun stuff.

Update at last

Posted on October 30, 2009

It’s been a while since I blogged, because a lot has been going on. Firstly there was a lot of patching and changes and so-on involving Gratuitous Space Battles. Then I grew another year older (boo!) which involved going away for a day and playing with tanks. I ended up sitting in the gunners seat of a British Challenger II tank, which was surreal, awesome, and when the guide starts talking about its planned role in nuclear war, kinda scary.

Then… I went away another night to nottinghame game city, met up with various people from game dev that I’ve met over the years, and bizzarely took part in a panel-discussion thing with feargal sharky and phil oliver from blitz games. I’d link to a video of it, but I haven’t seen it on the web yet (pls post a link if you find one).

In between all this GSB got updated to version 1.20, which was buggy, and immediately afterwards today to 1.21, which I trust is less buggy.

That version is very very very close to what I hope is the ‘final’ release version of the game. I have a playable demo setup running already (although it needs work). Don’t panic, that doesn’t mean the game will not continue to get updates and improvements, and expansions blah blah, it absolutely definitely will.

Also, in about a weeks time, I move house and knowing the incompetence of UK companies, I’ll lose internet access for a few days. It’s a busy time!

A not so trivial change

Posted on October 26, 2009

When you think about adding a feature to an existing game, it often sounds much simpler than it will be. Here is an example from today.
After a lot of consideration, I decided to add new ‘carrier support’ modules to cruisers. These would act as mobile repair yards for fighters. If you gave fighetrs the ‘cautious’ order, when suitably damaged, they will seek out the closest cruiser with a carrier module, head there, dock, get repaired, and return to battle.

Now there is a lot of code associated with the AI for doing that, and the UI for displaying it etc, but that’s all the code you factor-in and expect to write, so that isn’t the problem. The extra work, comes from all the stuff you hadn’t considered.

I needed code to prevent docked ships shooting, being tractored, being affected by shock waves, or targeted by enemy ships. That’s all pretty reasonable. Then I needed code so that on docking, the fighters would choose the most sensible module for multi-bay carriers where one was damaged, or had a big queue of fighters, plus handle exploding carriers and damaged carrier modules.

But then I started looking at the visuals. The fighters were just flying on top of the cruisers, then vanishing whilst docked. Clearly this sucked, and it would look cooler if the fighters flew ‘under’ the cruisers and re-appeared there. This would look like they docked in hangers under the ship.

BUT! in GSB ALL the fighters fly over the top of cruisers. It’s a rendering optimisation, which nobody notices. So I had to code a newer system where fighters *could* fly under as well as over the cruisers. This just means putting them into two groups randomly, looks cool, and is still pretty fast. And this is where it gets interesting.

With this cunning new system, as a fighter approaches a cruiser I can just ‘force’ it to toggle to an ‘underneath’ group, and thus it will look cool. However, it may not already be an underneath one, and it *may* be on top of a cruiser at the point at which I realise I need to do that. So there is a danger it may suddenly ‘ping’ underneath a ship horribly as I’m watching.

I can set a flag that means the change is pending, and only do it when its offscreen, but that might not always be possible. At some point I need to either just risk it, or do a lot of intersection tests to ensure its ‘safe’ to jump underneath. Ideally I flag this as something to do in a frame where there is some CPU headroom (existing code in the game checks this, and does other similar tasks in those gaps)

And there is one final hiccup. Over time, as every fighter gets repaired, they will eventually all end up ‘underneath’ cruisers. Which will not look right. I need to tag fighters as ‘needing to toggle above’ when they are next offscreen, just like I did the other way around.

This is all the code people forget about, and is why game programmers suck so badly at putting together schedules :D

Future Possibilities in the world of Gratuitousness

Posted on October 25, 2009

Some ideas I’m thinking about:

1) Carriers. Basically ships would have a carrier module that would let them repair fighters. the fighters would get a new order to return to base after X damage, and after Y time docked underneath the parent cruiser, the fighter could launch totally repaired. Probably an expensive or heavy module. This needs new orders, module and of course lots of balancing.

2) Scenario-Limits. A mission can be defined where there are more complex restrictions on the fleet other than pilots and cost. A crew limit, or a limit on the number of missile modules or plasma turrets. Maybe a mission where there can only be one third of the budget spent on cruisers, etc…

3) Drones. A module launches not dumb missiles, but active drones that hunt down and shoot enemy fighters, or clamp onto enemy armor and drill through it slowly over time. They can be shot down by point defence weapons.

4) Increased area of effect rule. Missiles in-flight can be vaporised by the blast waves from exploding ships

5) Anti-Missile Missiles. Another form of anti-missile defence.

6) Shielded Missiles. (take multiple PD hits)

7) Gravity Bombs Ultra slow missiles which drift transparently through enemy shields.

8) Multi-source beam weapons (several beams converge on one point, allowing multiple hardpoints to join forces to fire a single more deadly beam).

9) Decoy transmitters. Allows a fighter to impersonate a cruiser or frigate for short periods to draw enemy fire.

I doubt any of this will make it into the games release. I suspect a lot of it will end up in the game eventually, either through expansion packs, modding or just extra free content. Thoughts?