Game Design Homework 15

(see assignment here:  http://fsugd.blogspot.com/2010/10/homework-15-status-of-your-game.html)

• 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.

I feel like I've generally made a good effort to point out what I have, and each of my other group members has, contributed all along.  I guess it's dome for extra reiteration though?  Alright.

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:

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:

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.)

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)

• What steps are members of your team taking to prototype the game?

I've been using the Blender assignments as a way to incrementally add ideas and mechanics that directly relate to things we want in our game.  In effect, the Blender assignments have become a working prototype of our group game, though with a different "plot" behind it, if you even want to call it that.  I know that Sam has been primarily focused on making an original score for us, and the relevant form of prototyping for him is that he's been writing and playing around with different themes on a piano before going to the effort of actually recording them through a midi system.  David's been working on improving his modeling skills and building us some various objects to use in the game, and seems to be getting quite a lot better at it.

• What could go wrong in your team’s game?

Murphy's Law?  Plenty of things could foreseeable be more difficult than we're expecting.  The main one I've been concerned with, as the programmer, is implementing the dynamic room generation, and dealing with transitioning the player between rooms (We're going to have to do some tricky stuff, maybe, to deal with issues Blender has with lighting)

• Will men and women like your game equally? What could be done to enhance the game for one or the other gender?

I imagine it would appeal more to men than to women... the genres involved (FPS and Survival Horror) both tend to be skewed in that direction.  Enhance the game for women... hmm.. Ignoring the fact that it's out of the scope of this class, perhaps making it multiplayer could help a little... even then, though, I don't have much hope that it could appeal to a general female audience much.  Can't win 'em all!

• 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.

I don't think this game would be overly geared towards any particular age group... Teens would probably be fine with it as is.  40-50 might want more explanation that we want to give the players, but aside from that, I don't see too much that we would want to change if we're sticking with the same core game concepts.

• What pleasures does your game provide to the players (Chapter 8)

Progression, a sort of suspense up and down feeling, hopefully a little bit of humor if some objects are animated to move in novel ways. 

• How are you applying the principles of iteration (chapter 7) to your game design? Each member should discuss his/her approach and contribution

I touched on this in the earlier question on prototyping, but the fact that I'm playing each version I create for the homework, and usually ever several steps within each assignment.  I'll fudge around with a couple variables like speed and health... though so far I've mostly been tuning it to be easier to test, as opposed to more balanced to play.  I'll clearly go back and rebalance everything once we get closer to a final game.

• What are some changes that you “might” have to make to your game to improve it?

From a purely gameplay perspective (as opposed to, say, technical problems we may encounter), we may decide that we want to give the player more varried ways of interacting... missile weapons is one idea that we initially threw out, but I might suggest re-considering if we have time, because it could allow for some interesting ways of dealing with more dangerous or tricky foes.

• What are you doing that “might” not work as expected?

Some of our lighting ideas are proving tricky, and we've still got a lot to learn about how we want the player to interact with the music.  I'm also, as I mentioned, a little worried about getting the dynamic rooms working out smoothly.

• What are the characteristics/experiences/features that players will like and not like? What are your expectations from the players of your game?

Assuming we get everything implemented as we're envisioning it?  I think the random layout of the mansion will be a fun thing for players to work with... keeps things unpredictable.  It's possible that some players might not like the idea of conveying health information through music... it requires them to pay attention to something that many people have become self-trained to tune out.  Also, depending on how you feel about tension in games, you may love or hate the fact that you often don't know until the last second if a sofa is going to try to eat you or not.

As is becoming my norm for text-heavy entries, here is a picture:

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?

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.

• What is the theme of your game?

 Haunted mansion, etc.

• Name one experience from your own life that could be built into your team’s game

Uh... I once went to Halloween Horror Nights at Universal Studios?   I walked through a bunch of haunted house-type things and had various things jump out at me threateningly?

• How could you incorporate this idea into the game?

We can have a bunch of things suddenly jump out at the player threateningly?

• Give 5 ways you are reinforcing your theme (or plan to reinforce the theme)

 Dark, flickering lighting
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?

 "How do we design an immersive haunted-house game with some unique characteristics?"

• What are the constraints imposed by the problem statement?

 We're locking down the general genre and theme of the game, and that it is a game of course.  Also, since we are trying for maximum immersion, we limit what can be presented in the game (Straying too far from normalcy of things like the environment will destroy suspension of disbelief, etc.), and of course wanting it to be unique rules out full-scale copying of someone else's game. :P

Too much text today, hmm?  Here's a random picture from my archives...

I need some shades like that.