GAMBIT: Projects: Sophocles

On the design scene, we've taken a step back from trying to find a suitable scenario for our game to trying to pin down exactly what we want, because it's imperative that our game's design reflects and channels exactly the message we want. What exactly is the fate we want to convey? Do we want to focus more on fate as depicted in Oedipus, or fate on a wide, general scale? Doris and Abe seem to want the player to ponder the same questions after playing the game as after reading the play. These questions include: what if Oedipus had killed himself after hearing the prophecy? Wouldn't he have them avoided his fate? What emotions should we feel towards Oedipus? Should we pity him, or scorn him? Is it a person's fate that defines them, or the path they take to reach that fate?

My initial intuition was this: it must be the path, and only the path. If Oedipus is going to kill his father no matter what, then how can we blame him? How can we make any statement about his personality or his character, if nothing he does can alter his fate? It must be the journey that defines the person then. If Oedipus were to hear the prophecy and respond with a "bring it on! Where's my father??", then we should scorn him. How can you kill your father just because some random person told you it was "fate"? Whereas if Oedipus did his utmost best to avoid it (which is in my opinion exactly what he did--he even ran away from his "parents" and severed ties with them completely so that he would never hurt them), and deserves pity, and even perhaps respect. Oedipus's only source of shame should be that he wouldn't take the advice of others and stop trying to uncover the truth, and also that he began to lash out at people unjustly in his rage. But sleeping with his mother and killing his father...it was inevitable, and horrible as the act was, I don't see Oedipus as any worse of a person for having accidentally committed it.  He did the best he could to avoid the atrocity.

But wait a second! I'm not taking into account that Oedipus's fate is specific to him only and no one else. We can't take any random person off the street, put them in Oedipus's exact situation at birth(imagine that...), and  expect them to end up killing their father and bedding their mother. Such a statement would only be true for a person with the precise personality and temperament of Oedipus. Oedipus's fate, by its very nature, does take into account his personality, because they determine his actions. That's where things get a little muddled. Does this mean that, simply by being who he is, Oedipus is responsible for his fate? At the same time, just because a person has a personality very similar to Oedipus doesn't mean he is likely to do what Oedipus did. What does it all mean anyways?

Abe and Doris think that an intriguing question is: what if Oedipus tried to kill himself? Would his sword have slipped from his hands and somehow fallen into his dad? (I'm not even going to try to explain the part with his mother.) They believe, that by the nature of fate, yes. They want to make a game where, no matter what the player does, he loses. But fate is not quite like that. Oedipus doesn't know that his fate is inevitable, only that others claim it to be; thus he behaves differently. Furthermore, Oedipus only gets one "play-through". He only gets one shot at his game. I might argue that there was only one possibility for the way things turned out, and that was the way in the play; there is no comparison here to a player playing through the game multiple times, because Oedipus has no second chance. Oedipus couldn't have tried to kill himself with his sword. That possibility isn't even worth considering. If we took him brainwashed him and took him back in time, he would probably behave precisely the same way. Imagine if you were told by a reliable fortune teller that you would kill your family. You probably wouldn't kill yourself. On his first play-through, it is inconceivable that Oedipus would have killed himself. It is similarly inconceivable for the most part, that Oedipus would have made any decisions differently from those in the play. After all, he is Oedipus!

What would be really phenomenal is if we made a game so that the player loses not because of the information we've provided the player, but because of the player's own mindset and mental conditioning. There might even be ways in which the player could have won, and they can see these for themselves by replaying the game. Yet the player couldn't have won, simply because it is inconceivable that the player would make the necessary choices on the first play-through, in the same way that it is inconceivable that Oedipus might have committed suicide, or done anything other than the set of actions that led him to his fate. Then the game, in some ways, would truly embody and model "fate."

There are, of course, many problems to this. Because playing a game is not quite as the same as living a life, players could simply choose randomly, and a certain proportion of them would win. (whereas in real life, people rarely make their decisions randomly) Doris argues that this would not be fate, and I suppose she's right. That brings up an interesting question: if Oedipus had been truly random in each of his decisions, could fate have still kept him trapped within its invisible clutches? Or would Oedipus's directions not have been truly random? If we had brainwashed Oedipus and taken him back in time repeatedly, would he have made the same "random" decision each time? Probably. But all that proves is that people can't be truly random. I feel that practicing true randomness in one's decision releases one from fate's clutches, although it could leave the practitioner with a rather screwed-up life... In which case, we can accept that players using a random number generator to play the game should have a chance at winning.

By now, I've wandered way astray from where the rest of my team are. But this should give you an idea of how difficult it is to construct a game around this particular topic. Modeling a game after "addiction" (see: Akrasia) is, I think, substantially easier than modeling it on fate, because addiction carries with it far fewer paradoxes and conundrums than fate. For that very reason, this project is far more interesting, and I enjoy it immensely.

Hope everyone enjoys the holiday.

Mark

Mark here! Still plodding along through tutorial after Flex tutorial, trying to amass the skills needed to generate digital prototypes quickly once our project reaches that stage. I finished the article series I had been working on for the past week, which culminated in a shooter that was very short, but had all the basic elements of a full-fledged game.  The game, in case anyone is interested, can be found here:

http://www.brighthub.com/hubfolio/matthew-casperson/media/p/49540.aspx

While not very satisfying in its current form, the code's excellent organization allows for easy extension and addition of features like health bars and such, in case anyone is interested in building it up. I probably would if I had any spare time. It's a neat exercise in creativity, trying to make as fresh and novel a game as you can from one whose framework has already been set. Sounds like a good idea for a competition in game design.

But I'm done with that tutorial now, and the programming leader has revealed the next step to my crash course in Flex: a game engine called PushButton Engine (here: http://pushbuttonengine.com/). This engine had already been evaluated by one of my colleagues here at the Lab, who judged that it was very powerful, but that the documentation was horrendously lacking. From my short experience with it so far I am inclined to agree with him. There is barely anything in the way of tutorials, and the tutorials themselves just give you snippets of code without really explaining what's going on. The engine itself seems quite intriguing! Unfortunately, there's no quick way to gain insight on how it works. I will continue to investigate it.

Nevertheless, I've been having a lot of fun.  If time permits, I plan to program a very short game in one of these engines (likely PushButton) and evaluate how my experience differs from those while programming under Java (which is my first language) It will be a great exploratory experience.

That's what's happening on the programming scene.

Mark

Directive: Decelerate.

We seem to have gotten somewhat ahead of ourselves.  We have a million different design ideas but no clear guiding principle from which to work.  Shame on us...  That was one of the first things I learned at the September Boston Postmortem on game design.  It was #1 on the list of RIT's (Really Important Things) of Game Design from a panel of Boston's most prominent game designers.  I even have it written down in the little black notebook I carry everywhere: "Project goal/vision".

So we need to go back and think about what it is we are really going for.  The primary question seems to be, "What version of Fate are we trying to convey here?"  There are several that I can think of off the top of my head.  There is Fate as a self-fulfilling prophesy.  In this style, one does something because they are told to, and is really a kind of psychological interpretation, as in, I could do all these other things, but I am doing it this way because the prophesy colors everything I see and makes it impossible or difficult to do anything else.  I have never seen Se7en (it's on the list) but from what I hear it is like this.

There is the interpretation that Fate orders everything you must do, in effect creating a kind of rail that you must traverse.  In this interpretation, Fate not only tells you what you must do, but how you must do it.  So Oedipus had to marry his father and kill his mother in just the way he did.  If you think about it, almost any narrative-based game works like this.  You go where you go and do what you do because the game tells you you have to.  Example, FFVII, where you always start in Midgar fighting Shinra, find out about Sephiroth, blah blah blah.  This really works for the Final Fantasy series because the narrative is so well crafted, but personally, for a game about Fate, I think this would be a pretty bland interpretation to follow.  It may be the easiest, however, and for that reason, may be the one we end up going with, if we can do it well, if we can make that ride on a rail meaningful, with the goal of inspiring questions about Fate and Free Will.

Finally, there is a much more organic interpretation of Fate.  In this interpretation, you are Fated to do some deed, or you actions have some kind of fated consequences, but the how of it is left up to your imagination.  I imagine it as being two points, and your path before, after, and in between is completely up to you as long as you go between the two points.  It is here that the really interesting procedural properties of video games can really shine.  As an example, carry out the story of Oedipus.  Now what would have happened if Oedipus had tried to kill himself?  Perhaps he would have slipped on a stone and killed his father somehow anyway.  What if he embraced his fate and became some sort of atrocity-loving psychopath?  What if he said, "Hell yeah, Delphi!  Let's get it on!"  In all cases, his journey is different, but the outcome is the same.  Interestingly, upon asking ourselves these very same kinds of questions, we realized that Oedipus was not fated to do anything during the time in which Oedipus Rex takes place.  He was not fated to find out about his deeds - so his path after the fulfillment of the prophecy could have been different.  So as designers we are given different paths both before the prophecy and after it!  So many opportunities for the player to play things through and explore different options!  Hurray for using procedurality!  Not to make this sound easy though, taking this path will require some genius.  How do we do it abstractly?  Can we do it without just combining 3 different rail games into one (take your pick of rails!)?  Yikes!  Can of worms!

So I guess it is partially going to come down to what the team (and particularly, Abe and Doris our esteemed project owners) wants to say with fate.  Until then, I'll be playing with Game Maker 7 as a rapid prototyping tool and revising our project schedule for this latest directive: decelerate.

Producer out.

We seem to be focusing more on coming up with a secret that we keep away from the player, feeding them only small clues. The player will reach the end and the surprise, and then be like "ahhhh, so that's what all that stuff before meant. How did I not see that?"

            I don't know if I like this direction, because then the player might only play through the game once or twice. There's no sense of being able to outmaneuver fate or the game. Maybe we can tune it so that we can still have this element of strategy and apparent freedom, although such an element is probably the hardest to incorporate.

 

            Here are a couple more random ideas from me:

 

            You are shrouded in darkness, and there is a faint beam of light coming from the top of the screen. Little machine parts start drifting down, and you start piecing them together to assemble a machine, whose purpose is to lift you up towards upwards. Depending on how high your machine reaches (it is constrained by fuel), more machine parts fall down. Eventually, you reach the very top. Then, you see a giant mechanical beast that was secreting the machine parts down into the darkness. It lunges towards you and eats you.

           

            Well, that's not good. What's the point in playing the game if you're just going to get eaten at the end?

 

            But hopefully we can make the game so that the player, even while his main purpose is to get altitude, can also use the parts that are falling from the machine above to make weapons to fight off the beast. Maybe we can put an HP bar over the beast to SUGGEST that it can be defeated. Maybe at the very end, we show safe-looking place like an altar or something far off in the distance, which suggests to the player that it is possible to evade the beast and reach the altar. The player might then try to not go all the way up to where the beast is until he has so many resources and so much fuel that, when he does reach the altitude where the beast lies in wait for him, he will still have plenty more fuel with which to flee.

 

            Of course, we can easily still contrive it so that the player still loses. But at least this way, the player has some hope of winning. There are many ways to adjust this story. Maybe the machine parts that were released by the beast have a tracking system, or even break down once they have brought the player within feeding range.

 

            This scenario does require that the player be a character on the screen though. Most of the team seems to like the idea that YOU are Oedipus, not some character on screen that you control and channel your emotions into, because the connection between the player and the scenario in the game may be weaker.

 

            Until next time.

 

            Mark Zhang

Hey all!

I've spent most of this week learning how to program in Flash by going through a great tutorial that takes you through the process of making a simple shooter step by step. So I now know of one approach to organizing and constructing the game engine, as well as how to how to embed images, make a scrolling background, take user mouse input, etc. This tutorial is the optimal resource for me because it focuses narrowly on game programming, and I need to learn all the techniques involved with that swiftly.

For one thing, I was impressed that Flash had native support for gamestates, making it that much more convenient for the programmer. You enter code like this:

<mx:states>

<mx:State

name="Game"

enterState="enterGame(event)"

exitState="exitGame(event)">

</mx:State>

<mx:State name="MainMenu">

<mx:AddChild relativeTo="{myCanvas}" position="lastChild">

<mx:Button x="525" y="368" label="Start" id="btnStart" click="startGameClicked(event)"/>

</mx:AddChild>

</mx:State>

</mx:states>

What this does is first specify that you're going to be defining states with <mx:states>. Then you enumerate all of the states in your game, enclosing each in a <mx:State> </mx:State> tag. You can do things like specify what to do when you first enter and leave the state. To switch gamestates, you just need to change the currentState variable of the application (currentState = "Game"), and everything else, including the throwing of the enterstate event, is handled by Flex. When it is a certain gamestate, the application will display all the GUI elements listed within the State tags (like all the buttons) on the screen. This really facilitates GUI transitions, among other things, as you can change GUI schemes with one change in variable.

 

 

            Another nice thing I've discovered in this tutorial is resource pooling, which I find to be a neat solution to some of the problems in memory management.

When a program is run, it creates a bunch of objects. When these objects are no longer needed by the program, they should be destroyed so that the memory they occupy can be regained. If this is not done, then, for example, when a player fires many many bullets during the course of a shooting game, there will eventually be a large and unnecessary burden on computer memory.

In languages like C, the programmer had to destroy each object manually. If he missed one, then a "memory leak" would occur, and the program would use progressively more memory. In more advanced languages, garbage collectors performed this task automatically, in the background as the program ran. However, garbage collectors could slow down a program, because the garbage collector has to check each object currently in existence to see if it is still in use, and destroy the ones that are obsolete. Flex does employ a garbage collector.

However, there is a trick we can use to make garbage collectors run much more efficiently. We can create a resource pool. The resource pool is a class that takes a function which defines how a specific instance of the pool should create its objects. If we want to make a pool for Weapons, we pass a method to the pool that returns a Weapon object. Then, each time we want to make a Weapon object, we instead ask the pool for one. If the pool has a Weapon object in its storage, it gives it to up. We can then change the variables of the Weapon object to suit our purposes. Only if the pool does not have a weapon in storage will it make a new one. Every time a weapon has fallen out of use, it is returned to the pool and waits for another method request.

I'm not totally sure how this helps the situation, in terms of memory management. Say you hold down the shoot button continuously, and a maximum of 20 bullets can appear on the screen at once. Then the pool will have 20 objects in its stores, and the garbage collector will have to constantly check these objects to see if any are not in use. Even if the player no longer shoots, these 20 objects will still exist (because the pool never lets go of an object once it's created) and the collector will still have to cycle through these. Whereas if there was no pool, the 20 bullets would be eaten up by the collector after they went off the screen, and then the collector could relax. Maybe the solution lies in how the garbage collector is implemented; maybe if an object is in an arraycollection, the collector doesn't even consider it or something. In any case, resource pooling does keep the program from needing to make too many objects, which does make the program more streamlined. And this concept can probably be adapted to any number of languages.

Check back in a couple days for some more game ideas!

Mark

December.  The year is already fading into winter and design questions abound.  While the middle of the game has ideas flying around left and right, the real conundrum seems to be the inextricably linked beginning and end.  Questions like: What aspect of Fate are we trying to convey?  Are we implying that your efforts are futile and have no effect on the big picture?  Oedipus' story has had a very profound effect on us even 2500 some odd years later.  Of course, that's a rather human-centric view of history.  After all, we are but a mere blip in the history of the Earth, and less than that on the scale of the Universe.  What effect has Oedipus, or humans in general, had upon the Big Picture?  Does that now turn our game into some kind of Lovecraftian cosmic horror about the ancient and the unknown?  Are we trying to drive the player crazy with the vastness of space a la The Hitchhiker's Guide to the Galaxy?  These questions (and rarely their answers) are whirling all around us as we try to get a grip on what this game is supposed to mean.

So here's my stab at it.

The essence of Socrate's tragedy is the moment of Anagnoresis upon his discovery of his deeds.  Part of what drives this is the audience's knowledge of what is going to happen.  The audience represents Fate in this way, and the tragedy comes from watching Oedipus' self-destruction.  We can't do this in a video game because the audience, the player, is also the participant.  The player is Oedipus.  So Fate, instead of being manifested by outside knowledge, has to be designed into the gameplay.

The tricky part is that Oedipus was told his fate on numerous occasions.  So he was aware of his fate even as he was ignorant as to how (or even if) it would be carried out.  It seems that we are tasked with the problem of telling the player they are going to do something they don't want to, offering some escape, but ultimately designing the escape such that it accomplishes what the player did not want to do.  This would be easy to do in strictly narrative form by putting the player on a rail and watching them go, but we are seeking to use the structure and medium of the game, not the narrative.

The central problem comes down to this: How do you convey Fate in a medium in which the participant intrinsically has Free Will?  How do we make the player do something without them realizing we are doing it?  Almost makes me wish I were a psychology major...  Really, we have to trick the player.  We have to make the player look left while we go right (Kansas City Shuffle, anyone?).  The player has to think they are doing something because they want to, when really everything they've seen all along cues them to do so.  On second thought, maybe I should have been a magician.

Fortunately for us, the player has already been heavily conditioned to do certain things by years of playing other people's games.  So the key becomes to think of a way to blind the player with their own gamer instincts to accomplish that which they are running away from.

Producer out.

Today was a great brainstorming day. Our team met with another team and had a large storming session on ideas for Sophocles. The restrictions for the game were laid out first: The game must focus on the concept of a machine (smaller parts working together to form a whole), that the machine itself represents fate, and that the outcome is always the same no matter what changes or is played differently in the game. After the rules were laid out our two groups began listing out any ideas that came to mind. One that struck me was the concept that the player is fighting against a machine to rearrange pieces to correct something while the machine behind it is racing to convert them back to how they originally were. The trick is that the player is actually the one messing up the pieces because once he or she sees the pieces as a whole (step back from the whole thing), he or she realizes they were all a part of a larger image, and by rearranging them he or she was actually messing up the larger image.

On the art side of the project, today was the first step to creating the web site for the game. I managed to complete the drawing for the banner and choose a color study for the painting as well as theme for the site. Now all that's left to do for the banner (the largest part to designing the page) is to paint it, which will be done in watercolor with some mixed media for effects. The overall look is that of mechanics (gears) with a touch of organics and rust (Corrosion of metal) as the topping to the ice cream. The idea was to touch upon what has been mostly discussed or desired in the game while remaining general so that the website can still match or apply to the game no matter which direction we go.

I hope you enjoyed your Thanksgiving!  Here's Part 2 of my Game Ideas series...

Game Idea 2:

The scene fades in and there is a creature C perched on top of some object X which is in the clutches of a gigantic machine, the glistening infrastructure of which stretches off as far as the eye can see in every direction. The machine seems to be composed not only of the typical cogs and gears, but also of organic components like flowers, leaves, vines, and even things like hearts and eyes and blood vessels. The machine holds X in a claw and C is straining with all its might to pry open the claw and release its precious X. Off in the distance, there is a gigantic laser of some sort. As C watches in horror, a little creature much like itself, in a situation identical to itself, is carried under the laser by another claw. The laser pulses and both the creature and its precious object are vaporized.

C's eyes flare in determination. He launches himself from his perch and strikes out at a piece of the gigantic machine.

At this point, the player can choose what machine part he wants to start off with. He can choose between a variety of parts that are in view...more or less any of the basic parts available in the game are obtainable. In general:

Mechanical parts attack and move

Botanical parts defend

Visceral parts do a variety of specific things. For example, if you attach an eye to a missile, whenever the eye sees something in a certain range, the missile will fire. Hands might allow you to alter the gigantic machine itself.

Now the idea is this: In your panicked state, you see violence as the only answer. C (you, the player) will journey to various sections of the machine and try to mess  itup  to the point that it will no longer function and you can save your precious. Can you throw enough wrenches into the machine that it will grind into a halt, and save your precious?

SPOILER ALERT!!!!!

No. You can't.

As in all the ideas we are considering, the player must lose. Ideally, he will harbor some delusion that he can still beat the game if he tries harder and employs a better strategy (just as Oedipus believed that he could thwart fate if he was clever enough) So he will try again. Just letting you know though, there is no way the player can actually "win", although he can achieve different endings. It's okay for me to disclose this here because most players won't read the blog anyways. You are special.

END SPOILER!!!!

You also have a time limit, before the claw reaches the laser. The time limit might be around 30 minutes.

In each stage, a part of the machine will be revealed. There are two things the player can do here. The player can attack the machine. In this case, parts will fly off on successful attacks. The player can collect these parts and add them to the player machine. At first, the player will get a lot of parts, and feel overconfident like Oedipus that he is going to succeed. Later, the machine either gets so strong that more parts becomes less significant, or your machine is so complex and cramped that adding more parts won't really make it more powerful.

Once you have advanced visceral parts like hands, you can also alter the machine itself, to try to do even more damage to it and screw it up.

Between stages, you will have time to make modifications to your personal machine to make it more adept at fighting the big machine. You might be able to upgrade parts to more advanced ones. However, the time is still running during this period.

The big machine has access to all of the parts that you do (since it is the source for all of your parts in the first place) So hypothetically, it can do everything that you can. The machine in reality probably won't fight back too hard. Fate doesn't really care if you to try meddle with it (it won't matter; you'll lose), and the point isn't to make the game too hard, so that the player becomes more focused on the skill aspect of the game than on the message.

Also, there is no glittering message "STAGE CLEARED" A player must decide for himself when he has done enough damage to a stage, or when he has achieved what he had intended in it. The only confirmation from the machine is a WIN or LOSE at the end of the game.

There are so many directions we can go in this game. One idea of mine is to make it very complex (it already sounds kinda complex) because fate, after all, is mind-bogglingly complex and impossible for human minds to even wrap their minds around, let alone control.

As to the mechanics of controlling the machine, the idea is this. You can attach "controllers" to parts of the machine. For example, you can attach the C controller to a heart, so that every time you push C, the heart pumps, gives energy to other stuff. Or maybe you push A and a motor revs up and gears move and a bunch of missiles fire. It's kind of difficult to explain in words...But the point is that you can only push so many keys in a given span of time. Thus, it is in your best interest to have as many different parts of the machine powered by or controlled by the same part as you can, so there are a lot of design aspects to consider. Doris, the other supervisor on the team, said that she wants the player to have some satisfaction from assembling something and seeing all the parts work together perfectly. This is a way of simulating that feeling.

Mechanical parts might include gears and cogs and other objects that can transmit kinetic energy from one place (namely the controller) to another (the things that are going to fire). Maybe we'll have springs, engines, and all sorts of things. Missiles, mini-lasers.

Botanical parts might include giant flowers that shield from missiles, vines that hold things together, leaves that power the plant, stems for transmitting energy, etc.

Visceral parts are the most interesting, and can include eyes, hands, hearts, muscles for moving things, blood vessels for transmitting nutrients, etc.

It's possible that different classes of parts can interact with each other, although with less efficiency. Maybe hearts can power missiles, although not as well.

Lastly, Abe mentioned something about three gods of fate personified by the Greeks: Clotho, who spins the thread of life, Lachesis, who measures the thread, and Atropos, who severs it.

Here, the precious X could have a protective bubble around it, and the claw clamps onto that. The machine could be composed of 3 different parts of equal size: Clotho, Lachesis, and Atropos. Clotho is responsible for creating and maintaining the protective bubble. Lachesis powers and wields the claw. Atropos is the laser. The player can choose to target any one of these, or multiple ones, leading to even more choices and more complexity. The large selection of stages available to the player would then be divided between these three machines. Wrecking an area belonging to Clotho would damage Clotho.

Clotho would be composed more of botanical elements, being a protector.

Lachesis would be composed of more visceral elements, as the journey to the laser represents the time during which a man is "alive" and made of living flesh.

Atropos would be composed more of mechanical parts.

The player can also choose to one of these simply to gain more parts. Maybe the player really wants to target Atropos, but likes the playing style involved with using botanical parts. Then he would first target Clotho, get a bunch of parts, and then move onto Atropos.

There are many possible endings. One is just to have so many stages eventually appear that the player can't finish. Another is to make the machine so strong that eventually it can't be destroyed.

Or we COULD make it so that it IS possible to destroy the machines. But the player still loses, because:

If he destroys Clotho, the bubble  will pop, but the environment in the machine turns out to be hostile to precious X and it melts away.

If he destroys Lachesis, the claw disintegrates, but the X plummets down into the depths of the machine and is lost.

If he destroys Atropos, the entire machine explodes. As both C and X are inside the machine, they both die.

We can also group the stages up into different categories with different themes. For example, maybe there's one whose theme is "blindness", in an area where there isn't much light and the player has to attach giant glowing flowers to his machine to be able to see, while the machine has black bulbs that absorb the light and negate the action of the flowers. Maybe these sections can build on each other.

Okay, I'll stop here.

Comments: I like this idea a lot, and hope my team will give it their consideration. I'm a little sorry I don't have more time to do it justice; I rushed this description. I do realize it's a little too concrete though. There's too little room for multiple interpretations. I'll leave that decision up to you. There is definitely a lot of potential in this game to tie in whatever message or metaphor we please, as I hope I have demonstrated here in my extensions. One thing we have to be careful of is limiting our scope though, if we do end up pursuing this. This game can't be programmed in 10 weeks. Not even close. Too much stuff.

That's all for now!

Mark =)

               For our first brainstorming session, we were to focus on tasks that the machine in our game could try to accomplish, although we were free to explore tangents. 

Many of the concepts we brainstormed I thought would make great games in their own right, if only there was a team dedicated to flesh them out. Sadly, we are only one team, and we will pick only one idea to nurture into a game. Hopefully, we can get those other ideas posted sometime so that others might give them a chance to mature into a successful game.

Meanwhile, here are two game ideas which I developed by myself during the first week. Unfortunately, I don't feel as though they are what my team is looking for. There is a little too much narrative to them, and Abe wants the game to speak purely for itself through its mechanics and design. Maybe I'll make the games myself one day.

I will post these ideas in a two part series.

Game Idea 1:

A strange hyperintelligent creature of uncertain shape and form is terrified of death, even though he is still in his prime. He decides to thwart fate by constructing a machine that will destroy whatever force is fated to take his life, be it old age, disease, some physical threat, or some mystical reaper. The machine will do this by ripping the force clean out of the fabric of reality.

Now, clearly, destroying old age and disease and all that would do some pretty unpredictable things to the universe. In fact, it would probably end up blowing it up or something, and if we want to give the player more options, we might consider what happens if the player succeeds in eliminating one of these things.

However, in the scenario I envision, the player builds up a small preliminary part of the machine, and it churns and clanks and then informs the creature that the entity that will kill the creature is in fact of the same species as the creature itself. Not only this, but the entity kills the creature not accidentally, but through cold-blooded homicide.

The creature is furious, but also gleeful. Here was his chance to erase a twisted murderer from reality! And he is vengeful; how he hates murderers! How fearful and terrible death is, and how foul are murderers for spreading it, for being its missionaries! He wants this unknown murderer to suffer. The creature's ego also begins to swell. How brilliant he was! He had already seen the future, and that was only the beginning. Now he would play God.

So the game progresses and the player builds up the machine. As the machine grows in sophistication, it begins to perform different tasks with increased proficiency. These tasks involve debilitating the murderer, in ways like "make him feel pain", "make him colorblind", "make him lose his memories."

In the end, the machine is completed and it fires and it kills the creature who made it.

And while the game is progressing, though the creature does not explicitly say it, it is clear that he is the one who is losing color vision and memories (this could be done graphically by making the colors duller, etc.) and being crippled by the machine.

Comments: as I said, too much narrative for our purposes. I rather like the idea though, and it fits with our fate metaphor alright. I didn't really go far enough to map out exactly how the game mechanics would work. I imagine they would be similar to the next one I describe, since both games involve building up machines.

       Today was the first day the whole team was able to meet up and brainstorm. The session left us with some great ideas and helped get my concept powers flowing. I began the day by illustrating the first inspiration I had; a glowing moth creature. This came into mind when the idea of collecting a glowing substance (goo, fireflies, and light) as an objective was discussed.