Tutorial Catchup
Yesterday we had our first tutorial after the Christmas break. It was good to catch up with Dan and Ben again, and talk though the progress I have made on my DMP project. I'm going to use this blog post to quickly run though what was said during the meeting, and my action plan based on its outcomes.
Me spent a lot of the beginning of the meeting talking though what was needed for the report, which is really good because I had no idea. The crux of it is that we will get more tailored guides as to what is needed, as well of a check list of things to include in about 2 weeks. Because of this I'm going to spend the next couple of weeks working on the more technical side of my project.
Speaking about my porject, it was important to work out MoSCoW, or in lamens terms:
- Must Have
- Should Have
- Could Have
- Would Have
This is in reference to my requirements. I'm going to work on a detailed list for the next post, but the two major must haves I havn't done yet are getting the counter working accuretly, and knowing when something is knocked off the screen, and getting the fog objects floating on during game play.
One of the other things I needed to look at was the marker for tracking the user. Currently its just a red circle, and the group suggested I look into using an image, or using the camera to put a shadow of the user back in. Id quite like to do some research into this area, so we shall see how that goes.
Another idea that came across was making the game both Usable and Delightful. This was about putting more effort into the visual design of the game, and the user thinking. Making it fun for the user to play, and working out the game rewards. I thinking when I work out my requirements a lot of this will fall to the wayside, but I would like to write up these ideas into my report.
That was about it I think. For the Next two weeks I'm going to work on getting those last two Must have requirements working, and them from their start writing my report, and see what time allows whilst working out my finished project.
Poster Presentation Mark
Just got my poster presentation mark back. Got a 70, which is just the right side of the border for a 1st. So happy with that. I think I'm going to give up on flash development for the rest of the week. Going to wait to show of my Christmas work to the tutors, and talk to my flash developer friend about how to go about the next stage of the project (working out when a fog object is off the screen).
So until then I'm going to try and crack on with other uni work, as their is a fair bit to do. Also going to start prepping the final report for DMP. Going to try and work out what needs to go in it, then show this to Dan on Friday and get feedback. Then spend the weekend hopefully trying to have a bit of fun, as well as getting on with starting the report proper.
Progress Review 4 – Sunday 24th January
Now I'm officially back at uni, I figured I better get on with a Progress Review. Its been a while since my last progress review (11th Jan) and even longer since my last real Progress Review (November! oops!). Lets see how I've been getting on.
Work Completed so Far
I'm getting on quite well with work at the moment. My prototype is now up to version 3. Ive added loads of features such as the timer and percentage counter, that basically work. Ive also got pretty close to my final design, which I'm pretty happy with considering my design skills are pretty poor. That's a lot of pretty.
Ive also started a lot more user thinking. I've started researching other games, and have been using this to develop my games Ive also written some questions for the guys and gals at Aardman Digital to answer about designing games for children, so that should help me out a lot. Overall, I'm happy for now.
Evaluation of Work so Far
Not bad I reckon. I know my code is pretty poor, but for now it works. My aim is to get it working alright, then try and refine certain bits to get those technical marks up. The same really applies to my final design. Its good enough, but I would like to look better. Oh well.
I'm a little worried that I've not started writting my Final report for this project yet, and we've not had much input from the tutors about it. Hence why I've been keeping a fairly heavy deauty blog about all my work, so hopefully I can copy/paste/rewrite a lot of my ideas.
Action Plan
The next stage of development is one I have been putting off, which is working out when a blob has been knocked of screen. I think I'm going to have a chat with a Professional Flash developer friend of mine and get some advice on how to do it.
I also need to continue with research and user thinking, and start writting my final report. Lots to do so little time. Eek!
Prototype 3 – now with percentage’s (Sort Off)
Ive been working away on version 3 of the prototype, which has all the bits I've mentioned already. There are a few changes in this one compare to version 2.
Firstly, the timer has been added. Its currently red but I'm going to change this soon. Its also in a digital font on my machine, but I'll embed it soon so it looks better.
Secondly, you'll notice the percentage counter. This is a bit of a proof of concept more than anything as it just takes the number of blobs, and adds "0%" to the end to give you a percentage out of a hundred. It also changes colour depending how many blobs are on screen, as I detailed in an earlier post.
Thirdly, but not least, is that every time you load the flash it creates a random number of blobs between 1 and 10. This is in reality to show off the percentage counter working.
Anyway that's enough talking. Go play! There should also be an animation coming soon for none web types showing the random positioned blobs and the percentage counter.
Prototype Animation
Ive put together an animation of my prototype (without the fog, that's coming) for people who don't have web cams. Take a look:
http://serve.discoliam.com/prototype/animation/
That progress review is coming. I started, just didn't finish.
Effects of C02 on people, and how to visualise this in the game
My last post got me thinking about how to represent the user dieing. Lots of games have visual clues that a user is dieing/failing task etc, though I can mostly only think of first person shooters. (Pictures bellow) Some games have other methods, like guitar hero (as discussed in the last post) has a bar showing how well your doing, and if you fail you are boo'd of stage. In the burnout series of games, your car is shown to be getting more and more destroyed. In Grand Theft Auto the screen fades to black and white as the character is sprawled across the floor.
Here the player in doom is show to have ill health
Blood and dirt on the screen in Modern Warfare 2
Fading to black and white as you die in GTA IV
Since this is a common gaming technique I thought about what should happen in my game? Clearly the bleeding character or blood on the screen would not be suitable for my younger players. There is a lot of evidence of video games effecting children badly, and i certainly don't want to reduce my children to tears, just teach them something.
I also thought it important to make the game as realistic as possible. There's no point having fairies floating around telling you that you've died. I first tried looking into the effects of rising CO2 levels on humans, which is called Hypercapnia. This Thread on Google Answers (I didn't even know they had an answers system!) and the article on wikipedia contained lots of useful information. Ive listed some effects bellow:
- lowers the shivering threshold and increases core cooling rate
- Effects Diaphragmatic Function - Harder to breath, became tired easier
- Acidosis (Acid in the Blood) Serious and sometimes fatal
- Headache, Nausea and Visual Disturbances
- "In 1986, volcanic Lake Nyos erupted huge quantities of CO2, resulting in the deaths of approximately 1800 people and thousands of livestock up to 25 km away."
- flushed skin
- Extrasystoles
- muscle twitches
- hand flaps
- reduced neural activity
- raised blood pressure.
Studies also showed that these would only happen when CO2 was at 15,000 ppm, or 40 times the current levels, which gives me some suggestion of when these things should start taking place in the game.
During my research I discovered the article Does Easy Do It? Children, Games, and Learning By Seymour Papert, a living legend in computer science and learning. Lego even named the Mindstorms system after one of his books.
The article most talks about games aimed at learning, as opposed to informing which is the main aim of my game. Though the two are similar, there are differences (as far as i see it). There is some good advice to take from the article though, including this quote I'd like to share:
"Frankly, I think that it is downright immoral to trick children into learning and doing math when they think they are just playing an innocent game. To make the situation worse (as if anything can be worse than lying to children), the deception does not achieve any purpose, since cooperative learners who know what they are doing will learn far better than children who go mindlessly through the motions of learning."
All this has left me with an awful lot to think about, and a lot more to read. Hopefully I can start getting some solid ideas down on paper soon.
Refined Percentage Display
My rather talented girlfriend surggested an idea for my final design. Giving a bit of colour feedback within the percentage display, so the user can see how there doing in a quick glance.
I liked the idea and decided to persue it further. I immediately thought of Guitar Hero, which has a similar system for telling you how well you are doing.
The bar on the left of each track in the above screenshot shows how well a player is doing. Here they use 3 sections Green if your doing well, yellow if your average and red if your doing really rather poor.
I've plumped for a similer system. Since we're doing it in percentage of Co2 in the atmosphere, it made sense to do 4 colours, one for every 25% section.
- 0 - 25% Green
- 26 - 50% Yellow
- 51 - 75% Orange
- 76% - 100% Red
And here's all 4 colours from the design.
This got me into thinking about how to show the user dieing. As in the game the CO2 will kill you in the end. I think more research is required.
Timer in Prototype
I can't be arsed to put it online, but after to many hours of wrangling Ive got my timer working in my prototype. So far its just a text field on the stage, but the next step will be to generate the text field using action script, but I don't really understand the documentation yet, and I've not found a decent tutorial 
This flash stuff is hard. I might right a progress review on friday.
More Final Designs
Since Ive got my timer working (see bellow) I thought I better add the text stuff to my final design. The font is Digital 7, and I think it looks good. Thoughts?
Building my Timer
Today I have been working on building the timer for the game, which counts how long you have been playing. I couldn't find a tutorial that did what I wanted, so I set about building my own. It took shitting ages, must longer than it should. But after a while, I finally got somewhere. The tutorials I used included:
I spent my first hour trying to work out why tutorials I was using weren't working, then I realised that this was because they where in AS2, and I'm in AS3, Idiot. Never mind.
So that's it really. Next I need to add it to the game, and work out how to do the embedding, as it just broke it when I tried to embed the font. Oh well. It will have a nice LCD style one, and be in red.