Archive for category Game Design
I made a Flash Game (Robofortress)
Posted by Joshua Smyth (Admin) in flash, Game Design on October 16, 2009
Inspired by a couple of local Flash developers. I thought I’d take a look at making a game with the web’s most ubiquitous game framework.
Play the game here
Use WASD keys or Arrow Keys to move and use the mouse to shoot the bad guys.
This game is a port of my entry for the 48 hour game jam. Originally it was written with the XNA framework in C# but I decided it would be a prime candidate to test the flash waters. Although this time around I added ‘Easy’ and ‘Normal’ difficulties.
I’ve got a couple more flash game ideas floating around in my notebook (aka scraps of paper strewn about my bedroom.) So hopefully we’ll see another release before too long.
Let me know what you think. Good and bad – I’ll write a future post on my first experiences with flash and Robofortress itself at a later date.
Design Ideas for Attack of the Meeplings II
Posted by Joshua Smyth (Admin) in Game Design, Meeplings on September 25, 2009
I’ve been playing around with Flash lately and my first flash game RoboFortress (A revision of a game I made earlier this year for the Global Game Jam) should be finished in a couple of weeks. Its a pretty simple maze based shooter but should be entertaining enough for people who like fast action games with retro graphics and sound effects.
After that I’m going to have a go at making Attack of the Meeplings II in flash. Here are my thoughts based on the feedback for the first game.
- The game is too hard (Casual gamers like the retro look and feel, but the game is too hard. I’ve noticed lots of inexperienced video game players don’t even use the up and down arrow keys at first) – I’m going to have to put a bit more thought into easy/medium/hard difficulty levels
- The game is too easy (Experienced players, esp those used to playing more hardcore shooters find the game too easy. They are only challenged ~30+ minutes in after the game speeds up fast enough for them. Yes, I know this is directly opposite to the first point but it shows how games sometimes have two (or more) very different audiences.
- The game doesn’t have any powerups People have commented on the simplicity of the game. Which is of course intentional. But it feels pretty good to be big and powerful so I’ll look at adding a couple powerups.
- The music is awesome The sequal will feature more awesome music!
Also I think I will cut it down to 2 stages – Most people don’t even get through one loop of the game and I like the infinite looping concept. For the hardcore players the speed increase per loop needs to be greater each time.
If you have any other feedback on Attack of the Meeplings or ideas for Attack of the Meeplings II please leave a comment.
Your unique selling point is now more important than ever – [part one]
Posted by Joshua Smyth (Admin) in Business of Software, Game Design, Indie Game Development, marketing on July 17, 2009
Reports are coming in that the games industry is not quite so recession resistant as previously thought. What we have been witnessing over the last 1-2 years is a nose dive in prices for downloadable games, the near disapearance of PC games from retail stores. And the re-release of lots of back catalog titles.
All of this is a good thing™
Games have been historically expensive, backwards compatability has always been a pain, and only being able to choose from the ‘top 40′ equivilent at your local store was hurting the medium as an art form.
All of this means the game has changed. Dramatically.
As someone with disposable income, there are alot of games out there for me to choose from. I’ve mentioned before that I’ve got way too many unplayed games on my shelf with not enough time to play them all.
And now with the low prices seen across the board for digital distribution from the likes of Steam, Big Fish Games, The iPhone App Store, Gamers Gate, Good Old Games, PSN and XBLA – For less than a take-away meal I can buy more than an entire weekends worth of entertainment.
The flip side to this is of course – How sustainable is this model for the developers of games?
The music industry got a shake-up in the early 2000′s and I have a feeling it’s going to be the games industries turn to have to re-think business and the way it turns ideas into products. And unfortunately, unlike the games industry, we can’t earn money by playing live shows. T-Shirts maybe, but live shows? Probably not.
I think we are going to see more small studios, making smaller-budget (and by small-budget, I don’t imply low-quality at all) niche titles. (ie. like the old days.)
And with niche titles, it’s all about the unique selling point.
If I have $10-$20 to spend, and a spare weekend, I need a reason to buy your game and not someone elses.
The irony here is that it’s not price that will be my deciding factor, it will be all the irrational fuzzy aspects of my personality which will lead to me making a purchasing decision – It might be interesting story, art style, maybe promote some message I agree with, invoke my sense of nostalga or capture my interest in some other way.
In any case, your game has to be in some way special.
Developers, indies in particular, have to think what their game stands for – what does it, I dare say – mean?
Embarassing Code
Posted by Joshua Smyth (Admin) in Game Design, Game Programming, Meeplings, UnderKeep on March 5, 2009
Like any art – As we game programmers grow in our skills and abilities more often that not we can look at our past projects and be embarrassed at some of our ideas and implementations.
Most people don’t get to look at your code, unless you’ve released open source software of course. Infact, I’ve heard a good reason to make your project open source is just because other people can look at it, for that reason alone, you are compelled to make it good.
I’ve had a few “what the hell was I thinking?” moments which each of my finished games, and that’s just the finished ones. Some of the unfinished projects that never saw the light of day had horrendous ideas – like that time I tried to implement my own scripting language and parser in VB 6 with a whole lot of select statements and if-then-else trees that ended up wider than the Mississippi.
I would still like to program my own scriping language (or Domain Specific Language or DSL as all the cool kids are calling them these days.) But now at least I know it’s a difficult problem that involves a lot of Hardcore Computer Science™
So here are a few things in my finished projects that I implemented bady
- Star Cars – My first serious attempt at becoming an independant game developer was a 3D arcade title that I no longer advertise on this site due to vista incompatabilities and requiring a hardware transform and lighting supported video card. It had this had a really long, really complex collision detection algorithm that got to the point where I didn’t actually know how it worked. It got that way by me trying to solve the problem, attempting a solution, where-in the implementation would cover 80% of the cases, then I would just hack it until it worked. There was one edge case that I could never figure out – It turned out that it was easier to change the level mesh, than try to debug that horrible code.
- Caverns of Underkeep – Most of the design decisions for Caverns of Underkeep turned out very well, infact most of the game engine structure is being ported to my current project, but there is one part of the code thats just downright bad. And that’s how I implemented the modal dialogs – I did this weird thing where I would put the gamestate into a “modal mode” and all events would be routed from the active game state into the modal dialog class and then I would poll an object until its value was non-null which would return the gamestate back into its normal state, passing the newly created object back to the client gamestate – Don’t worry if you didn’t follow that, it’s kinda hard to explain without pictures and flow charts and things, which kind of illustrates my point. Now this method worked, but it was stupidly complex, my new method of rendering modal dialogs is to do a hit detection against GUI elements before they can process events, and simply masking the background so only the dialogs elements are exposed to the hit detection.
- Attack of the Meeplings – Originally Attack of the Meeplings was going to have powerups and I had this cool idea for a spread gun, unfortunately I couldn’t track down a bug in my code that was not allowing for symmetric vectors for the bullet paths, ie if v is a vector then v mirrored would not have an angle symmetric with v which gave it this lopsided look – I played with this for a day before just giving up and cutting the idea of powerups. I think it had something to do with the location of the centre pixel of the bullet, the spawn location of the bullet relative to the player, and the fact that I was rendering at discrete values (ie pixels) on the screen. Really this problem shouldn’t have been all that hard to solve, but I decided at the time it just wasn’t worth it to fix.
Stop With the Grind Already
Posted by Joshua Smyth (Admin) in Game Design on January 3, 2009
Over the holiday period I’ve managed to sink many many hours into the cult Japanese RPG Persona 3 which has simultaneously delighted me because it’s so different and also reminded me of why I don’t really play jRPGs.
I was really enjoying myself until about 30 hours in where I encountered one of the monthly boss battles and found myself way, way underskilled to win the battle. One walkthrough that I looked at recommended that I have a character at level 45 – A full 8 levels higher than I was, which means about 4 hours of just pure grinding, running around and getting into fights.
I usually play through games quite quickly and don’t bother to grind my character, because I like to see new things and progress the story – and besides, I’ve got a whole lot of other games sitting on my shelf unopened. But now I have to grind if I want to get on with the game.
Theres just a little too much grinding going on for an otherwise excellent game. Many have reported that it takes around 80 hours to finish. Which is a pretty large time investment – Heck, I think I wrote Attack of the Meeplings in round 80 hours.
I think for the RPG I’m developing I’m going to target around 20 hours of gameplay, which is about how long Eschalon Book 1 lasted for me, and I thoroughly enjoyed that. I’d rather have a shorter experience, but one that isn’t feel a bit drawn out.
But if you do have a spare 80 hours, Persona 3 is a really excellent game.
I would like to pick up Persona 4 which was recently released, but I might have to wait until retirement before I playing it.
A look at the Attack of the Meeplings Highscores
Posted by Joshua Smyth (Admin) in Game Design, Indie Game Development, Meeplings on May 18, 2008
Here’s a histogram of the 4,842 scores in the Attack of the Meeplings database. At first glance the data looks realitively normal – However, it’s far from it. The horizontal axis is not linear, but exponential (2^n) the data is heavily right skewed which tells us that there are some people who are just so much better at the game than most.
This graph shows us how difficult the game is and we can see where peoples limits begin to emerge – For example, there is quite a bit of drop off in the 4000-8000 area.
The median score is 949 and there are only 295 scores that are greater than 16,000.
What does this say about developing a shooter if you’re an indie game developer? – Implement difficulty levels! The people who are in the top 100 are those who really like these types of games and are really good at them. Unfortunately if you only target those people you drastically reduce your potential audience.
Your players are supposed to be having fun, remember that. Give a challenge to those who want it, but relax on people who aren’t quite as good.
Random Name Generator Algorithm
Posted by Joshua Smyth (Admin) in Game Design, Game Programming, Programming, UnderKeep on January 24, 2008
I spent the morning creating a random name generator which will be added to the ‘create character’ section of Caverns of Underkeep.
I’ll explain how it works in a minute. But for now, here is an example list of names:
- Yivha
- Ilhalo
- Xagloh
- Pojlo
- Xifei
- Coxfo
- Cedtiz
- Digja
- Emrapo
- Aygoh
- Omgez
So not bad, sorta could be real-made-up fantasy character names maybe. This is how the algorithm works:
First of all, I did a little bit of research reading about syllables on wikipedia
I decided to create two different name types – Those that start with a vowel, and those that don’t. For the names that start with a vowel I use the form VCC-VCV
Where C = consonant and V = Vowel
For names that start with a consonant I use the form CVC-CVC
In each case I randomly determine if the name length is 5 or 6 characters long. If the length is 5 characters, then I just leave off the last letter in the string.
Thats it!
Obviously it’s very simple and I don’t do any weightings against uncommon letters like x or z or anything like that. But it gets the job done 
If anyone is interested the java source code is avalible here
More on classes
Posted by Joshua Smyth (Admin) in Game Design, UnderKeep on December 14, 2007
In a previous post I explained how Caverns of Underkeep will not have any classes.
Well, I lied.
I just added a character creation screen to the current build and I implemented some character classes.
However, I still claim that Caverns of Underkeep is not an RPG, so the classes represent game options rather than roleplaying options.
So far I have added six vocations:
- Adventurer - Normal, the default. Pretty boring.
- Beserker - Cannot wear any body armour or equip any shields. In return there is a 5% chance that they do double damage in Hand to Hand combat. They can still wear helmets – They’re not that stupid.
- Frail Mage – Starts with +4 MP and -4 HP
- Merchant - Starts with 250 GP but loses -2 Dexterity due to being a book reading economics nerd.
- Ogre - Big and strong. Starts with +3 Strength and +3 Endurance. Unfortunately Ogres are banned from all the shops in town.
- In Debt Big Time – You start with -1000 GP. If you can pay it off you get a score bonus.
That’s it so far, I’ll add more as I think up some. Basically I want something that gives a strength but also gives a weakness. Or perhaps provides some alternative playing styles. Post ideas if you have ‘em.
Caverns of Underkeep – Still not a roleplaying game since 2007
Random Dungeons
Posted by Joshua Smyth (Admin) in Game Design, Game Programming, UnderKeep on December 10, 2007
I’ve been working on algorithms for randomly generating dungeons.
My project Caverns of Underkeep is a Roguelike, and one of the features of all roguelikes is that they have randomly generated dungeons. There are two different flavors of dungeon generation and I’ll explain how they work in this article – Surprisingly the simplest algorithms can often produce the best results.
Here is a screenshot from a typical Cave map
The way this type of dungeon is generated is as follows:
- Start with a completely unwalkable surface, then draw some randomly sized circles in random places – These circles are going to be water areas.
- Perform a couple of random walks from the centre of the map, if we fall off the side of the map stop walking.
- Locate tiles that are dead ends. (Any tile that has only one walkable tile as a neighbour) At these dead ends place a circular style room. Use a basic turbulence* algorithm to alter the shape of the room.
- Locate a few other tiles that are part of a corridor – And not part of a room (To do this just work out how many unwalkable tiles are in the area immediately surrounding the tile you selected – If the number is greater than 2, then the tile must be part of a room and not part of a corridor) and randomly place some more circular rooms at these locations.
*A basic turbulence algorithm for drawing a shape is if say – You are going to draw a rectangle, then draw it as normal but determine randomly if you are going to draw N more rectangles with slight x and y offsets to give a more interesting shape to your rooms. See the image below for an example.
The second type of map is a Citadel – A typical screenshot is bellow.
This algorithm is pretty much the exact opposite of the one above.
- Instead of starting with some random walks, I divide the map into 10×10 sections. Doing this gives it that more deliberate man made look to it.
- Determine if I want to place a room here – If I do, note it’s location in a big list of rooms.
- Draw a random rectangular room (with turbulence)
- Once all the rooms have been drawn, consult my list of rooms. For each room draw a corridor between that room and the nearest room. Once a corridor has been drawn from a room, remove it from the list of candidates for nearest neighbour (otherwise we could get stuck in an infinite loop)
Both algorithms are guaranteed to be completely connected – Which is a really important thing to have in a roguelike. There’s nothing worse than not being able to complete the game because of the random generator – Bad computer, no biscuit!
In Caverns of Underkeep I also take a hybrid approach to generate the sewer levels. Basically I combine the two algorithms to produce another style of dungeon – See if you can work this one out for yourself
Why Caverns of Underkeep won’t have classes.
Posted by Joshua Smyth (Admin) in Game Design, UnderKeep on December 4, 2007
Its not that I’m anti-class when it comes to my RPGs. Infact I enjoy replaying games as different characters provided the game has been designed well enough to be played in different ways – And that really is key.
If I were designing a normal cRPG I’d have specialist quests for different classes, but there’s a bit of a problem I have with this new tendency for modern RPGs to omit classes and have an entirely skill based system, and that is I always end up playing the same character – A fighter/magic user who can pick locks 
Personally I’d rather play a game that let me into the thieves guild if I actually were playing a rogue, rather than if I just managed to get past all the traps and pick the right locks. I think I’d be more inclined to play through an RPG a second time (or a third) if I knew there would be new quests, new locations and new content that wasn’t available to me the first time round. Also quite often at the begining of the game I’ll not be sure where I should spend my skill points, should I take hide-in-shadows, white magic or detect-traps? If I haven’t even played the game yet, how would I know? So I tend to fudge and become a jack of all trades type. Starting with a basic fighter/magic user type and adding pick locks.
I’ve got a feeling that if I were to pick a character class at the beginning, selecting something from the usual trinity of rogue, magic user or fighter. I’d reasonably assume that the game would be balanced for each type, and offer unique experiences for each. I really enjoyed the way Quest for Glory offered different quests and ways of solving puzzles for it’s three main character types.
But anyway, why won’t Caverns of Underkeep have classes? Because it’s a dungeon romp, theres no real roleplaying going on what-so-ever. Your job is to kill monsters, and to do this you’ll need to be able to fight, use magic and pick locks.
However, I’ll probably steal an idea from Cute Knight (which is a nifty little game) And let the player choose a star sign which their character was born under, this will give various different starting abilities and bonuses/weaknesses.