Demo'ed and didn't Die!

This week, minds were blown as a demo version of U-F-OMG was successfully showcased during an AINT102 workshop, giving new insight into the world of the incredibly well crafted, perfectly executed games that I produce!

Sadly, some of that explanation may have been poetic licence. Though I didn't expect it to be a problem, I exported my demo version of the game to a .swf file for the enjoyment of my coursemates and lecturers. This sadly lead to a lot of problems with mouse lag, that, when the game runs in stencylworks, are non-existent. I think these problems stem from my attempt to include more than one human actor type, and from having a quite process intense 'always' event controlling the movement of the human actors. In response to this I have made a couple of fixes in the last week (22/11/2012), namely;

• Returning to using only one type of human actor
• Modifying the human movement AI in order to use an 'Every n seconds' event rather than an 'Always' event, meaning they check to see where the player ship is every second

I also recieved some feedback from other students and lecturers in the form of a google docs questionnaire (An idea that was blatantly stolen from me), the results of which have been made available to me now. According to that feedback and my own plans I will be continuing to develop the game over the next weeks and planning to deliver a finished prototype by the tenth of december. For the mean time, take a look at the recording taken of some demo play of the game, lag free due to being run in stencyl.

The Second Wave

Yes indeedy, it's time for the second lot of testing!

Having posted a second demo on facebook and created a second google form, I've started getting feedback on the newer version of my game. At the time of writing my main point seems to be, stop the humans from accidentally moving whilst being abducted, should be simple. I've also been given a complaint about the performance of the mouse in the game. This worries me as, whilst it could well be an easy fix, it could also mean that the game's lagging due to all the 'kill, create' functions whizzing about, which would be bad as tinkering with using the recycle command lead to all kinds of nastiness last time! Either way, it shall be looked into.

So yeah, I'll keep an eye on the form today, and hopefully I'll be working on the game all day in preparation for the demo or die tomorrow! Wish me luck!

I'll leave you with a few screenshots.

The lovely title screen, sadly I couldn't print screen the wicked music that accompanies it!

Tutorial screen

A bit of in game, by now you've probably seen this, I love it though!

My (Almost Crushingly) Honest Friends

So, remember the small play test version of the game I released? Yeah, basically unplayable.
Just kidding! Only mostly unplayable! In fact it was a fantastic opportunity to step back and have a look at what other people thought of my game, and my first notion was;

Ease of Play
 Far too many of the people I asked to test my game (Including my dear, ancient father) found it was nigh impossible to understand what was going on, and the game was so punishingly difficult that there was little chance to experiment in game. Well, fristly, I've implemented a but of logic to make the difficulty scale over time. At the minute that's not really working properly, but the game is at least quite easy. I'm also implementing a tutorial level, with one simple enemy that constantly respawns, allowing the player to get used to the controls in a less stressful environment. I also had responses that, as the ship is symettrical, it would be useful to have animations that showed plainly which direction the ship was facing, and this is something I'm still working on, as it's difficult to design a UFO with a nice grill on the front that still looks inkeeping with the aesthetic, but then maybe that's where I'm going wrong...

Fire at Mouse
At first I was of the notion that it would make it cool and difficult if I forced the player to have only one direction of fire. This was stupid. It's not fun to lose a game because the game mechanic is deliberately hobbled. Hence I've now added a 'fire at moust cursor' function, whereby the player clicks an area of the screen and the subjugation ray fires in that direction.

Score System
Despite the fact survival is the main point of the game, it was important that players be able to quantify what they were doing. For this I've implemented a score system, whereby players score a small number of points for a successful hit with the subjugation ray and slightly more points for a successful abduction.

In terms of glitches, it was reported that, upon retrying the game the human enemies no longer spawned into the play scene. This was due to a variable that I wasn't resetting at the beginning of each new scene, and has since been fixed. I also made the fade in and out times shorter between each scene. Most irritatingly a bug was reported where, upon being recycled and created in the scene again, human enemies would no longer stun properly, continuing to move but still able to be abducted. I seem to have been able to fix this by using the 'kill' command rather than the 'recycle' command, however this is messy in terms of processing, and I would rather know the exact cause of the problem.

So, here are a few screenshots of the game as it stands here, and hopefully I'll be producing another little demo some time this week, and once again collecting all the feedback I can.

Until next time!
Jack

Apologies for the Delay

Hello again! Yes, it's certainly been a while. As I should have possibly foreseen, the other parts of my course that I was moaning about rather a while ago suddenly started becoming actually important meaning less time was dedicated to the game. This alongside problems with my student bank account and a trip to the Explay event in Bath mean my progress with my game has been somewhat lackadaisical of late, but no more!

In terms of development, things have been going pretty well with the game, I have what is pretty much a fully playable demo ready, with a fail state and restart buttons and everything! So after a pretty good tutorial session (those have picked up as well) with some of the CGD staff, I got a lot of feedback on how getting some playtesting going would be a good idea. So, being the conscientious man that I am, I went ahead and created a little facebook group of a few close friends (brutally honest close friends, at that), gave them the .swf of my game and a link to a google form for feedback and let them loose.

Needless to say, this was fantastic advice. The bug reports that I got were almost all things I had missed during playtesting, and I was given some suggestions that I hadn't really thought about before, or that reinforced feelings I had about the game mechanic already. So as of this morning I've set to work fixing those bits, with the intention of releasing a second demo for the same group, to see what they think.

But that's not my only plan! I know that contracting a load of people you already know is not the best way to play test a game, so I want to get this out to a wider audience. Just how? I'm not sure yet, but there's a whole load of pin boards around the university with space on, so I was thinking of perhaps finding a bit of free, online file hosting space and posting up the address of the file and the form, hopefully catching some random members of the public, getting some good feedback and maybe spreading a bit of hype for the game? (Hmmm)


So yes, that's the plan of action, the previous events and the crap excuses out of the way, hopefully I should be able to post a few screenshots of the game looking a bit more polished soon. Until then, see you next time!