(Original assignment not yet on the blog!)
Please answer the following questions:
- What elements of chance are you using in your game?
Dynamic level generation allows for a lot of chance, in terms of what enemies you end up going against, how many, in what order, etc. It also allows for random variance in how long the game is, the difficulty, the maps themselves, etc.
- Describe the skills used in your game, and their relationship to chance and probability
Most of the "skills" in the game just involve being cautious, avoiding and defeating enemies, etc. There's not too much chance interaction with that part of the game.
- What elements of your game are out of the gamer’s control?
The map layouts, which objects become enemies, etc.
- Can the player influence chance in some way?
Not under any of our current plans, no.
- Is there a way that the player can estimate his opponent’s (the computer) skill
Perhaps just through experience? The Computer in this case isn't meant to be skilled. The enemies act is a fairly mindless and straightforward manner, but the difficult comes from not being able to anticipate which objects are enemies until you are already being attacked.
- Estimate the probability of drawing a king of diamond AND an ace of spades from two full decks of cards (that are shuffled)
Assuming it's two "full" 52-card decks (no jokers) which have been shuffled together and then had two cards drawn one after another (without the first card being replaced before the 2nd draw), the odds are 4/104 that the first draw is one of the target cards, and then 2/103 that the second draw is the OTHER target card, for a total of 8/10712, or 1 in 1339.
- Throw three dice (with faces 1-6). What is the probability that the sum will be 10? 12? 14?
Assuming fair dice, etc. you get....
27/216 for a sum of 10,
25/216 for a sum of 12 ,
and 15/216 for a sum of 14.
RANDOM PICTURE!
Tuesday, November 9, 2010
Thursday, October 28, 2010
Game Design Homework 15
(see assignment here: http://fsugd.blogspot.com/2010/10/homework-15-status-of-your-game.html)
Our group is pretty diverse in background, which has lead to a very easy and straightforward division of labor. David has been working on modeling, Sam on music, and myself on coding. So far I've only got the beginning stages of code for the actual final game beginning to come together, but I've been experimenting heavily in what Blender and do throughout the class while working within the context of our homework assignments. As we've now covered some of the basics of python in class, I'm beginning to focus my efforts more in that direction.
My main focus for the immediate future is in the dynamic generation of level maps. I've been experimenting with generating objects in python, but have yet to make sufficient progress to be worth making a video of my results. My main goal for this weekend is to have a script for generating room layouts, to have something to show the group the next time we meet.
As for illustrations and videos, it's much simpler to please just refer to my earlier posts. In particular, the video for Homework 9 shows a game in which the basic controls and monster logic represent a very crude prototype for our game. From the point illustrated in that video, I've begun to figure out things such as appropriate scale for rooms and doorways, movement speeds, and values related to monster logic triggers. The results of this have yet to come together into a demonstrable product, but as I mentioned, hopefully by early next week I should have some basic level generation done which my group-mates will be able to review and critique.
I can't think of anything else to add that hasn't already been said to death, so here's a random picture to round off the post:
- In each of your blogs, please describe your contributions to your team’s game, and your use of blender.
- Illustrate your contributions with pictures, videos of your work, and descriptions.
- Make sure you talk of your own contributions.
Our group is pretty diverse in background, which has lead to a very easy and straightforward division of labor. David has been working on modeling, Sam on music, and myself on coding. So far I've only got the beginning stages of code for the actual final game beginning to come together, but I've been experimenting heavily in what Blender and do throughout the class while working within the context of our homework assignments. As we've now covered some of the basics of python in class, I'm beginning to focus my efforts more in that direction.
My main focus for the immediate future is in the dynamic generation of level maps. I've been experimenting with generating objects in python, but have yet to make sufficient progress to be worth making a video of my results. My main goal for this weekend is to have a script for generating room layouts, to have something to show the group the next time we meet.
As for illustrations and videos, it's much simpler to please just refer to my earlier posts. In particular, the video for Homework 9 shows a game in which the basic controls and monster logic represent a very crude prototype for our game. From the point illustrated in that video, I've begun to figure out things such as appropriate scale for rooms and doorways, movement speeds, and values related to monster logic triggers. The results of this have yet to come together into a demonstrable product, but as I mentioned, hopefully by early next week I should have some basic level generation done which my group-mates will be able to review and critique.
I can't think of anything else to add that hasn't already been said to death, so here's a random picture to round off the post:
Tuesday, October 26, 2010
Game Design Homework 14
(see assignment here: http://fsugd.blogspot.com/2010/10/homework-14-reality-is-state-of-mind.html)
- What about the real world is modeled by the game?
Simplified, but generally real-ish layouts of real rooms, realistic physics, lighting... do houses really get haunted?
- Give some ideas on how you will control the Challenges versus skill graph
As you travel through the mansion and visit more rooms and whatnot, more and more objects will become haunted, making the game more difficult as you progress. You will also find additional useful items further into the game, allowing for more choices in how you deal with situations, which should also help to keep the game from getting to monotonous or difficult.
- Where in the Maslow Hierarchy of Needs does your game lie?
Primarily we're appealing to the 2nd tier's need for safety/security by making a game in which the player is trapped and needs to fight for survival.
- List some of the objects of your games
Chars, tables, sofas, TVs, refrigerators, beds...
- For these objects, list their attributes For 5 attributes, create a state diagram (following pacman example)
The general state diagram for an enemy in our game looks something like...
- What is the space of your game? Discrete? Continuous? What is its dimension?
Continuous in 2D and semi-3D through limited jumping. Boundaries in the form of separate rooms, etc.
- Will players see all game data, or is some of it secret?
The information given to the player will be minimized. We hope to convey some useful information through sounds and things like lighting... but a lot will be left vague to increase suspense and fear.
- List some of the operational actions in your game
Movement (Forward, back, left, right, turning), Jump, Spring, Attack with whatever weapon, flashlight on/off
- List a few anticipated resultant actions in your game
Approaching objects slowly and backing off quickly to check if they're aggressive, Perhaps using the flashlight as a way of detecting haunting, if such a mechanism can be implemented (we're already having lighting troubles), fleeing through rooms already cleared to avoid angry enemies
- List some verbs that apply to your game
Run, jump, hit, rest, hide...
- List some rules for your game (you’ll change these later ..)
Laws of physics (don't walk through walls, can only jump so high, etc.), You can kill anything that can kill you, and visa-versa (and on the other hand, you can't destroy anything that's not a threat to you), you can only hurt The Potato with the Holy Peeler.
And with that, here's a nice picture of the box of one of the best games ever, that had a heavy influence upon my childhood:
Saturday, October 23, 2010
ALPACA FIESTA! YIP YIP!~
So tonight I wanted to show the class (or whatever other audience I may have) another project of mine. This is something I started on back in... I don't know, about January and worked on until about the beginning of March, but had set aside since then (Until tonight, that is). By itself, it's a mediocre clone of the game Bejeweled Blitz (which you can play for free on Facebook, check it out!), but there's a much deeper purpose, which is...
I'm constructing my own engine for building 2D, sprite-based games! It's written completely in C++, using SDL and... well... elbow grease. I'm intentionally reinventing the wheel here, I know, but this project is allowing me to do two key things. The main one, of course, is to familiarize myself with SDL and low-level game programing. The other one is to give me an engine that lets me do all the wonky stuff I want to do, like arbitrary sprite animations.
So far, I've got pretty solid code in place for some basic things; screen resizing, loading and displaying static sprites (currently only .bmp, but others are very simple to add at this point), building custom animations from any sequence of sprites... etc. The main things I'm lacking right now are a controlled mechanism for I/O (which is a simple matter... I just haven't had a need for it yet), and sound support, which should not be much harder, but I've yet to approach. The last big project I know I've got, and it's what I'm starting on next, is to rewrite my window handler to allow for sub-dividing the window into logical frames, and rewriting my sprite collision detection (Oh, I didn't mention that part, did I? Oops!) to work efficiently with those changes.
Yeah so, I don't really expect that to make any sense to anyone besides me... I'm too tired to write intelligibly, so instead, here's a gameplay video of Alpaca Fiesta. All you really need to get out of this is that I made it all myself (including the beautiful artwork), and that most of the code in it will be readily reusable for other games.
(Apparently my screencap software interacts poorly with SDL's method of fullscreening, so the screen size comes out oddly in the video. Sorry about that. I assure you that the game fills my entire screen from this end.)
I'm constructing my own engine for building 2D, sprite-based games! It's written completely in C++, using SDL and... well... elbow grease. I'm intentionally reinventing the wheel here, I know, but this project is allowing me to do two key things. The main one, of course, is to familiarize myself with SDL and low-level game programing. The other one is to give me an engine that lets me do all the wonky stuff I want to do, like arbitrary sprite animations.
So far, I've got pretty solid code in place for some basic things; screen resizing, loading and displaying static sprites (currently only .bmp, but others are very simple to add at this point), building custom animations from any sequence of sprites... etc. The main things I'm lacking right now are a controlled mechanism for I/O (which is a simple matter... I just haven't had a need for it yet), and sound support, which should not be much harder, but I've yet to approach. The last big project I know I've got, and it's what I'm starting on next, is to rewrite my window handler to allow for sub-dividing the window into logical frames, and rewriting my sprite collision detection (Oh, I didn't mention that part, did I? Oops!) to work efficiently with those changes.
Yeah so, I don't really expect that to make any sense to anyone besides me... I'm too tired to write intelligibly, so instead, here's a gameplay video of Alpaca Fiesta. All you really need to get out of this is that I made it all myself (including the beautiful artwork), and that most of the code in it will be readily reusable for other games.
(Apparently my screencap software interacts poorly with SDL's method of fullscreening, so the screen size comes out oddly in the video. Sorry about that. I assure you that the game fills my entire screen from this end.)
Tuesday, October 19, 2010
Game Design Homework 13 (aka: I don't have a good title for this one right now)
(see assignment here: http://fsugd.blogspot.com/2010/10/homework-13-iteration-and-players.html)
As is becoming my norm for text-heavy entries, here is a picture:
- What steps are members of your team taking to prototype the game?
- What could go wrong in your team’s game?
- Will men and women like your game equally? What could be done to enhance the game for one or the other gender?
- What would have to be done to your game to make it appealing to 15-18 year group. Same question for group between 40 and 50.
- What pleasures does your game provide to the players (Chapter 8)
- How are you applying the principles of iteration (chapter 7) to your game design? Each member should discuss his/her approach and contribution
- What are some changes that you “might” have to make to your game to improve it?
- What are you doing that “might” not work as expected?
- What are the characteristics/experiences/features that players will like and not like? What are your expectations from the players of your game?
As is becoming my norm for text-heavy entries, here is a picture:
Thursday, October 7, 2010
Game Design Homework 11 (aka: We're Animaniacs!!)
(see assignment here: http://fsugd.blogspot.com/2010/10/homework-11-animated.html)
For this assignment we worked with animation and armatures to make some stuffs move. While the animation itself is not too tricky, getting it to interact well with the physics and game engines is proving quite a hassle for me, and I don't have all the kinks worked out yet. I've got a chair that attacks in a manner similar to the TV, minus the electric bolts. If the chair bumps you it hurts you, etc. I've implemented a very crude animation such that the cushion on the chair looks vaguely like it's trying to eat you. Here's where the hassle comes in... When I run the animated chair by itself, it works out completely fine. When I pop it into the room through the spawner item, though, the cushion shows up in the wrong space. I think this is probably related to some type of situation where the data is misaligned with its layer's origin or the likes, but in over an hour of playing with it I've yet to solve the problem, and am presently out of time, so I'll fix it this weekend. For the sake of the assignment itself, though, the animation works when view by itself. Lack of time has kept me from preparing a video, but I'm sure the chair will be there in an improved state next week, and I'll stick a video up for that.
So yeah... not too much to see here, folks. Here's another random picture?
For this assignment we worked with animation and armatures to make some stuffs move. While the animation itself is not too tricky, getting it to interact well with the physics and game engines is proving quite a hassle for me, and I don't have all the kinks worked out yet. I've got a chair that attacks in a manner similar to the TV, minus the electric bolts. If the chair bumps you it hurts you, etc. I've implemented a very crude animation such that the cushion on the chair looks vaguely like it's trying to eat you. Here's where the hassle comes in... When I run the animated chair by itself, it works out completely fine. When I pop it into the room through the spawner item, though, the cushion shows up in the wrong space. I think this is probably related to some type of situation where the data is misaligned with its layer's origin or the likes, but in over an hour of playing with it I've yet to solve the problem, and am presently out of time, so I'll fix it this weekend. For the sake of the assignment itself, though, the animation works when view by itself. Lack of time has kept me from preparing a video, but I'm sure the chair will be there in an improved state next week, and I'll stick a video up for that.
So yeah... not too much to see here, folks. Here's another random picture?
Tuesday, October 5, 2010
Game Design Homework 10 (aka: Follow your themes, kid!)
(see assignment here: http://fsugd.blogspot.com/2010/09/homework-10-theme-party.html)
Haven't we covered most of this already? Ah well... let's do this.
Creepy music
Presenting the player with as little information as possible, to add to suspense
Sudden, unpredictable attacks by items
Disorienting layout of the map
Too much text today, hmm? Here's a random picture from my archives...
I need some shades like that.
Haven't we covered most of this already? Ah well... let's do this.
- What is the theme of your game?
- Name one experience from your own life that could be built into your team’s game
- How could you incorporate this idea into the game?
- Give 5 ways you are reinforcing your theme (or plan to reinforce the theme)
Creepy music
Presenting the player with as little information as possible, to add to suspense
Sudden, unpredictable attacks by items
Disorienting layout of the map
- View your game as the solution to a problem statement:
- What is your game’s problem statement?
- What are the constraints imposed by the problem statement?
Too much text today, hmm? Here's a random picture from my archives...
I need some shades like that.
Thursday, September 30, 2010
Game Design Homework 9 (aka: Heads up seven up!)
(see assignment here: http://fsugd.blogspot.com/2010/09/homework-9-hud-and-menu.html)
I don't think we actually have a name for our game yet? Anyway, the idea is that we start off with an external view of the mansion with some spooky stuff going on, and you can click on the door to enter start the game. Clicking on a window may take you to a help screen, or settings, or about, or whatever other kind of things we need, and maybe we'll have a title up at the top. Ta-da!~
- Design a menu system relevant to your game (on paper, not on the computer)
I don't think we actually have a name for our game yet? Anyway, the idea is that we start off with an external view of the mansion with some spooky stuff going on, and you can click on the door to enter start the game. Clicking on a window may take you to a help screen, or settings, or about, or whatever other kind of things we need, and maybe we'll have a title up at the top. Ta-da!~
- Design an HUD system that your game might use (on paper, not on the computer)
- Use the logic panel to construct a menu with two items, that are clickable. Use scenes to achieve this (or some other means). Menu should have “Play”,“Help”,“Prologue”,“Exit”
- Create one or more panels that with a brief description of your game (“Prologue”)
Tuesday, September 28, 2010
Game Design Homework 8 (aka: All four parts equal, but one clearly more equal than the others)
(see assignment here: http://fsugd.blogspot.com/2010/09/homework-8-elemental-tetrad.html)
Story: Nomic is a fairly abstract game and as such, there's no explicit story. If you want to force the idea of there being a story, though, there's the general idea/feeling that the players are legislators/law makers in some sense, working together, but each with the goal of winning as an individual. It's impossible to make any progress without cooperation, but everyone is always suspicious of one-another, because they all know that the others are always, in the end, trying to win at their expense.
Aesthetics: The original rules of Nomic call only for paper and pencil to write the rules and propositions upon, and a single die for using to gain points at the end of your turn. The aesthetic as the game has played out in my experience has always been one of the players sitting around a table with pads of paper, and with the table littered with little scraps of this and that, dominated by the central rule sheet in the middle of the table... the resulting feel, if you were to look at it as an outsider is something between a brainstorming session, a game of D&D, and an intensive study time for a life-crushing final exam... and that combination is indeed how the game itself usually ends up feeling.
Technology: As mentioned above, the technology is pretty minimal; paper, pencils, and a single 6-sided die. Some more recent adaptations of the core rules have called for the use of computers/laptops/internet connectivity, as the game lends itself very well to shared workspace environments as opposed to writing everything out on paper; but this adaptation changes nothing of the core aspects of the game. The simplicity and utilitarian aspects of what is needed to play add to the overarching feeling of legalese or doing some kind of work in governing, if you'd like to look at the theme as such.
Mechanics: There is where the "more equal" of this entry's title comes into play. Nomic as a game really exists only as a set of mechanics. All the rest is created by the players themselves in the act of playing. The core mechanics of the game are that of proposing a new rule, debating the meaning and merits of that rule, voting on if this new rule will come into effect or not, and then (through continued play) determining what the real effect of that change is. As it sounds, the entire experience feels very much like acting as a law maker or founding father of a country or some such, which as I mentioned is the overarching theme of the experience.
Aesthetics: Haunted Mansion! Dark corridors, old, dusty, creepy furniture, spooky music and sound effects, room layouts that make no sense and make you feel confused and lost, creepy lighting, etc.
Technology: Blender, obviously, and python scripting. Sam is also using some programs he's familiar with for music composition. Scripting will allow for a dynamically/randomly generated house layout, ensuring that the player does not feel comfortable in the mansion if they replay the game, and allowing for it to remain challenging.
Mechanics: Basic first person movement, you find various weapons (probably all non-projectile, but that's not set in stone) and use them to destroy haunted objects. You travel between rooms and look for new tools (weapons, flash light, possibly health items(?), etc.) and search, too, for the boss and the item needed to defeat him. Also, as time progresses in the mansion, the level of haunting increases; more items in each room will be dangerous, and returning to rooms you had previously cleared my yield new enemies.
- Consider any non-computer game that you enjoy playing, and describe the four elements for that game. For example: monopoly, battleship, dungeon and dragons, etc
I chose this game because it is clearly a very non-traditional game, and I believe it does a good job of breaking our book's author's ideas of what is needed for a good game. The game in its core does not truely rely on aesthetics, story, or even technology beyond the written word. At the same time, any of these elements could be introduced at any point in playing the game, if the players so chose to do so. The effectively-limitless flexibility of the game means that hypothetically all bets are off. That being said, my analysis is based only off of the core idea behind the initial rule set.Nomic is a game in which changing the rules is a move. In that respect it differs from almost every other game. The primary activity of Nomic is proposing changes in the rules, debating the wisdom of changing them in that way, voting on the changes, deciding what can and cannot be done afterwards, and doing it. Even this core of the game, of course, can be changed.—Peter Suber
Story: Nomic is a fairly abstract game and as such, there's no explicit story. If you want to force the idea of there being a story, though, there's the general idea/feeling that the players are legislators/law makers in some sense, working together, but each with the goal of winning as an individual. It's impossible to make any progress without cooperation, but everyone is always suspicious of one-another, because they all know that the others are always, in the end, trying to win at their expense.
Aesthetics: The original rules of Nomic call only for paper and pencil to write the rules and propositions upon, and a single die for using to gain points at the end of your turn. The aesthetic as the game has played out in my experience has always been one of the players sitting around a table with pads of paper, and with the table littered with little scraps of this and that, dominated by the central rule sheet in the middle of the table... the resulting feel, if you were to look at it as an outsider is something between a brainstorming session, a game of D&D, and an intensive study time for a life-crushing final exam... and that combination is indeed how the game itself usually ends up feeling.
Technology: As mentioned above, the technology is pretty minimal; paper, pencils, and a single 6-sided die. Some more recent adaptations of the core rules have called for the use of computers/laptops/internet connectivity, as the game lends itself very well to shared workspace environments as opposed to writing everything out on paper; but this adaptation changes nothing of the core aspects of the game. The simplicity and utilitarian aspects of what is needed to play add to the overarching feeling of legalese or doing some kind of work in governing, if you'd like to look at the theme as such.
Mechanics: There is where the "more equal" of this entry's title comes into play. Nomic as a game really exists only as a set of mechanics. All the rest is created by the players themselves in the act of playing. The core mechanics of the game are that of proposing a new rule, debating the meaning and merits of that rule, voting on if this new rule will come into effect or not, and then (through continued play) determining what the real effect of that change is. As it sounds, the entire experience feels very much like acting as a law maker or founding father of a country or some such, which as I mentioned is the overarching theme of the experience.
- Describe the mechanics, aesthetics, story elements and technology for your team’s game, in its current state
Aesthetics: Haunted Mansion! Dark corridors, old, dusty, creepy furniture, spooky music and sound effects, room layouts that make no sense and make you feel confused and lost, creepy lighting, etc.
Technology: Blender, obviously, and python scripting. Sam is also using some programs he's familiar with for music composition. Scripting will allow for a dynamically/randomly generated house layout, ensuring that the player does not feel comfortable in the mansion if they replay the game, and allowing for it to remain challenging.
Mechanics: Basic first person movement, you find various weapons (probably all non-projectile, but that's not set in stone) and use them to destroy haunted objects. You travel between rooms and look for new tools (weapons, flash light, possibly health items(?), etc.) and search, too, for the boss and the item needed to defeat him. Also, as time progresses in the mansion, the level of haunting increases; more items in each room will be dangerous, and returning to rooms you had previously cleared my yield new enemies.
- How is each of the four elements working towards a common theme? What is this theme?
Thursday, September 23, 2010
Game Design Homework 5+6 (aka: Cylinder Man vs. The T.V.)
(see assignments here: http://fsugd.blogspot.com/2010/09/homework-5-game-logic.html & http://fsugd.blogspot.com/2010/09/homework-6-it-builds-character.html)
So here we're working with having multiple objects, groups, add object actuators, tracking, changing states, shooting, and any number of other new minor skills. I've got a simple little quazi-game going here in which the player (Cylinder Man) attempts to destroy a chain of haunted T.V. sets, who in turn are trying to kill him. They do this by shooting different-colored bolts of electricity, or magic or some such at one-another. The player has, in this demo, 5 health, and each of the T.V. sets has 2. The player can run and jump has he or she pleases, and the TVs simply rotate and bounce menacingly forward while shooting at regular intervals. Each time you kill a TV, it falls over and spins around a bit before disappearing, at which time a new one spawns. When the player inevitably dies, he/she also falls over and bounces around a bit, just for good measure.
So here we're working with having multiple objects, groups, add object actuators, tracking, changing states, shooting, and any number of other new minor skills. I've got a simple little quazi-game going here in which the player (Cylinder Man) attempts to destroy a chain of haunted T.V. sets, who in turn are trying to kill him. They do this by shooting different-colored bolts of electricity, or magic or some such at one-another. The player has, in this demo, 5 health, and each of the T.V. sets has 2. The player can run and jump has he or she pleases, and the TVs simply rotate and bounce menacingly forward while shooting at regular intervals. Each time you kill a TV, it falls over and spins around a bit before disappearing, at which time a new one spawns. When the player inevitably dies, he/she also falls over and bounces around a bit, just for good measure.
Tuesday, September 21, 2010
Game Design Homework 7 (aka: What are you doing? NO FOR REAL)
Assignment has yet to be posted on class blog, so here we go:
The homework is individual, post to your blog
• Describe some surprises in your game
Well... everything attacks you? Hopefully that's at least a little surprising. The levels are dynamically generated in a way that makes the inside of the house seem supernaturally large, and somewhat nonsensical, as a result of it being haunted. We're toying with the idea of having certain enemies being effected oddly by certain weapons, but that is a back-burner idea.
• Describe the goal of your game (as opposed to the experience)
The goal, from the player's perspective, is to find the source of the haunting and a way to stop it
• Why would a player wish to achieve the goals stated in your game ?
Because s/he doesn't want to be eaten by a toaster?
• What is valuable to your game players?
Baseball bats, hammers.... things that they can use to break things. Also health-regen items, if we choose to implement them (still being debated)
• What problems are the players asked to solve?
"How do you break these things?" "Where the heck is the door?" "Which way do I go to find what I'm looking for?" "Why is this toaster eating me?" "How do I destroy an evil, haunted potato?"
• How could your game generated(?) additional problems so that the players keep playing?
Dynamic level generation!~
• Give some initial thoughts to the four elements (mechanics,elements, story, aesthetics) of your game. (We will go into more detail in the following week.)
Mechanics are mostly standard for a FPS, though we are not currently planning on having any projectile weapons.
Technology is blender, obviously.
Story is pretty simple and straightforward; you're in an evil haunted mansion, and do not like it.
Aesthetics are simple by necessity, but we hope to give a general sense of creepy haunted-ness through use of lighting and music (Yay for Sam's music skillz!).
Now I shall go back to my pulsing headache.
The homework is individual, post to your blog
• Describe some surprises in your game
Well... everything attacks you? Hopefully that's at least a little surprising. The levels are dynamically generated in a way that makes the inside of the house seem supernaturally large, and somewhat nonsensical, as a result of it being haunted. We're toying with the idea of having certain enemies being effected oddly by certain weapons, but that is a back-burner idea.
• Describe the goal of your game (as opposed to the experience)
The goal, from the player's perspective, is to find the source of the haunting and a way to stop it
• Why would a player wish to achieve the goals stated in your game ?
Because s/he doesn't want to be eaten by a toaster?
• What is valuable to your game players?
Baseball bats, hammers.... things that they can use to break things. Also health-regen items, if we choose to implement them (still being debated)
• What problems are the players asked to solve?
"How do you break these things?" "Where the heck is the door?" "Which way do I go to find what I'm looking for?" "Why is this toaster eating me?" "How do I destroy an evil, haunted potato?"
• How could your game generated(?) additional problems so that the players keep playing?
Dynamic level generation!~
• Give some initial thoughts to the four elements (mechanics,elements, story, aesthetics) of your game. (We will go into more detail in the following week.)
Mechanics are mostly standard for a FPS, though we are not currently planning on having any projectile weapons.
Technology is blender, obviously.
Story is pretty simple and straightforward; you're in an evil haunted mansion, and do not like it.
Aesthetics are simple by necessity, but we hope to give a general sense of creepy haunted-ness through use of lighting and music (Yay for Sam's music skillz!).
Now I shall go back to my pulsing headache.
Tuesday, September 14, 2010
Game Design Homework 4 (aka: What are you doing?)
(see assignment here: http://fsugd.blogspot.com/2010/09/homework-4-experience.html)
So... our game, hm? The basic idea is this: You're in a haunted mansion, and your goal is to A: survive, but also B: fight off haunted house-objects while you search the house for the source of the haunting and a way to stop it.
The background/plot of the game is pretty minimal. Perhaps we'll have a wall-of-text screen at the beginning describing the basic set-up... something about having been called to the house to fix a problem, or the likes... for whatever reason, you're in the house, and now you can't get it. Various objects (sofas, toasters, refrigerators, beds, etc.) are becoming haunted and attacking you, and you have to beat them up with whatever household objects you can find.
One of the primary "gimmicks" of the game is that the mansion will be randomly/dynamically generated every time you play. The layout will be strange and twisty, and not necessarily make any sense in terms of real architecture... and that's entirely intentional. It's part of the effects of the haunting; the house is much larger on the inside than would make sense from seeing the outside. Why are there 20 kitchens? I dunno... it's spooooky~ We're also hoping to do some nice subtle tricks with the music, to help with a atmosphere/general creepiness factor, as well as to convey useful game information. (ex. we're considering having the game tempo increase as your health decreases, so that you know you're in danger and it becomes more suspenseful.)
In terms of characters, there's really only the blank-slate protagonist (the game is 1st person, so the only details offered will perhaps be what his/her hands look like). The "antagonists" are household objects which have been possessed by evil. Also (spoiler warning), the "big boss" of the game, and source of the evil hauntings, is a big, evil potato. One found, you must locate the Holy Potato Peeler to destroy it and free the house from its evil grasp.
Typical "levels"/rooms would be something like a kitchen in which there are a number of mundane objects... say a toaster, some plates, a table with some chairs, etc. and, mixed in, some haunted objects such as a refrigerator, a blender, and maybe a couple of the chairs, which will attack you when you come near to them. You have to attempt to interact with the various objects as you search the house for tools and the source of the evil, but if you interact with an evil object it will attack you. Also, as time passes, more and more objects become possessed... so rooms will have higher percentages of objects which are dangerous, and new objects may become haunted that previously were not in rooms you've already passed through.
I am not an artist in any way, so... uh... here's some "concept art" from random Google image searches?
(This toaster is brave, but not very evil)
(Here's a mean-looking couch)
(The quintessential game-that-takes-place-in-a-mansion)
So... our game, hm? The basic idea is this: You're in a haunted mansion, and your goal is to A: survive, but also B: fight off haunted house-objects while you search the house for the source of the haunting and a way to stop it.
The background/plot of the game is pretty minimal. Perhaps we'll have a wall-of-text screen at the beginning describing the basic set-up... something about having been called to the house to fix a problem, or the likes... for whatever reason, you're in the house, and now you can't get it. Various objects (sofas, toasters, refrigerators, beds, etc.) are becoming haunted and attacking you, and you have to beat them up with whatever household objects you can find.
One of the primary "gimmicks" of the game is that the mansion will be randomly/dynamically generated every time you play. The layout will be strange and twisty, and not necessarily make any sense in terms of real architecture... and that's entirely intentional. It's part of the effects of the haunting; the house is much larger on the inside than would make sense from seeing the outside. Why are there 20 kitchens? I dunno... it's spooooky~ We're also hoping to do some nice subtle tricks with the music, to help with a atmosphere/general creepiness factor, as well as to convey useful game information. (ex. we're considering having the game tempo increase as your health decreases, so that you know you're in danger and it becomes more suspenseful.)
In terms of characters, there's really only the blank-slate protagonist (the game is 1st person, so the only details offered will perhaps be what his/her hands look like). The "antagonists" are household objects which have been possessed by evil. Also (spoiler warning), the "big boss" of the game, and source of the evil hauntings, is a big, evil potato. One found, you must locate the Holy Potato Peeler to destroy it and free the house from its evil grasp.
Typical "levels"/rooms would be something like a kitchen in which there are a number of mundane objects... say a toaster, some plates, a table with some chairs, etc. and, mixed in, some haunted objects such as a refrigerator, a blender, and maybe a couple of the chairs, which will attack you when you come near to them. You have to attempt to interact with the various objects as you search the house for tools and the source of the evil, but if you interact with an evil object it will attack you. Also, as time passes, more and more objects become possessed... so rooms will have higher percentages of objects which are dangerous, and new objects may become haunted that previously were not in rooms you've already passed through.
I am not an artist in any way, so... uh... here's some "concept art" from random Google image searches?
(This toaster is brave, but not very evil)
(Here's a mean-looking couch)
(The quintessential game-that-takes-place-in-a-mansion)
Thursday, September 9, 2010
Game Design Homework 3 (aka: I like to move it - move it!)
(see assignment here: http://fsugd.blogspot.com/2010/09/homework-3-action.html)
So here we go, homework 3... Today's assignment is a direct extension of #2; I took the file from the end of that assignment, and simply added in some sensors and the likes to make it interactive. I stuck a dozen keyboard triggers onto my ship, so now you can awkwardly fly it around by rotating and/or accelerating about any of the three axis. wasd+qe for motion, ijkl+uo for rotations. I also made it so that the spacebar key would move the camera to something resembling an isometric view on the ship, in case you fly off into nowhere land. Lastly, I made it so that if you can manage to bump into the big orb-thing, it'll reset the scene for you. Ta-dum. I think what this best demonstrates is how amazingly complex and counter-intuitive it is to move a ship through a vacuum. JANE! STOP THIS CRAZY THING!~
(Apparently the server rejected my original video without informing me. I've converted it to WMV and it's slightly butchered the video in the process... hopefully it still makes some sense though?)
So here we go, homework 3... Today's assignment is a direct extension of #2; I took the file from the end of that assignment, and simply added in some sensors and the likes to make it interactive. I stuck a dozen keyboard triggers onto my ship, so now you can awkwardly fly it around by rotating and/or accelerating about any of the three axis. wasd+qe for motion, ijkl+uo for rotations. I also made it so that the spacebar key would move the camera to something resembling an isometric view on the ship, in case you fly off into nowhere land. Lastly, I made it so that if you can manage to bump into the big orb-thing, it'll reset the scene for you. Ta-dum. I think what this best demonstrates is how amazingly complex and counter-intuitive it is to move a ship through a vacuum. JANE! STOP THIS CRAZY THING!~
Thursday, September 2, 2010
Game Design Homework 2 (aka: Does it Blend?)
(see assignment here: http://fsugd.blogspot.com/2010/08/homework-2-blend.html)
So for this task, we're basically familiarizing ourselves with the basic object-constructing functions of Blender. I'm playing with version 2.49b here, and I make myself a neat little space ship like such:
After I finished recording that, I played around and made the ship more symmetrical, smooth out the back a bit, and redid the texture. I also generated a nice, bumpy little world with colorful pools of... I dunno, magic voodoo juice? I stuck a random star map behind it, added a bit of lighting, imported my ship, and... ta-da! Here's my final result:
Neat-o, huh?
I had a lot of fun with this assignment, actually... I spend a few hours over the past couple of days just playing around with shapes and getting more-or-less accustomed to the controls. I still don't know how to do anything of much use with texturing, but perhaps a time will come for that one.
I'm looking forward to the next assignment, because now we're getting into actually moving things! Hoo-ray!
So for this task, we're basically familiarizing ourselves with the basic object-constructing functions of Blender. I'm playing with version 2.49b here, and I make myself a neat little space ship like such:
After I finished recording that, I played around and made the ship more symmetrical, smooth out the back a bit, and redid the texture. I also generated a nice, bumpy little world with colorful pools of... I dunno, magic voodoo juice? I stuck a random star map behind it, added a bit of lighting, imported my ship, and... ta-da! Here's my final result:
Neat-o, huh?
I had a lot of fun with this assignment, actually... I spend a few hours over the past couple of days just playing around with shapes and getting more-or-less accustomed to the controls. I still don't know how to do anything of much use with texturing, but perhaps a time will come for that one.
I'm looking forward to the next assignment, because now we're getting into actually moving things! Hoo-ray!
Saturday, August 28, 2010
Game Design Homework 1 (aka: Prove you know how to post in a blog)
(see assignment here: http://fsugd.blogspot.com/2010/08/homework-1-make-blog.html)
This is a picture of god. Every good game designer needs one of these:
(Fun Fact: I was once within about 20 feet of Miyamoto. It was pretty much the most amazing moment of my life.)
Here's a video of of me talking (very) briefly about the WikiReader. Enjoy?
This is a picture of god. Every good game designer needs one of these:
(Fun Fact: I was once within about 20 feet of Miyamoto. It was pretty much the most amazing moment of my life.)
Here's a video of of me talking (very) briefly about the WikiReader. Enjoy?
Wait, wait, let me explain!
I am Blayne, and what is this? Well, I suppose it's my attempt to document my efforts in game development. For the moment at least, this is specifically through the context of Florida State University's Fall 2010 Game Design class being offered by the Department of Scientific Computing. For the class we're required to maintain such a blag and use it for our assignments and the likes. I shall do so here, but hopefully also use it for any other work I do towards this long-standing goal of mine. And with that... let's get started on my dang homework!
Subscribe to:
Posts (Atom)