Fuck screenshots...

...this is a flash game!

Controls: Up and/or Down. That's it. That's all you get. Every time the mode changes, the effect of those two buttons changes. It's up to you to figure the rest out.

Iteration the Furst: this is the version that was presented as a prototype on Wednesday 24 March



Feedback was mostly on the pacing - changing to a different screen between modes really disrupted the gameplay, and it felt a little slow. It's also perhaps a little too hard.

Iteration the Next: this is the slightly updated version that was presented for more different feedbacks on the following Monday. Not much changed, really, except for pacing. The whole thing is kind of more hectic (and possibly confusing?)



Still probably too hard, harder than the previous version, because it's faster. Some useful stuff came out of the feedback session, most importantly that we need to nail down our target audience before we iterate more. There are also plans in the wings for more player feedback and clearer flagging of new game modes. Some complaints were made over the acceleration and drag on the character movement, too. I am currently in the process of stripping down the code base and turning it into a more modular system.

ALSO the text is off-centre and it bothers me. I will fix that at some point.

Target Practise

Current vaguely scheduled list of targets/goals I'd like to hit this semester. Subject to frequent updates and adjustments. Delivery times are 'as at end of week x'.

Week 6
Primary: Sound design breakdowns complete
Placeholder SFX implemented in projects
Secondary:
Story treatment roughs completed

Week 7
Primary:
Initial rough music concepts
Secondary:
Design documentation completed, if required by teams

Week 8
Primary:
Sound system initial version complete

Week 9
Primary:
Music concepts complete and locked in

Week 10
Primary:
Majority of SFX recorded/produced and in place

Week 11
Primary:
Sound system final version complete

Week 12
Primary:
Music composition and production complete

Going solo, update

Here is a clearer list of what, in an ideal world, I would like to achieve by the end of this semester (some of these, of course, may get extended to whole-year goals).

Mostly copied and pasted from my individual contract for this semester, but it helps me to put it up here.

Primary Goals

Sound Design

I will write sound design breakdowns for at least 3 – 4 projects (initially I am thinking for Horse, Bullet, Lantern and Islands), if not all of them. This includes lists of sound effects required, brief documents discussing the choices made in the sound design and the intended impact of sound and music on the player.

Sound Programming

I will build and maintain a sound system for use in Unity projects to streamline the inclusion of sound in the game. This is dependent on the nature of each game, whether the sound needs to be simulated in 3D space or not, and the needs of the separate teams.

I am still unclear as to the exact nature of this system. I am hoping that over the next week with some more feedback I will be able to define the problem better and start building a solution.

Music Composition/Effects Production

I will be composing most, if not all, of the music for Horse. This will include different tunes with various arrangements and styles for different stages of the game. While initially the music should have an 8-bit feel to match the retro look of the game, it should change frequently and drastically, in accordance with the subversive nature of the game design.

I have also been asked to compose the music for Bullet. The current music direction suggested is something on the lines of 'epic strings'.

I am keen to compose music for Islands, as this would allow me to explore a slightly different realm of composition – rather than music that is based specifically on the visuals or the theme of the game, Islands requires music that evokes a specific emotional reaction in the player.

Over the course of the projects, I will build up a library of sound effects based on the sound design for each game. Some of these may be generated using synths or tools such as SFXR, others will be Foley and general effects recorded at my home studio or sourced from various free sound effects libraries.

Secondary Goals

Story treatments

Subject to the desires of the core teams, I will be assisting with the development of narrative contexts for the Lantern and Islands projects. If this goes ahead, I will be writing story treatments for both games that form part of the overall design and inform the use of the gameplay mechanics involved.

Design Documentation

This is less of an individual focus and more of an element of the overall group design work. I am including it here because I have a specific interest in synthesising design ideas into a clear written format that effectively communicates the core concept of a project. I would like to use my writing abilities to help teams bring their ideas together into a cohesive whole that can be used for reference during development.

I will put my scheduling goals in a separate post, so that I don't get tl;dr problems when I need to refer back to them.

The Prototype - Retrospective

Just some quick reflections on Wednesday's prototype presentation session.

I think, overall, it went pretty well. Everyone had something to show that answered some of the questions raised by the pitches, and the feedback and criticism given was generally constructive and meaningful.

The presentation of Fishman didn't go too poorly. I was of course disappointed that I wasn't able to demonstrate it clearly, but the reception of my explanation was not received as harshly as I might have expected. I think a large part of the problems that occurred with the prototype of Fishman was that Henrik and I were trying to tackle the prototyping of two games with just the two of us, while other teams were focussing on a single game or spreading the workload to more team members (the work for Lantern and Islands, collectively, was split between four people).

The key problem, however, was the inability of ordinary keyboard interaction to accurately demonstrate the gameplay mechanic. Fishman is something of an input gimmick game (this is not strictly a bad thing), and it really doesn't work without the mic input. I had put together a very simple demonstration in processing of how the volume information from the input could be used to raise and lower the height of a bar, but unfortunately the microphones on the lab computers weren't working.

The net result is that Henrik and I have decided to put Fishman on the backburner at this point. We are not giving up completely on the idea, and I for one still think it has the potential to be an interesting game, but I don't want to sink time solely into trying to get the code the input analysis to work properly when I could be developing something that I know we have already proven.

The presentation of Horse, on the other hand, was fairly successful. I think the prototype helped us towards answering the question about timing - there was some pertinent feedback given on this, particularly that the game should continue running when the player gets an alert that the gameplay is about to change. It was also recommended that we make the different stages more distinct, which I know was something Henrik had been planning on anyway. Over the weekend, I will be working on passing the game information between the gameplay states so that the player's experience of the game doesn't get put on hold when the state changes, while Henrik will be developing more art and designs.

We'll also both be tinkering around with writing some silly dinky 8bit music to put into the prototype, with musagi (I will probably also faff around with midi data in Pro Tools).

With regard to other people's prototypes, there was some really nice work demonstrated - some in particular that I would like to be involved in the initial design and writing stages of, as long as the core team members are willing to have me on board. I'll probably be sending out a few emails with more detail to this effect.

That's all I can think of that needs to be addressed for now. I am of course working out my individual contract to deliver to Matt by the end of the day.

Going solo

Hey there cats and kittens. This is your recently-appointed resident sound guy talking (okay, sound girl, technically, but that sounds naff and wishy-washy).

Finally getting around to blogging about my individual role for this semester's projects, so that all of you (my current developers-in-arms) what's going on, and what you can ask me for if you need it.

The way I am currently thinking about it, the role of sound in these projects can be broken down into three areas:

1. Design

The decision-making process. This is really key to the what, if any, impact sound has on the way the player plays the game, and the player's impression of the game.

Off the top of my head, this is the sort of stuff I can work with people on, if you guys want my input:

• deciding where and if music or sound effects should be used
• picking and choosing the right kinds of sounds and the right places to use them
• what will they signify to the player?
• do they serve as feedback or stimulus?
• will the player be able to read them correctly?

2. Sound programming

I would really like to build some kind of simple system that everyone can use to easily organise and trigger sounds and music for their games (probably in Unity, since the majority of projects will be happening in that).

I haven't had a chance to think too deeply about this yet, and I would welcome feedback on the kind of system people would like in order to help them streamline the audio pipeline. How would you guys like to be able to handle sound in your scripting?

3. Composition/Recording

This one is slightly trickier. I am a little rusty in this area, and I am not sure how quickly I will be able to produce music and/or effects. At this stage, I'm going to say tentatively that I will do the music for two projects this semester. These are actually already pretty much set - I'd like to compose for Horse, because there is the potential for a lot of fun and silly chiptuning there, and Tyson has already lined me up to work on their Bullet game, so unless the projects get especially shuffled around these two are pretty much locked in.

That said, if people want me to record Foley or create SFX (or even come over to my place and do their own while I record), I am happy for this to be arranged.

Do let me know if you want this facility available to you as an option, because I need an excuse to go get a new mic + monitoring headphones, and I will need time to sort that out.

So, in a nutshell, get in touch if you want soundie stuff, kids.

Brutality

Okay, time for some honesty. The latest version of the fishman gameplay prototype is up here and I'm frankly tired of dancing around the main point that keeps coming up as I work on it, which is this:

It's shit.

It fails to communicate with the player, the interactions are unclear, it's clunky, and above all, it's boring and feels pointless. I know there are things missing, like a decent GUI and specific end states, but if the main mechanic feels like crap, then there's no point in dressing it up.

So. Failed experiment. Moving on to horse tomorrow, which I hope I can manage to not screw up.

The progress of fishman

Gradually getting somewhere with this. There is a newer, more playable and commented-code type version of the unity project on Dropbox. It suffers, at the moment, from grey box lolz visuals, but the key things are there.

To be honest, I'm not sure how well it's expressing the gameplay though. I know the theory of the mechanic is okay, but in practise it may well turn out to be a little lacking. Hmm.

Trying to nut out some better visual feedback for the player and tweak the feel of the gameplay now.

We are only going to spend at most another day on this before we move on to prototyping Horse in Flixel.

Illuminated thoughts

Just some quick notes with reference to the amalgamation of my Chiaroscuro and Zac's Lantern game.

After the pitch we had a quick discussion about the two ideas, the key point being of course that they approach the same idea (the rather obvious duality of light and darkness), but from opposite ends - while his character emanates light, mine draws in darkness.

There didn't seem to be a way to comfortably reconcile these two concepts in the already quite well-defined character of Zac's lantern guy, so this is where the idea developed of having two characters with distinct abilities who have to help each other through the environment. As evident in Zac, Amjad and Cameron's blogs, they are rapidly progressing and solidifying the concept - I particularly like the idea they have developed of the dark character taking a slightly less human/solid form and being able to climb and jump to areas Lantern Guy can't, and it opens up more scope for puzzle elements than were available to either of the characters individually.

I do think it would be nice to keep the lantern as a linking motif between the characters - possibly as something they have to pass back and forth and use in different ways in order to solve puzzles (in the hands of Lantern guy, it emanates light, whereas in the hands of the dark character it draws in the darkness). On a different tack, if the two characters are made completely distinct, it might be worth keeping our minds open to the possibility of the game working as a two-player co-op experience, but I don't think it really needs to be considered for the purposes of the prototype.

As it stands, I am perfectly happy to step back from the design and development of the Lantern game at this stage unless my input is specifically requested. I think these guys are doing a stellar job and taking the gameplay in an interesting direction.

Technorage

Suffering from computer troubles of various kinds. Bizarre corrupt file problems have been plagueing my rubbishy Unity prototype project and I've had multiple crashes with no useful error information. Not to mention my usual Windows problems. So I've gone a little dim (not dark, I promise!)

Net result: I am behind in my work. This is something of a concern, particularly when I look around and see the amount and quality of work that other people have already achieved. It is time, therefore, to start pouring out that bottle of midnight oil into the lamp. So it begins, and so, I suspect, will continue - the next week will set the rhythm for the semester, and probably the year. Not what I would call an auspicious start, but we take what we can get.

Anyway, so. Here is my current complete trainwreck of a prototype on Dropbox, to be updated as frequently as I am able. There are grey things. They move. They move slightly differently if you press keys. It's a... well, it's a thing.

I suppose.

http://dl.dropbox.com/u/2512414/3114GFS/fishman2.zip

And so it begins

Along with Henrik, I will be prototyping my concept 'The Fisherman and the Moon', codename Fishman, and Henrik's unnamed concept, codename Horse.

First off, after a quick chat with Henrik, we decided to go ahead and work in Fishman in Unity, because we can use this FMOD plugin, which will be necessary for sound manipulation and analysis (more on this when I've looked into it in more detail). Horse, however, will be developed as a flash game, with the Flixel library in Adobe's Flex Builder.

The aim now is to get a functioning game working in Unity, with a variety of grey boxes to represent in-game objects and, at this stage, key presses in place of loud/soft sounds.

Tasks I'm working on for Fishman (Horse to come later):

- set up scene, locked to 2D plane
- on key-press
- the moon moves/changes direction/changes speed
- the fisherman's boat moves/changes speed
- win state when fisherman reaches shore
- loss state when moon gets too close (boat 'capsizes')

More as it comes to hand.

The Pitch - Retrospective

I've put a bit of thought into the outcomes of this session and my reactions to it, and haven't been able to come to a satisfactory conclusion.

I think the net outcome was successful, but the process was incredibly wearing, and perhaps this is because it was not entirely what I expected. I felt that we had all worked too individually, and I think the game ideas we were pitching were, on the whole, too complete. The result was what I like to think of as the ownership problem - there was a sense that each pitch idea belonged specifically to the person who had pitched it.

The following session of picking and choosing the games we were going to prototype was therefore very difficult, because the language we were using lent itself to the description of the games by the name of the originator. It was difficult to separate which game we wanted to make from the idea of whose game we wanted to make. That said, I think the whole class managed this quite well in the end, and I think we have a good range of interesting and diverse prototypes to work on at this stage.

Vis-a-vis my individual experience of the pitch, I will say that I wasn't happy with it. In my impeccable 20/20 hindsight, it may have better not to include Threadsuns in my pitch. In my head, it was a very malleable idea that I just wanted to put out there for kicks, and I was hoping for maybe a little more interaction and back-and-forth during the pitch session (see above re: possession problem). Again, I think everyone was too shy to put their own spin on something that was being presented as 'my' idea and 'my' game.

Alternatively, they thought it was a stupid idea (never ever rule this out. Everyone has stupid ideas. The important part is always seeking feedback so you can tell the difference).

I also don't think I really managed to accurately convey of my ideas with the possible exception of the fisherman and the moon, because it was dead simple (an interesting note: Henrik correctly cottoned on that I had been thinking of Hemingway's The Old Man and the Sea. Nobody, however, managed to pick up the loose parallels to Terry Pratchett's Nation.)

So, hm. I suppose all of this adds up to the fact that I would have preferred a more open pitching session - something with a little more trading of ideas, and less fully-formed concepts coming from each individual. This point, of course, is moot, because that process will inevitably take place over the semester as development progresses.

My thoughts on the whole thing, anyway. I think we're doing pretty well though.

Game Concept 5 - The Fisherman and the Moon

Just after dusk in a peaceful oceanside village. Out on the water where the sheltered bay meets the wider sea, the fisherman hauls in his last catch of the day. There is a heavy storm lurking on the horizon, and he wants to be back home and dry before it hits.

Knee-deep in slippery silver bodies, he reaches for his oars - and to his dismay, finds them missing! Frantically, he casts about in the boat for them, but they are nowhere to be seen. They must, he thinks, have slipped out of the oarlocks and overboard while he was busy pulling in the nets. He reaches over the sides of the boat, in a vain attempt to paddle back to shore with his hands, but with the weight of the fish, he can't even budge it.

The storm is encroaching at a frightening pace now; the fisherman can see high, white-capped waves rolling towards him. With no practical solution in sight, he looks up at the moon and utters a soft, crooning, sing-song prayer for safety. To his surprise, his prayer is heard - the moon seems to drift coyly a little closer, and he feels the unmistakeable surge of the tide beneath his boat. He laughs and sings the soft, lilting prayer again - and the tide pulls stronger.

Delighted, he calls to the moon, flattering and praising her. She gets closer and closer and now the tide becomes wild and uncontrolled, and he is sent sprawling back onto the pile of fish in his boat, on the verge of capsizing. He flushes with anger and changes his tune in an instant, yelling vulgarities and cursing her carelessness. She backs away into the sky and after a moment, the water is dead still.

The fisherman, however, is still far out from the shore, and the oncoming storm is closer and more threatening than ever. Overcome with penitence, he lowers his voice again and murmurs his apologies to the moon, drawing her back. Again, she comes too close, and again he sends her away - but his boat is now a little closer to shore. The fisherman smiles - he knows what to do now.

After an alternating sequence of soft, gentle cajoling, and violent screaming anger, the fisherman, exhausted, manages at last to bring his boat ashore, hauling it up with its precious silvery load onto the shore just as the first drops of rain strike on the sand. He gives his thanks to the moon and unloads the fish into a wooden bucket - and much to his surprise, nestled lengthways in the bottom of his boat, are the two mysterious disappearing oars.

With one last screaming curse, he makes his way up the hill in the pouring rain.

Game Concept 4 - You're in a box

You're in a box. A glass box. It's not much bigger than a person. You can move a little in the box - back and forth, bumping against the glass. The glass is so thick and heavy, the box doesn't budge. Outside the box, there's a breathtakingly beautiful world. You can see it, but you can't reach it, you can't hear it. You have to get there. You have to get out of the box.

You hurl yourself against the glass. You punch and kick and beat your head against it, to no avail. The box doesn't even move. You don't even leave a mark on the glass. Maybe you slump against the wall now - fall down, sob a little. You want to get out but you can't. You can't reach this beautiful world that seems just a hand's breadth away.

You get mad. Mad like a captive animal. You know no-one can hear you in here, but you have to get it out, and you scream. Loud and long and visceral and the more you yell, the more you want to yell. You are so caught up in the noise and the rage that you don't notice the box vibrating with the volume - at least, until it shatters.

The glass goes everywhere, bursting outwards away from you. You cower a moment in the wreckage as the pieces rain down around you.

When you look up, you aren't standing where you expected to be. You aren't standing in that sublime world that surrounded the box. But you can still see it. It's ahead of you, and above. In a blind fervour, you leap towards it, and tumble into space. You fall, surely to your doom. But the horrible sensation of the free-fall is broken surprisingly quickly as you crash land... into the wreckage of the box. You don't know how you got to be above it, but you're thankful for the absence of a grisly death.

Out in the empty space between you and the beautiful world, there are more boxes and other glass contrivances of all shapes and colours and sizes - drifting gently from side to side in an invisible aether, and all of them too far for you to reach easily. Infuriated again, you swear out loud; to your surprise, some of the boxes pop and shatter into a powdery mist. New ones coalesce from the pieces, and you are in luck: some of these are close enough to leap onto.

You step lightly from one glass creation to another, and happily begin humming a little tune. At the sound of your voice, the bridge beneath you collapses into nothing and re-condenses as a large Klein bottle, further up. With a gasp that causes an effigy of a kitten to shatter and shift downwards into a jellyfish, you manage to catch onto the rim of a passing bowl and haul yourself to relative safety.

You've figured it out, now - it's the sound that does it (took you long enough). Different pitches affect different coloured objects, and the volume dictates where they move in the space. Happily, and with more than a little trial-and-error and occasional dramatic falls, you make your way upwards and forwards, singing, whistling, yelling and cajoling the objects into position.

The beautiful, exquisite world is in reach. You can hear the sounds, taste the air. You step forwards off your last glass elevator and... bump into a wall. Startled, you stumble backwards - and bump into a wall.

You're in a box.


Mirror's Edge DLC, for visual reference.

Game Concept 3 - Hyperacusis

Disclaimer: I firmly believe this concept is too ambitious for this project year, and will in all likelihood not be pitching it because I won't have time in my pitch, but I wanted to put it up here anyway.

Working Title: Hyperacusis

Genre: First-person puzzle/adventure (somewhere between Myst and Half-Life?)

Platform: Unity Web/PC

First-person, 3D

Core concept/s:

• imagine any first-person shooting game that involves killing hostile or dangerous aliens
  
• what if you couldn't see them, couldn't touch them, didn't know how to hurt them - because all they are is a sound?
  

Environment:

• either a desert or an arctic environment - an open space the player can explore with some signs of civilisation

• the player's "home base" is a research station of some variety (more than a little generic, there) where they return to replenish their health etc

• the whole area is completely abandoned and devoid of life

• the only signs of people are abandoned belongings and homes, and the occasional corpse for good measure
  

Objective:

• the player is alone in the environment, which they have to explore at first

• they will come across non-corporeal 'sound creatures' who are embodied by noises which are severely harming to the player character

• the player must explore, find items, and progressively discover how to destroy the sound creatures

• overall goal is to wipe them out completely from the gameplay area
  

Gameplay:

• there are a variety of different sound creatures in the area, which have different effects on the player character and different weaknesess the player can exploit

• the creatures are limited to different 'zones' - most of them do not move around, so the player can remember their locations

• when the player enters the zone around a creature, they will first hear a warning sound that indicates an enemy is nearby (eg/ a high-pitched, grating whine). The nature of this sound may give a clue as to the sound generated by the creature

• when the character is exposed to a creature, s/he loses health and the player may not be able to fully control the character's movement

• the creatures can only be defeated with sound

• the character's main 'weapon' is a handheld sound recorder and playback device

• at the research station, the character has a very simple interface to be able to record and mix sounds from elements in the environment

• the correct combinations of sound played back at the creature will destroy it

• when a creature is destroyed, the zone it inhabited becomes completely 'dead': there is no atmos, and any player-character created sounds are almost inaudible - as if the creature sucked the sound out of the area as it died
  

Other mechanics:

• initially, the only item the player has is a pair of earmuffs. These cut out the sound of the creature and reduce the health loss experienced by the player character

• however, they inhibit the player's ability to respond to the creature - the sounds the creatures make are cyclic and pulsing in nature, and the player must record starting on a pulse, or the recording will be useless

• the earmuffs can only be used to allow the player to explore some areas in relative safety - however, they are completely ineffectual against some of the more powerful creatures, who can pierce through them
  

Obstacles/game elements:

• some creatures can be temporarily stopped by the character making noise (stomping, clapping, vocalising), but this will not destroy them
  

• some creatures can be destroyed simply by being played back at themselves (a more extreme version of holding up a mirror to an animal to make it aggressive)

• others are not so simple

• for some, the sound must be manipulated in some fashion

• for others, the sound cannot be properly recorded, and must be synthesized using elements from the environment, character vocalisations etc

• the way the player character responds to the sound can be a clue about how to defeat it

Examples:

• if the character becomes hyperactive and frantic (camera shake, over- sensitivy to controls), the sound needs to be slowed down to defeat the creature

• if the character becomes slow and dull (blurring vision, reduced sensitivy to controls), the sound needs to be sped up to defeat the creature

• if the character becomes disoriented (inverted controls), the sound needs to be played backwards to defeat the creature
  

Sound:

• Obviously the entire premise of the game is based around the use of sound and the player learning how to respond to sound instead of visuals

• there would be no background music - the soundscape would be comprised of atmos and ambient noise

• no animal or human sounds except the player and things left behind by the researchers to add to the story and mood
  

Other visual elements:

• obviously this would require some more complex first-person character animations

• however, the environment and animations could be simplified to be more stylised

• since the use of sound in the game is not entirely realistic or physically accurate, the player may be more inclined to accept less realistic graphics - though this may detract from the strangeness of the situation with which the player is faced
  

Potential problems/other issues of interest:

• There are so many problems with this idea like you would not believe

• As mentioned, the project is far too ambitious for the time allowed

• I think the core concept is solid but I am not happy with the specifics of gameplay - they seem both lacking and overly contrived

• the concept of the earmuffs to allow the player to move around in a less inhibited way is good, but doesn't cohere well with the other ideas about recording/playback
  

• earmuffs could be replaced with simply the character putting their hands over their ears - during which, of course, they can't perform any other actions except movement through the environment

• also toyed with the idea of a sinewave generator, with the player trying to match the core frequency of the creature - possibility of finding multiple 'weapons' as in a traditional FPS
  

I really like the idea, but it needs a LOT of work, both conceptually and for execution.

Game Concept 2 - Chiaroscuro

Working Title: Chiaroscuro

Genre: Puzzle/adventure

Platform: Unity Web/PC

Third-person, 3D

Core concept/s:

• the darkness is safe - be afraid of the light

Environment:

• the game takes place in a constructed environment (a series of caverns, chambers, hallways etc - possible a castle or an underground network of passageways. Think Prince of Persia: Sands of Time plus Ico plus a twisty maze of passages all alike)

• Environment should feel abandoned/ancient (stone walls and floor - partially ruined?)

• level design is linear or ocassionally branching without being an actual maze - the player should not get lost, turned around, or returned to the beginning

• the base state of the environment is pitch-black and unlit

Objective:

• the player must navigate obstacles from one end of the level to the other
• ideally, there is an overarching loose narrative and a series of levels that the player can navigate sequentially (pretty standard stuff)

Gameplay:

• the player character shows up as a bright figure in the darkness, but casts no light

• the character is able to draw the darkness into him/herself and expel it again at will, giving the player control over the illumination of the environment

• the game is a mostly-linear movement puzzle - the player must successfully navigate the environment by carefully controlling the levels of light and darkness

I envision the character control scheme to be similar to that of Sands of Time - much less jumping and less need for precision from the player, but the pacing of the character's climbing and walking could be similar.

• there are monsters/enemies lurking about - in the darkness, they cannot hurt the character, but the stronger the light is, the more dangerous they are

Sort of like the inverse of the shadow creatures in Ico - kind of fey and strange and wispy, but formed of bright light instead of darkness.

• when the character is hurt by a monster, they either lose health (standard health/lives system) or are returned to a previous checkpoint
  

• in order to navigate the environment, the player may be forced to draw in all the darkness, bright illuminating the space, as some environmental elements will only be fully corporeal in full light

• conversely, some objects will only by fully corporeal in darkness (bridges, ledges etc)

• some obstacles/path blockages will only disappear in darkness; some only in light

Other mechanics:

• There are a few possible ways to handle the monsters - either the character has no offensive capabilities and is forced to run from them (survival), or the character can destroy them, but either there is a limit to the number of times they can do so, or the monsters quickly regenerate after being destroyed

• the overall game should not have a time limit, but will be elements that require quick thinking (the old breakable ledge trick and variations)

• elements that are corporeal in different light levels will be shown as translucent when not solid

• the light levels needed to solidify any single element will be shown by the colour of the element (eg you draw the darkness away from a translucent black bridge and note its position, then walk across it in the dark)

• the light levels required should not be overly precise (three to four key light levels from dark to light)
  

Obstacles/game elements:

• elements that drain the darkness out of the character back into the world
• elements that block the character from expelling darkness
• elements that reverse the dark-absorbing effect
• elements that only allow the character to go between extremes (full light or full dark)
• sources of light outside of the characters control (eg moonlight)
• sources of light that the character has limited control over (eg. drawing darkness from and illuminating the far end of a corridor to cover a torch beside the character

Sound:

• no tunes - semi-musical ambient sound
• sound feedback for the game is important, since so much of it can potentially take place in darkness
  
• character footsteps (or whatever noise the character makes, if not humanoid) can change according to surface, to give clues about where the character is standing - the floor may have a different sound at the edge of an abyss to warn the player
• there is a warning sound when there are monsters/enemies around - so that the player knows what to expect if s/he draws in the darkness
  

Other visual elements:

• The enemies/monsters should be bright and beautiful, but somehow slightly wrong and threatening (thematically, similar to the Weeping Angels in the Dr Who episode 'Blink')

• The character does not need to be humanoid

Although clearly the initial sketchy design I have of the character is heavily influenced by Yorda from Ico - she doesn't cast light, but seems to be self-illuminated and shows up brightly in the game's darker environments.

Potential problems/other issues of interest:

• this does require a sense of some kind of story, even if only a very loose or simple one, to tie it together

• the story may or may not necessarily need to be fully presented to the player
  

• the visual ideas for the environment are not totally clear at this point - this requires a good deal more thought and design

• again, because the levels cannot be generated and there is probably a story, this is not necessarily a game that could be 'finished' in the project time available - possibly a condensed or simplified short game could be completed instead

• control scheme needs to be clarified - how does the player control the darkness (mouse wheel scrolling, perhaps?)

• it's difficult to say how hard this system would be to code

Game Concept 1 - Threadsuns

Okay, here goes. This is the first of three game concepts I have thought of that I will potentially be able to pitch in class on Wednesday 10. For some modicum of clarity, I'll try to describe them in dot points. Pictures will be added when I have made some.

Working Title: Threadsuns

Genre: Puzzle

Platform: Unity Web/PC

First-person, 3D

Core concepts:

• the player is disembodied, and has no apparent physical presence in the game world
• there is no fixed orientation in the 3D space; orientation changes as the player moves around the world

Environment:

• the game takes place in a grey-white void filled with 'suns': glowing orbs that float in the space like stars

• the player has a full 360 degree view around them on the X-axis and 90-degrees up and down on the Y-axis

• (alternatively, the player has a full 360 degree view around them in all directions, but has the ability to lock-off the view temporarily to move and re-center the mouse within it. This version is more of a mindfuck)

EDIT: A better version: The player has a fulle 360 degree view in all directions, but they click and drag on the screen to rotate the first-person camera and move the viewport.

Objective:

• there is a goal point somewhere in the space (a planet or similar), which is visually distinct from other elements
• the player has an object (the package) that they have to deliver from the level's starting point to the goal

Gameplay:

• the 'suns' form gameplay nodes. The player's viewpoint is always situated over a node

• the player can travel between nodes via a 'thread' drawn from one to the next

• the player can pull a thread out from the current node and either place a new node in the world or connect to a pre-existing node

• threads have a fixed length, but the new node can be placed anywhere in the players viewport (as long as not prohibited by another game mechanic)

• when the player travels to a new node, the view will re-orient so that the newly created thread is directly behind the player on a horizontal plane (perhaps this should eventually be that it re-orients to the view that best encompasses the path behind them)

• the current orientation is shown with a skybox that is darker at the bottom than the top

• the player can draw an adjacent thread back into the current node to erase the path

• there is a limit to the number of new nodes that can be produced from a pre-existing node

• the aim is to create a pathway that the package can travel along from the starting node to the planet

• the package will only move when there is an unbroken path that leads all the way from the starting node to the planet

Other mechanics:

• levels with pre-existing networks that have to be erased to limit the package to a single path

• levels with fixed networks where the package has a specific movement pattern that the player can exploit (eg. the package will always go left at a fork in the path)

• different coloured nodes with individual attributes such as specific thread length, different limits on the number of nodes that can be created from it

• multiple packages with different attributes (eg. a red package that cannot travel through across blue nodes)

Obstacles/game elements:

• 'black suns' that suck in nodes and destroy the path

• areas that the player cannot travel through
• areas that the package cannot travel through
• areas that threads cannot be drawn through
• eddies that shift nodes and/or threads
• teleport points

Sound:

• all sound effects in the game would ideally be musical and harmonic, with an underscoring ambient atmos effect, so that the SFX accompanying actions taken in-game create an ambient soundscape

• audio feedback about obstructions could be included as dissonant sounds, to cue the player to look around for the obstacle

Other visual elements:

• the void can be filled with weird and wonderful visuals that add to the ambience, such as clouds of gas or vapour, strange creatures or symbols ghosting out of the background

I am particularly thinking along the lines of Steve Ditko's work on the original Dr Strange comics - unusual organic shapes, that could be incorporated into the gameplay.




I think these images give a really good feel for the sense of disorientation in a 3D space and the lack of easily identifiable absolute directions.

Potential problems/other issues of interest:

• until the game is prototyped there is no way of knowing how well the player will deal with the sense of disorientation and constant re-location that forms the core of the game (it may turn out to be simply too difficult)

• how to teach the player the mechanics - should they learn by exploring? Should there be a series of tutorials at the beginning of the game to help the player?

• what is the interface for placing nodes?

• is there a classic fixed GUI, or a dynamic one, or simply appropriate in-game indicators?

• will the player need/want an overarching story or can the game simply be surreal verging on abstract?

• the levels need to be designed (to attempt to randomly generate something this complex would be a horrible coding nightmare)

• consequently, how much content can be generated for this game?

Presumably, with the time and people available, the final product would be a one-level demo of the concept and gameplay.

Furst

Oh hi thar,

This is a blog where I will be documenting and keeping track of my 3rd year Games Design degree project/s. So far there's not much to say, since the nature of the projects are still nebulous, but over the next week I will be posting and refining the game concepts I want to pitch in class.

Next post: some possible core gameplay mechanics.