Thursday 24 March 2011

Example Ship Configurations

Now that the ship editor is actually functional, I can post a couple of screenshots of example ship configurations.  They're not particularly varied, as I've only bothered to make a minimal set of ship components at the moment, but it should be informative, at least.

The two weapons shown here are the basic energy cannon (which was the first weapon implemented) and the laser cannon (a straight line instant hit weapon).  As work progresses, a lot of other weapons will be implemented, and upgrades will be generated for existing ones.

This first configuration places two laser cannons on the back of the ship, thus providing some all round firepower.

The second configuration concentrates all the firepower to the front, allowing more effective frontal assault of a swarm.  Having a power generator exposed on the back probably isn't a great idea, though.


Thursday Haikus

Programming a game\
It takes a bastard long time\
Hope this fucker sells\

Alternatively:

Coding all day long\
What time can I start drinking\
Without being a lush?\

Right, back to sexing up the ship editor.

Wednesday 23 March 2011

Video Test



This is a test video I made a while ago using CamStudio, but hadn't gotten around to uploading until now: the FPS isn't amazing, as my development machine does *not* like running the game at full FPS while simultaneously encoding, but it should give a first indication as to what the basic gameplay will be like.  It only shows a couple of weapon types (standard projectile + lightning blast), but it does feature the newer particle effects, although it predates the recent improvements in environment decoration.



[OK, what the Blogger upload did there was take my already highly compressed video and then proceed to squash the Bejeesus out of it.  Hopefully it still gives a bit of an idea, though].

When creating the main demo video in the next few months (as part of my Indie Fund application), I'm going to have to find some way of recording at full fps, which may involve adding the ability to specifically seed the random number generators and record player input, then play it back frame-by-frame so that processor power isn't an issue.  Which will be a bit of an arse, but as the most important (and pretty much only) part to the Indie Fund application process, it's definitely worth the time.

Feeling all GUI.

So far this week I've been continuing work on the main GUI system, and have certainly now churned out enough code for a fair number of simpler games than Juggernaut.  For example, if I ever need to do some kind of drag-and-drop 2D puzzle game I'm now pretty much set!

Although the GUI system is completely custom, I've based the layout fundamentals on Windows Presentation Foundation in terms of split panels/stack panels because, although I grew to hate WPF with a manic passion, the layout system was pretty good.  It would have been easier just to hard code all the panel positions for the ship editor, but bothering to do a passable layout system will make subsequent GUIs (such as the main menu) much simpler.

Just for you, even though it's still early days, I thought I'd post a screenshot of the early version of the ship editor, since it's been a while and I know how much people prefer a picture:

A first look at an early version of the ship editor, with a list of components on the right hand side that may be dragged on the main playfield and then attached to the ship.  Note that the background textures and title are just placeholders, and will be replaced by something much more sexy.  The basic layout is likely to stay pretty much the same, though.

Anyway, once I've finished off the most basic functionality of the ship editor (which should be today or tomorrow), I'll probably go back to the world editor and allow distribution of ship components throughout the environment that you can find and then bolt onto your ship.

Current Juggernaut code base size: 1.25 Megabytes.  Great Expectations by Charles Dickens weighs in at about 1 Megabyte.

Sunday 20 March 2011

Game Review: Dead Rising 2

OK, as well as posting status updates for Juggernaut I thought I'd also post a few game reviews as well. A couple of weeks ago I bought Assassin's Creed 2 and Dead Rising 2 on the cheap, and finished Dead Rising 2 early last week.

The first issue I had with DR2 was that it crashed completely on start-up, a problem that I fixed (after looking on forums) by changing my sound card settings.  Changing my sound card settings?  Is this still the early 90s?  Anyway, for a large company with proper QA teams this is a piss-poor fatal error to leave in.

Firstly, I have to say that overall, I did enjoy DR2 a lot: it does manage to effectively portray large crowds of zombies that you can mow your way through (sometimes literally) in an entertaining fashion. Unlike the Left 4 Dead franchise, these are proper old-school shambling zombies and, importantly, it's simply not possible to kill them all because there are so damn many: this is very different from L4D, where you pretty much have to kill every zombie you come across. When travelling around, usually inside a large mall, you instead find yourself running through the least dense areas and only killing zombies when you have to.  There was a particular highpoint when I found myself wearing a summer dress, Davy Crockett hat and spearing zombies with a swordfish that I'd pulled off the wall of a casino.

The overall game is timed, and certain events/missions will occur at specified times, meaning that is was impossible to complete anywhere near all the missions, leaving a lot of scope for replay. Although this is an effective mechanic, there are times when it's possible to end up with savepoints in either completely unwinnable or almost unwinnable positions. For some of the main missions (which must be completed else the game forces you to restart), the bar that shows you how long you have left to complete it may actually encompass the entire amount of time it requires to do 4 parts of a multi-part mission, with no idea how long it will take to do each part. A much better way to do this would have been to set time limits for the start of each mission sub-section, meaning that you could guarantee that the overall mission was always possible in the time available.

However, the main issue with Dead Rising 2 as a game is the balance, in that there isn't any. Seriously, elements of this game are as balanced as an upturned pyramid on cocaine. I fought bosses a quarter of the way through this game that made the final boss feel like punching out a 10 year-old with leukaemia. Especially since, in a fit of genius, you only earn the essential "dodge roll" move several hours after you've had to fight the bosses it was really necessary for.

Strangely, all the difficult bosses you'll fight are human, not undead. Hell, you can destroy any of the zombies with a couple of hits from a sledgehammer, it's those pesky humans that require 200 rounds of machinegun fire to the head followed by a good pounding with a baseball bat before they'll feel faint. It's particularly irksome when they're a fucking hippy armed with a shard of glass.

Seriously, though, if you're going to make difficult boss fights that you are going to die on a *lot*, not allowing players to save directly beforehand is just being a bastard. A lot of the time you'll need to run for a couple of minutes from your last save point back to the boss area, simply to get immediately killed and have to do the whole thing again.  This does not make for fun gameplay.

Oh yes, and the final final boss fight relies way too much on quicktime events, which everyone knows are a bad idea but they still keep getting put in games. To be fair, they're not "Press X Not To Die" ones (unlike Dead Space 2, which was a bastard for them), but it's still quite annoying.  Especially, I have to say, when they're converted to the PC and so the button flashes say "WASD" - because you are only using the buttons as up/down/left/right, I (and I suspect it's not just me) find it mentally harder to map "W" when it flashes up instantly to the "up" button than if it just used a directional arrow.

Yahtzee's Review also rings very true, and he complained about pretty much the same things that I found annoying.

Anyway, the moral of the story for game design is:
- Add savepoints before encounters you expect players to repeatedly die on so they can jump straight back into it, else they will get mightily frustrated.
- Don't take away essential gameplay elements (such as the damn dodge roll) simply to boost your levelling system.
- Make sure that you don't let players save the game in an unwinnable state.

Within the main design for Juggernaut, there is a checkpoint structure that the player will respawn from every time their ship is destroyed (it's even justified within the storyline), so this will allow easy avoidance of the first issue by providing the automatic saving of progress.