With my game featured on flyers at GDC and soon to be shown (in a small way) at EGX Rezzed it occurs to me that perhaps I should at least acknowledge its existence, even if I’m not ready to push it in people’s faces just yet. So a quick blog post will have to suffice…
So this is Super Thrustforce: Orbital Meat Police, a game about aliens, cattle abduction and retribution via the twin barrels of your spaceship’s miniguns. That and cow puns. Lots and lots of cow puns.
I’m not ready to announce too many details on the game just yet, but I’m currently planning to release on PC, Linux and Mac at some point this year.
I will hopefully do a more formal announcement in the near future. I also intend to start blogging occasionally about development, so please follow me on Twitter where I’ll announce new posts.
A note on the music in the video. Originally I cheekily used the awesome Orange Goblin’s equally awesome track “Your world will hate this” for this video for the Rezzed game show (and before that I had Ace of Spades), but wanted something I could use freely to post on Youtube. More out of hope than expectation I started with Empire of the Claw, whose music I used in my game “A Vicious Circle”, and when I dropped “Trance of the 80’s Arcade” in I was taken aback by how well it fit (from a things-happening-at-serendipitous-moments point of view). Ideally I wanted something a bit more rock (hence the original Orange Goblin), but so many bits work here that I felt I’d be daft not to run with it.
This is the work-in-progress for a project simply called Torus. There’s actually not much game here, but I think it’s an interesting little project nonetheless. (When capturing video for this I noticed that I actually got around to calling this Torus Trap, but I never liked that much, so I doubt it would have stuck.) Note that there’s no build provided for this project, simply because in the state I left it, it isn’t actually worth playing.
Torus was one of the first projects I worked on when I started using XNA, and it many ways it shows. Perhaps the most notable thing about the game is how much of it is based on limitations and restrictions. I’ve mentioned before that I like a good restriction or two, and this is perhaps the clearest example I have.
First up – the entire premise of the game came about because I couldn’t do complex collision like meshes, or even non-axis aligned boxes. So the first limitation was that I’d only use circular or spherical collision (or anything I could extrapolate from these). Previously in C++ I’d worked on a project called Radius which was a little like Gyruss or Tempest with the player’s ship roaming the outise of a circle shooting inwards. So I decided to take that idea and then wrap it around another circle – and have the player roaming the inside of a torus. They’d be orbiting the circumference of a circle as before, but could also move this circle around a larger circle into and out of the screen. It’s hard to explain, so here’s a video of it in action.
The second limitation I had was that, at the time, I couldn’t find any example code for 3D particle effects in XNA. Basically I wouldn’t be able to make nice fiery transparent explosions. Without this I decided that I’d look at somehow cobbling together some kind of shattering using debris objects. I’m pretty sure with hindsight this would have looked awful, but I made the call and it led me to then decide that everything would be made of metal. That decision then informed pretty much all of the rest of the design.
As mentioned, the player was going to be moving around a circle – this then became a physical ring object. This ring then needed to move along the inside of a torus. I’m a big fan of machinery and intricate mechanisms, so I then decided to mount this ring on rollers that would transport it around the torus. An issue here was that the if the ring sat on top of the rollers it would either waste an awful lot of screen real estate, or the roillers would have to be small and unimposing. So instead I decided that the ring should pass through the rollers – this allowed them to be suitably chunky, made the engineering pleasingly elaborate, and also allowed the rollers to act like shields when the player was inside them. As an aside, the decision to use three rollers was an obvious one (three of anything is generally more interesting than four), but led to the knock on realisation later that this was getting fairly close to looking like Space Invaders wrapped around the inside of a doughnut.
With the ring and rollers requiring elaborate engineering, I then decided that the art style should head towards Steampunk, and this then provided the backstory for the game, and also the design for the HUD and front-end.
The backstory was going to be something along the lines of scientists trapping some kind of energy-based entity in a torus-shaped containment facility to extract energy from it – there would be farms built into the torus to do this. The trapped entity gets a bit miffed about this, and starts spawning enemies to attack the farms. The player then takes the role of a fighter defending the farms from the onslaught. The intention was that it would probably feel a bit like Defender, with enemies spawning around the torus and heading to the farms, with the player intercepting them before they did too much damage. Almost none of this was implemented, but I quite like the premise, and it would have allowed me to make even more over-engineered machinery, since the energy farms would need to retract into the wall of the torus to allow the ring to pass over them.
The HUD/front-end is perhaps my favourite bit of this project. With the game now being made of elaborate mechanisms it made sense that that should extend to the rest of the project, and so I made a nice mechanical heads-up-display, and front-end complete with iris door (this one needed work, but man, I do like an iris door). Scoring and lives weren’t implemented so the HUD currently spins through an automatic cycle to show itself off. Here’s a short video of the front end. I was planning on making this much more intricate, with many more moving parts
One thing to note about this is that I haven’t the first clue about using render targets in XNA, so that HUD is just hanging in space in front of the game elements so that it appears in the right place on camera. It’s a total fudge, but it worked so I ran with it. Here’s a final video with a couple of extra camera angles to show what’s actually going on.
Also of note from that video – the player isn’t actually moving along the torus – the torus and enemies are simply rotating around the axis of the torus. I’m pretty sure I first decided to do it this way because otherwise the lighting would change as the player moved, but it’s probably a good approach, because it simplifies the maths at the bit where the action is.
As you can see from the videos there’s very little in the way of gameplay here, and I think that’s largely down to the fact that it soon became clear it would probably be rubbish, quite frankly. I got the placeholder red sphere enemies in, and soon realised that actually aiming at them would be tricky due to having a 2D plane of influence in a 3D world (the elaborate grid suspended within the ring is to help aiming – if the enemy is embedded in the grid you can hit it, but that’s just a bodged remedy to a symptom, not a fix for the underlying problem). It also looks pretty poor, since at the time I had no knowledge of shaders, and was struggling to find example code that I could use. I think I only kept plugging away at this as long as I did because the engineering was fun, but shelving it was a smart move because making it look good was probably beyond my ability with XNA back then, and I suspect the underlying problems with the core game design would always have made this a tricky one to make fun. Most of the remaining design decisions would probably be taken to mitigate or counter the inherent weakness of not being able to aim very well (I’d already considered making the enemies into snakes (of spheres) – not because I wanted snakes, but because it would give the player a chance of actually hitting them reliably).
Having said that, I’m half tempted to drop the meshes for this into Unity and throw some nice metal shaders at them, just to see what they’d look like…
This is the Work-In-Progress for a game that ended up being called Vadespacers (5, 8). I’ve mentioned previously I’m rubbish at naming games, and this one got saddled with a name that’s a cryptic crossword clue. (Technically it could do with a definition in there to be a perfectly valid clue, but since it’s the name of the game I’d suggest that’s implied.) The game is so clearly my take on Space Invaders that I wanted to get that into the name somehow, but there are silly numbers of games called Space Invasion and Space Assault etc. so I wanted to pick something a bit different.
Below is the video – as you can see it’s so nearly a complete game that it’s daft I never finished this. As usual the current build of the game is available to download at the end of this post.
So on to the game then. I started making this at one point when Dogfight Thing was dragging on a bit, looking like it might never get finished. I fancied doing something where I already knew all the answers (yeah – right!) and I’d never in 30-something years of making games had a pop at Space Invaders. It wouldn’t just be Space Invaders though – I needed a hook, and the one I went for was to make it a bit more in-your-face. I didn’t want to change the game much, just give it a bit more attitude, make it snappier and a bit more feisty. I think it was getting there.
So before starting coding the main thing I wanted to change was the main weapon, and the first thing that came to mind was to replace the “one shot at a time” mechanism with the polar opposite – a minigun. I knew this could be balanced out (by giving the invaders hit points probably) so ran with this as a plan.
Another decision I took really early on was to give the player a single life to keep things lively. I wanted to make the game much trickier overall anyway, and snappier as mentioned above, and that felt like the player should only get one chance at success. As much as I love the traditional arcade “3 lives” approach, it’s kind of frustrating when you lose the first one cheaply and still have to play on. Better perhaps to make the one life all you have, and make any error equal game over.
Getting the invaders working was largely simple, but there were several things I’d not considered beforehand. That whole “doing something where I already knew all the answers” thing was misguided even with something seemingly as simple as Space Invaders, but most of the problems were easily solved.
The implementation of the minigun weapon defined how the game would feel, and it’s something I’m happy with (although it could do with a better special effect). I wanted to speed the game up a little, but not too radically, so that meant the invaders had to take a fair bit of a kicking before exploding. With each bullet impact I then played an impact sound and jittered the victim around a little – this led to a proper feeling of them being riddled with bullets. It started to feel like you were giving them a real seeing-to (this works especially well for the bonus UFO I think).
The main design decision I struggled with was actually the shields. It’s not Space Invaders without shields, but I didn’t know how best to go about doing erodable ones like the original had. So I came up with a couple of alternate plans – either give the player a toggle-able portable energy shield that would form around them, or make the shields permanent. I quite liked the portable energy shield idea for shaking up the gameplay a little, but it felt a bit too far from the template, and with a little thought it had issues. It would be OK for it to stop bullets, but it couldn’t stop invaders, because that would make the shield incredibly powerful (unless I rationed it). So I went with the permanent shield instead (without properly thinking it through admittedly). It did tie in with the player being kind of clunky (the aliens use energy weapons, the player is flinging lumps of metal skyward as fast as they can), so strapping a couple of blocks of concrete in the air above them fit quite well. I hadn’t considered the fact that it would also have to wipe out invaders at the time, but later came to believe the game still works if invaders that get below shield level are considered to have invaded and ended the game.
Next I decided to add the rocket launcher to the game – the player already has a minigun, why not a rocket launcher too? To temper the usefulness of this I first made it so that if the player uses it behind a shield it kills them. With just the one life this perhaps feels a tad harsh (albeit in-keeping with what I wanted for the game), so I’m on the fence about this decision. I also added a chance for dead invaders to drop out of the sky, rather than simply exploding when killed. This redressed the balance in the invaders favour a little since the falling corpse will kill the player if they get hit by it, and using the rocket launcher potentially creates several of them – adding a bit of risk to using the thing. I also think it adds to the feel of the invaders being given a thoroughly good kicking, so that’s a definite plus point.
One final thing I added which is in the release below was a fast mode which simply makes the game play at twice normal speed. It was a quick and dirty trick to pull, and needs some balancing, but I quite like the feel of it. It’s much more of a white knuckle ride, and perhaps a tad closer to how I’d like the main game to feel. One of my favourite type of arcade games are ones that feel like they want you off them. Robotron always felt like this – it took your 10 pence piece and then did its best to throw you off. It’s the game equivalent of a bucking bronco – part of the fun comes from seeing how long you can defy it and stay on.
There’s not much more to say about this one. Basically it got to the stage shown in the video, and it’s not too far from done. It doesn’t feel quite how I want it to yet – it’s not punchy or mean enough. It maybe needs a bit more targetted aggression. Currently enemies fire at random and whilst they do fire fast shots if you’re close it’s not enough. The random selection works fine in the original where they’ve got shields to erode, but here it might be better to add a bit more malice – picking the right invader to fire (if only occasionally) and using deflection to fire at where the player’s going to be when the bullet lands.
I was also never completely happy with how the invaders sped up as their numbers are reduced. I tried a few approaches at monkeying with the numbers, but nothing really felt right. Stupidly I didn’t Google it at the time – the way the original game does it is easily found, wonderfully elegant, and should be easy to implement in my game despite the fact that my invaders move smoothly rather than in steps.
IIRC my game also doesn’t get harder over time either – you get the same wave over and over again. Fix that, work on the animation (only one invader type animates, and it doesn’t do it well either), tweak a few settings here and there, redo the lousy background mountains, make the bonus UFO score actually mysterious (involving rocket counting, akin to the original game), and this would be done.
In my defence for not finishing this when it was so close, I wanted to get it working with the Indie City portal to get online leaderboards in since it’s a pure score attack game, but after getting it working initially, an update to the IC SDK caused a bug with my implementation of it, and that stopped me dead in my tracks. I might consider finishing this off at some point and releasing it as a freebie (or maybe as charity donationware).
The one regret I have with this is that I didn’t set the screen to be portrait at the very start rather than using landscape. I’m not sure why this didn’t occur to me at the time – a defining point of the game is the overall shape of it, and mine is just wrong – too wide. It works my way I guess, but if i could change anything that would be it.
OK – here’s the download link. Instructions are included on the front end screen, but I left in my invincibility testing mode, so press “i” to cheat if you feel that way inclined.
This is the work-in-progress for Dogfight Thing – a long-running project from two or three years ago. There’s a playable download for PC at the bottom of this post of the current state of the game which is exactly what is shown in the video – i.e. lacking a lot of gameplay.
Oh Dogfight Thing – how I wish I’d finished you. You never even got a proper placeholder name.
Dogfight Thing first started as a dabble with making something a little like Time Pilot – one of my favourite arcade games. It soon became an attempt to create the kind of simple dogfight game that was ubiquitous on 8 bit computers back in the day, or indeed as one game type of the classic VCS game Combat.
So I quickly knocked up a biplane model, because biplanes are brilliant (and it also gave me an excuse to give the pilot a nice flappy scarf). The first pass was a Sopwith Camel complete with authentic colouring and RAF rondels on its wings.
Before implementing player movement I then had to add some scenery so that you’d be able to tell you were moving since the camera would be tracking the player. I was reminded of one of the dogfight games on either my Vic 20 or C64 which had the player landing and taking-off from a runway, and remembering this fondly knew that my game had to feature the same mechanic so built an airstrip at the left of the map. The immediate thought was then if I’m taking off to start then so should the enemy, so I built another at the right, and this kind of cemented how the game would develop for a while – with two opposing forces fighting with the same tools.
With that in place I then got the player moving at a constant speed, and rotating to provide the nice loopy control method. However there was an issue in that if you perform a half loop then you end up flying upside-down. The old games used to prevent this by automatically performing Split-S and Immelman turns – half-rolling/half looping, but I didn’t want that because it would make full loops look strange, and there’s a lot of fun in just lazily looping the plane about. I briefly considered auto- half-rolling if the player stayed upside down for a short while, but that sounded nasty, so the only thing to do was add a button to half-roll. This solved the problem, but also added the ability to roll whenever you want which was a definite bonus. I later added trails to the wingtips when rolling turned out to be one of the things I liked doing the most (and indeed the ability to turn the trail length up to “Frankly Silly” in the options menu).
Adding the first enemy to shoot then brought a change of direction. I had a Sopwith Camel, so the obvious choice was to add a nice Fokker as the opponent, but at this point I decided I didn’t want to go there. I’d already got a nice blue sky with fluffy white clouds in place – this didn’t feel like the right place for real war. So I recoloured the player plane in nice bright red and made a blue copy for the enemies. At this point I decided that nobody dies in the game (pilots parachute safely out and toward the camera out of the 2d-plane that the game takes place on). I also decided that since the planes were identical that the people fighting were divided purely by their choice of colour – that was the only reason for the fighting (like the cat race in Red Dwarf). Further to this I then decided to try comic book style explosions, which I rather liked.
I think the art style was why Dogfight Thing never got a proper name. I usually like to pick a name (even a placeholder one) to help define the game and inform decisions throughout. I also like to find a nice font early on for the same reasons. The bright and breezy feel of the game possibly meant that this was less pressing here – it was the touchstone for everything else (when I added smoke trails to damaged planes I started out with white smoke that went black as more damage was taken, but this clearly isn’t a black smoke game, so I soon changed it for denser clouds of white).
Back to the name – I’d been toying with were really simple names like Super Sky Pilot, but never liked any enough to commit to. I tend to struggle with names for games, which is a little strange because I love naming things like achievements. But then you can get away with a pun or a cultural reference for those – they can be silly and throwaway, whereas I think a game name needs something more – it needs to be more robust.
The next thing I added was bombing and this played nicely too once I’d got the physics working OK, and with that I needed something to bomb, and this is when the idea to make the player a part of ongoing war came about.
The idea was to give both sides armories that would produce tanks and other vehicles which would automatically move toward their opponents airfields. They’d battle each other when they met, but the player and the AI could swing the odds by bombing the opposition tanks, in an attempt to allow them to capture the enemy airfield. A fair bit of work was done on this and I added things like spotter balloons and flak cannons, and had plans for zeppelins and bombers and additional ground vehicles.
But development was taking ages. Suddenly my simple dogfighting game now needed the best part of a full-blown cartoon war in it. Something had gone wrong – it was far too big. I called a halt and had a rethink.
A new plan was made – I shelved a lot of ideas, and decided to make it asymmetric. The player would be given an HQ to defend, and it was just them against the enemy army and air force. I’d make it level based with each level just requiring a certain number of tanks/planes and flak cannons to be destroyed. This was much more manageable and was still the plan when I stopped working on it (probably distracted by a new idea).
A couple of additional notes:
One feature I liked in this was the sortie score functionality. The idea being that after taking off any points scored were added to the sortie score, and kills and other feats would add to the sortie muliplier. The sortie score however would only get banked to the real score when the player landed to end the sortie – adding a real risk/reward mechanic to the combat – as the player started to take damage they’d be torn between banking the points and getting repaired, or staying out and risking the lot. Obviously without much in the way of threat currently it’s not really shown off to the full right now.
I’ve mentioned how the overall design spiralled out of control, but here’s a smaller example of feature creep. The spotter ballloons I added looked nice, and were fun to pop, but only brought a collision hazard to the game – nothing more. Yet, once in I felt it needed to be done properly. To that end if you burst the balloon the basket falls and the spotter parachutes down. The basket is shootable until it hits the ground if you’re quick. If you shoot the basket the spotter parachutes away, the balloon floats off, and is shootable until it gets too high. If you fly the plane through the cables in the gap between the basket and the balloon, you get a bonus, the balloon floats away, the basket falls and both are still shootable. If you shoot both you’d get a combo bonus. That’s a lot of work for something that is just an obstacle.
The thing that’s most noticeably missing is AI for the enemy planes. I was tempted to say I’m terrible at AI, but I’m not – I’m just really bad at sitting down and having a go at it. I want to do a really good job of it, and so I put it off to do a proper job of it later, and then never get back to it. The daft thing is much of the time you probably don’t know what’s going to work until you’ve tried something, and then it often becomes much clearer. I need to work on this going forward.
I would dearly like to return to Dogfight Thing, but I’m pretty sure it won’t pay my rent so I’m going to have to leave it for now.
This is the work-in-progress of Super Critter Kill, a game knocked up in a few days for a competition. The name is a working title that I’m not particularly fond of (it was originally called Fur Cry, but I changed that before posting here to prevent getting sued).
It’s lacking in many many areas, and obviously absolutely everything should be considered really early placeholder work, but it’s available to download and play for PC via the link at the bottom of this page. It was created in XNA so a link is provided for the runtime files it needs.
As mentioned, this was made in a very short time for a competition – the theme of which was Procedural Generation. The original intent was to procedurally generate an island, and make a 3rd person exploration game along the lines of Strange Adventures in Infinite Space, or The Wager – a typical island is shown opposite.
However, with just a few days left I realised I was nowhere near getting anything I could call a game out of that, so needed to come up with something else instead.
As an aside this original game went on to be my primary project (now on hold), and it’s one I’d dearly love to return to – but it’s massive. The basic premise is that the player is a Victorian-era explorer on a mysterious fantasy island populated by all manner of tribes and NPCs. The gameplay was intended to be almost entirely decision making with all manner of interesting consequences occurring based on the player’s actions. I do hope to return to this one in future, because it’s perhaps my favourite thing that I’ve worked on. (In the image below Branston is the players hapless manservant). At the very least I may cover it in a future WIP.
Returning to SCK and the problem of the impending deadline – I’d always wanted to try making a first-person shooter, and knew the beauty of working in 3D is that a quick camera change gets you a different genre cheaply. So I quickly moved the camera down to eye-level and placed it at the player’s position and it worked a treat. I then changed the control method to move the camera around, and added mouse control for looking around
Then I knocked up a quick arm and gun model, and positioned it just below the camera (the picture shows it with the camera pulled a little further back). Finally I added a bullet and got shooting in the game.
With that done I needed enemies, and with the art style and the time constraints I plumped for cartoon critters. Throughout my career as a game designer my stock response to the question “how do we improve this game?” is the answer “bears” so that’s the first thing I made, and added to the game.
Next up I needed to be able to shoot the bear so I hacked in some collision. Collision is a real weakness for me (hence there being no landscape collision in the game yet), so I fell back on trusty old spherical collision. I know just enough maths to transform a line of spheres to create approximate sausage-shaped collision which was good enough (and incredibly fast).
Having made the switch from XNA to Unity now, collision really isn’t an issue. I could probably even go the extra mile and not have completely flat landscape.
With that in place though I now needed to add behaviours to the bears. I kept this simple and created a set of states for them to be in.
Spawning: I didn’t have time to spawn them out of sight of the player, so decided to be silly and drop them in from the sky. I later added balloons and parachutes to them. (One of my favourite bits of advice for making games – if you’ve got a weakness try to make it a feature. Don’t try to hide it – stick it front and centre and make it work for you if possible.)
Mooching: When the bears land they start mooching if the player isn’t close. They pick a random location a short distance away, move to it, wait for a short while then repeat.
Following: If the player gets close turn to face and head toward them.
Angry: If the player shoots them, then they follow faster.
Dead: When hit points are zero keel over and wait to be skinned.
Skinned: Wait for a little while then disappear.
I then set up a simple set of timers to populate bears. There’s an upper limit of bears in the world at any one time, and the game spawns bears periodically until it’s reached. The maximum number of bears then also goes up over time so the game gets harder and harder.
With that in place I’ve almost got a game. I just need player death. This is handled really crudely – if a bear gets close enough you’re dead. It’s so harsh I put a warning alarm in when they get near, but it’s not a good solution.
However there was just enough game there that I decided to spend the remaining time creating new art assets – a swamp landscape type, and the panda and tiger models (largely recoloured bears). Perhaps the time would have been better spent adding scenery collision, route-finding for the critters or gameplay design that aspired to be better than the bare-minimum possible to call it playable.
So this is how it entered the competition – unsurprisingly it didn’t win. Afterwards I added the balloons/parachutes to the bears, and for release on this WIP I added the bear trap and crate pickup to make it slightly more worth a download.
So that’s largely where this prototype stands – the barest semblance of a game but bags of potential I reckon. If I was to resume this project the plan going forward would be as follows:
Decent collision – should be dead easy with Unity.
Level design – I’d probably remove the procedural map, and replace it with something nicely designed. The procedural island was a benefit to the original exploration game, but I’m not sure it brings much here. TBD.
Weapons: I need to replace that basic pistol with a range of cool and unusual weaponry (the beartrap is a nice aaddition and I’d already started work on a blunderbuss).
Vertical mouse look – omitted purely for lack of time – it’ll allow flying critters, and short ones.
Critters – more of them, the more taboo the better.
Animation – I’d rather not do animation, so I’ll either pull their legs off and rotate them to make a run cycle, rotate the whole animal in a kind of loping gait, or maybe create posed frames and swap the models. The benefit of being cartoony is that this is another weakness that could be turned into a plus point perhaps…
Animal behaviour – what’s there sucks, so this needs to be better and needs to be varied. Maybe getting more natural stuff in there – predators and prey doing their thing, herds, charging/stampeding etc.
Design: Add small details like a goal, a game structure etc. Is it a hunting game with animals sticking to habitats, or is it just a frenzied shooter, or something else entirely? TBD…
Name: Find a better one, or learn to live with this one.
The game is available to download below. Simply unzip it somewhere and double-click the exe to play. One warning though – the video at the top of the page shows pretty much everything that’s in the game – it’s fun to pootle around in, but there’s not much in the way of gameplay beyond shooting endless critters.
The plan is changing on an almost daily basis. The current plan is as follows:
The program I used to make my website named all the pages weirdly meaning I didn’t want to tell anyone about the release of AVC. I’ll get this fixed – manually if need be – tell people about it, and then park the website for a bit whilst I work out what went wrong/find something better to use.
The Works-In-Progress will be done via my blog initially – maybe moved over to the webpage later if I think there’s merit in that. I’ll try my best to get the first one out this week.
Game development is switching to Unity. I love XNA, but I need everything on my side – and that means as few barriers to entry and as much flexibility as possible. I’d tried using Unity before but the sample game it tends to push as a demo – Angry Bots – is a big old brute and not a pleasant way in to learning the package for me. My reluctance to move on from XNA and unfavourable first impressions meant I wasn’t looking forward to diving into learning Unity, but after a lot of procrastination I finally sat and watched all the beginner tutorial videos whilst having a bit of a play with the editor itself, and by Crikey! – now I’m a convert. I reckon I can do really good stuff with this. Absolutely cannot wait to get cracking. If the website and the works-in-progress don’t show up for a little while then Unity will be to blame. These games aren’t going to make themselves.
I was working for Blitz Games when I made my first post, and as of last Thursday it ceased trading, so now I’ve got to find something else to do instead.
Time to give the indie thing a pop for real then.
To that end I’ve just released the one project that I’ve ever finished as a freebie, and then it’s on to new stuff. It’s a simple PC game called A Vicios Circle, knocked up in a matter of days, fittingly for a coding competition at Blitz. You can get it at www.bearcatgames.com
I still plan to do the Works-In-Progress, but they will have to fit in around my current new project which is intended to be my first commercial game. The first was almost good to go though, so it shouldn’t be too far off.
For this the first blog post by Bearcat Games I’d like to outline my current focus – a series of works-in-progress. One of the hardest things to do as a game developer is finish a project, and this holds true for me too. However, I’m also guilty of getting bored and starting something new mid-way through a project – meaning I’ve got a lot of work sitting on my hard-drive going nowhere, and seen by no-one other than me.
So a short while ago I decided that perhaps the best way to deal with this is to start releasing these to the world in their current state (maybe with a few tweaks here and there to kick them into a state where they can be shown, and more importantly played). So in the coming months I will be releasing a new one every week or so on my website (www.bearcatgames.com) along with some accompanying notes – these might include topics such as how it came about, design decisions, implementation, planned features etc. These works-in-progress will be in varying states – some of them have had many months of development, some were knocked up in 3 or 4 days.
Each new game will be accompanied by a blog post here, and I’d really appreciate feedback in the comments thread for each game. One of the things I’m hoping to get from this is motivation to get back to some of these projects and push them towards completion.
First up (hopefully coming in the next few days) will be Super Critter Kill (working title) – a cartoon FPS game about shooting endangered species for their skins.