Monday, March 26, 2007
What a Cool Idea
I know it's a bit old, but I only just heard about Red 5's awesome recruiting idea.
Wow. The idea says so much about what the company must be like. They must be fighting off cool game devs with a stick now.
(I want to be a cool game dev)
Wow. The idea says so much about what the company must be like. They must be fighting off cool game devs with a stick now.
(I want to be a cool game dev)
Tuesday, March 20, 2007
Steel & Glass: Structure
I tend to enjoy sandbox games - the ones where there's this big world and while there might be a main storyline or two, you can happily ignore it all and just do your own thing. I like them because you can jump in and have some fun even if you can only play for a short time, and because they usually have pretty good replay value even after you've "beaten" the game.
There are a few things you need for a sandbox game. Specifically, you need the sand and the box. The "box" is the setting - it's the world that gives all the gains of sand some context. It's all well and good to earn 5 million neoyen, but unless you know that's just enough to buy yourself a dual-blade mono katana, it's all a bit meaningless (kind of like how if you don't know what a dual-blade mono katana is, you don't really know why someone would pay 5 million neoyen for it).
Once you've got your box, you then need your sand - the various bits of the world that the player can gather together to do interesting things with. The easiest type of sand to deal with is money. All you really need to do is give the player a few different ways to get money, and some different areas to spend it. The standard way to get money is through jobs (or missions or quests or whatever you want to call them). There needs to be a balance between easy to do, low reward missions and difficult or time consuming but very profitable missions, and a split between independent (as in it doesn't matter what else you've done in the game) and storyline-related missions. Equipment serves both as something for the player to spend their money on, and a way of making the player's life easier. Better weapons, more efficient tools, stronger defenses, etc.
The logical progression for the player to follow in the game is that doing missions gets them more money, having more money gets them better equipment, and better equipment allows harder missions to be attempted. Of course, that gets pretty boring pretty fast, and has a definate end point ("okay, I've got the best item/finished the hardest mission in the game now"). So you need to mix things up a bit - you need special items that the player can only get by doing a specific mission, you need missions the player can only attempt if they have a certain amount of money, and you need items you can directly use to get more money.
But even that's not enough. Each point of the money->equipment->jobs triangle should also lead to itself. Some items the player can only get through other items, there should be a way of using money to directly make more money, and some missions should only be attempted after the player has succeeded at (or failed) other missions. There should also be elements outside the core triangle - for example groups the player can befriend, or equipment the player can design.
So, once you've got all those elements in place, you've got the beginnings of a potentially fun game.
There are a few things you need for a sandbox game. Specifically, you need the sand and the box. The "box" is the setting - it's the world that gives all the gains of sand some context. It's all well and good to earn 5 million neoyen, but unless you know that's just enough to buy yourself a dual-blade mono katana, it's all a bit meaningless (kind of like how if you don't know what a dual-blade mono katana is, you don't really know why someone would pay 5 million neoyen for it).
Once you've got your box, you then need your sand - the various bits of the world that the player can gather together to do interesting things with. The easiest type of sand to deal with is money. All you really need to do is give the player a few different ways to get money, and some different areas to spend it. The standard way to get money is through jobs (or missions or quests or whatever you want to call them). There needs to be a balance between easy to do, low reward missions and difficult or time consuming but very profitable missions, and a split between independent (as in it doesn't matter what else you've done in the game) and storyline-related missions. Equipment serves both as something for the player to spend their money on, and a way of making the player's life easier. Better weapons, more efficient tools, stronger defenses, etc.
The logical progression for the player to follow in the game is that doing missions gets them more money, having more money gets them better equipment, and better equipment allows harder missions to be attempted. Of course, that gets pretty boring pretty fast, and has a definate end point ("okay, I've got the best item/finished the hardest mission in the game now"). So you need to mix things up a bit - you need special items that the player can only get by doing a specific mission, you need missions the player can only attempt if they have a certain amount of money, and you need items you can directly use to get more money.
But even that's not enough. Each point of the money->equipment->jobs triangle should also lead to itself. Some items the player can only get through other items, there should be a way of using money to directly make more money, and some missions should only be attempted after the player has succeeded at (or failed) other missions. There should also be elements outside the core triangle - for example groups the player can befriend, or equipment the player can design.
So, once you've got all those elements in place, you've got the beginnings of a potentially fun game.
Labels: projects
Wednesday, March 14, 2007
Steel & Glass: Part 1
Probably the thing that best prepared me for programming (or at least the concepts behind writing code) was the game Escape Velocity. The basic idea for the game was far from unique - you're the captain of a spaceship, and you fly from planet to planet trading cargo, doing missions, buying better equipment and ships and making money. But it had this very nifty idea of plugins. Much like mods for a first-person shooter, you could use them to alter or extend pretty much everything the game ("make the laser cannon more powerful", "add a new storyline", "turn the game into Star Wars", etc).
On the old Macs (as in pre-OSX) there used to be this program called "ResEdit". You could use it to directly edit the resource fork data of a file. If you pointed it at Escape Velocity, you could see all the data for the different things in the game - all the ships, all the planets, all the missions, everything. An Escape Velocity plugin contained data to overwrite or extend the data in the resource fork of the main game. So to make a plugin, all you'd have to do is fire up ResEdit, copy from the main game the resources you wanted to edit, make your changes, save it in the plugins directory and fire up the game. Presto, now the Confederate Cruisers doesn't have any weapons and flies backwards.
I had lots of fun making my own (and playing other people's) plugins. Years later, when I started to learn about Object Orientated programing, it all clicked together. I suddenly got a big part of how O-O worked because of what I'd learnt hacking Escape Velocity, and I suddenly got how a bunch of Escape Velocity stuff worked under the hood.
Which is a bit odd really, because I suspect that Escape Velocity isn't especially object orientated...
I've always been really intrigued by the architecture - I love the idea of the data being so close to the surface, but still so tied to the structure of the object. Over the past few months, I've been itching to make something, and I'm thinking it might be fun to try using a similar model.
On the old Macs (as in pre-OSX) there used to be this program called "ResEdit". You could use it to directly edit the resource fork data of a file. If you pointed it at Escape Velocity, you could see all the data for the different things in the game - all the ships, all the planets, all the missions, everything. An Escape Velocity plugin contained data to overwrite or extend the data in the resource fork of the main game. So to make a plugin, all you'd have to do is fire up ResEdit, copy from the main game the resources you wanted to edit, make your changes, save it in the plugins directory and fire up the game. Presto, now the Confederate Cruisers doesn't have any weapons and flies backwards.
I had lots of fun making my own (and playing other people's) plugins. Years later, when I started to learn about Object Orientated programing, it all clicked together. I suddenly got a big part of how O-O worked because of what I'd learnt hacking Escape Velocity, and I suddenly got how a bunch of Escape Velocity stuff worked under the hood.
Which is a bit odd really, because I suspect that Escape Velocity isn't especially object orientated...
I've always been really intrigued by the architecture - I love the idea of the data being so close to the surface, but still so tied to the structure of the object. Over the past few months, I've been itching to make something, and I'm thinking it might be fun to try using a similar model.
Labels: projects
Caring Too Much?
"He shouldn't take it so personally!"
Someone said that to me yesterday, and it's the grain of sand that this pearl of a blog post has formed around.
A colleague recently decided it's time to move on. Part of his decision was motivated by the fact that a project he'd been heavily involved with has been put on hold indefinitely. He felt that there was a lot more work still to do, and that the project had a massive amount of potential. The Powers That Be disagreed.
The opening comment was made by another colleague when this reason was explained to him. And I can't get past how much of a flawed an idea it is to me.
The way I see it, you've got two types of jobs. The first type are the jobs where you arrive, do your work, then go home. The kind of job where you don't really bother thinking about it outside of work hours. The second type of job is the one where you arrive at work, argue with your boss a bit because he's missed something important, spend your lunch break working on a way to improve internal processes, stay at work until 9pm because the way you decided to do this project will take a bit longer but will produce a better end product and spend a chunk of your Saturday researching a new idea.
You know, they type of job where you actually care.
Personally, I'd much rather have the second type of job. And as an employer, I'd much rather hire the second type of people. Obviously, just because you're passionate, it doesn't mean you're right. Part of the job of management is knowing when to say "no" - no matter how big a tantrum your underling throws. But surely that fight would be preferable to the idea that really, this person hasn't thought (or doesn't care) beyond what's he's immediately doing.
Or am I wrong? Is it better to just do your 8 hours and leave work behind at the end of the day?
Someone said that to me yesterday, and it's the grain of sand that this pearl of a blog post has formed around.
A colleague recently decided it's time to move on. Part of his decision was motivated by the fact that a project he'd been heavily involved with has been put on hold indefinitely. He felt that there was a lot more work still to do, and that the project had a massive amount of potential. The Powers That Be disagreed.
The opening comment was made by another colleague when this reason was explained to him. And I can't get past how much of a flawed an idea it is to me.
The way I see it, you've got two types of jobs. The first type are the jobs where you arrive, do your work, then go home. The kind of job where you don't really bother thinking about it outside of work hours. The second type of job is the one where you arrive at work, argue with your boss a bit because he's missed something important, spend your lunch break working on a way to improve internal processes, stay at work until 9pm because the way you decided to do this project will take a bit longer but will produce a better end product and spend a chunk of your Saturday researching a new idea.
You know, they type of job where you actually care.
Personally, I'd much rather have the second type of job. And as an employer, I'd much rather hire the second type of people. Obviously, just because you're passionate, it doesn't mean you're right. Part of the job of management is knowing when to say "no" - no matter how big a tantrum your underling throws. But surely that fight would be preferable to the idea that really, this person hasn't thought (or doesn't care) beyond what's he's immediately doing.
Or am I wrong? Is it better to just do your 8 hours and leave work behind at the end of the day?
Sunday, March 04, 2007
Lost
www.lost.eu/2831a
Go on, you know you want to!
Go on, you know you want to!