Narrative in games lecture

Last week we were required to attend a lecture on narratives in games and trans media.  The lecture focused on building an entire world around our story in order to create a game as opposed to a different style of media that is much easier.  For example, books are the simplest due to the fact that much of the world is filled in by the reader's imagination.  Movies add a second and third layer of visuals and audio combined to create what the director wants you to both see and hear.  Video games are a whole new medium, much like movies, due to the fact that they add a fourth layer to this which is interaction.  By allowing the player to interact with the world, we allow them to create a story that feels more personal and immersive than a movie.  Then, by combining all three, we can accurately create an entire universe through trans media.  This was the general idea of the lecture, but I felt as if I've heard it all before, mostly from our programming teachers throughout the last three and a half years at college.

Things to Improve (?)

If I manage to have some free time, I would really like to come back to this project and rework some things as well as finish some polish that the systems desperately need in order to look nicer.

Some of these things include making the AI smarter and more state based (the basic layout is in there, but it needs a lot of game play programming in order to look complete) as well as mostly just polish for everything else that is in the game and tweaking of certain things.  The most prevalent tweak that should be done is probably the inventory system which we decided would just be picking up and placing objects as opposed to having an infinite list of items you can pick up.

The other thing I was looking forward to, but didn't have a chance to do because it would have been in next semester's class, is the audio manager.  This would have allowed my designers to easily work with different audio clips at different times, but for now we were just trying to get the game to look good enough for presentations so I wasn't able to implement the whole thing.  We've just been playing audio clips after importing them for now which works fine, but is not very pretty to look at.

Other than that, the game will probably be about ready to be put into a vertical slice with a lot of design work (mostly just tweaking and bug fixing to make everything feel, look, and sound better).

Im Back

Well, after a long Thanksgiving without internet, we're back.  Unfortunately I've found that our team has been cut for next semester so this project will be scrapped and I will be put on a new team to blog about for next semester.

I think the biggest reason why we got cut was between group dynamic as well as communication.  Between having an issue contacting people and being left with vague notes in the issues section of our repository as well as extremely short meetings where we continuously discussed things that were not relevant to what needed to be done that week (relevant to the project just not things we needed to be talking about), I can see why we got cut.  The meetings were the most unfortunate part of all of this because I tried to keep everyone on track, but I felt as if everyone was very scatterbrained or they just weren't into what we were actually doing because the conversations would always get ahead of ourselves. I honestly think this team would not have worked out in the end and, to be perfectly honest, I am glad we got cut.

I could see this happening around the middle of the year when a teammate came to a meeting and said that he didn't think we were going to make it in the end.  This seemed like it just killed a lot of our will at times, but I tried to keep everyone motivated enough to finish the project, but that seemed to backfire a bit because it caused more work for me with little results.

All in all, I'm happy with what I, personally, managed to accomplish even though it took me much longer than it should have due to scope issues as well as having to clean up the level every time I sat down to work on it.  At the beginning of the year I was uneasy about this team, but I told myself we would not be cut due to a lack of effort on my part, and, even though we did not make it to next semester, I definitely accomplished my personal goal.

Our challenge went fairly well today.  Unfortunately, we had some bugs which made the game look dumb at certain points, but it wasn't bad considering I wasn't told about many of these bugs until late last night and did not have a chance to fix them until this morning.  The two biggest issues are the inventory system breaking and the crouch breaking.  The crouch was fixed for the presentation, but another bug came up which cause the player to bounce up and down.  I have it fixed now since it was an easy issue to fix, I just didn't have time for it. As for the inventory system, we may be taking this out of the game because it is becoming increasingly irrelevant for the scope of our game.

Just got the randomization finished.  The rooms seem to be appearing in the correct locations and they are not spawning on top of each other any more.

For testing purposes, I duplicated some of the room prefabs to give the illusion of having similar rooms in the asylum (i.e. around 3 of each, only 2 of the glass rooms since we have 8 random rooms all together).  It looks so much better now, the level seems much fuller with something going on in every room.  Some of the rooms are useless (tables and crates) but it gives the building a more realistic feel.

Anyways, all the systems are built, now they just need to be revamped, polished, and organized, but a lot of that comes next semester if we move on.  The last thing we need in order to present our vertical slice is all on the design and art aspects of our game.

The last few things we need to add for our vertical slice (more specifically) includes: more art assets (as many as we can muster), the rooms need to be fixed and tested as to accommodate all the random room prefabs that are initially being instantiated, and we need some different types of rooms.  The ones we have at the moment work for now, but it would be nice for some more versatility.

This should all be design and art work, but I have a feeling I will end up reworking many of the prefabs as well as the level in order to make sure our game is working.

Last night's Q.A. session went fairly well.  It ended up turning into more of a bug testing session, but it actually helped a lot from my stand point.  When I initially got there around 8:30 I found that the prefabs were still screwed up for some reason so I spent half an hour fixing them and implementing the randomization of the prefabs.  It pretty much works the only issue I'm still having is that sometimes multiple prefabs will appear in the same room, but I didn't have time to fix that last night.  I should have time to fix it tonight before we present tomorrow.

Looking to catch up on my blog posts before the end of the year so I will be attempting to post every time I do something from now until the end of the year.

Today we are looking for another Q.A. session in order to complete the requirement we need to pass on to stage 4 before break since it's the last time we can challenge to stage 4.  Unfortunately, we lost our producer to M.I.G.S. for most of this week so I have two big tasks I'm looking to complete today for this project.

First off, I need to be ready for the Q.A. session.  The last thing I need to test is the randomization of the room prefabs.  We ran into an issue where all the prefabs' transforms were messed up.  I asked for a size of (1, 1, 1) and the center of the prefab to be (0, 0, 0) so we can place the prefabs right in the center of the room and have the script take care of setting it up for us.  Something got messed up, so I was waiting on Vinny to remake them properly.  Now that I have them, I can properly test and debug this system.

The second thing I need to do today is run the Q.A. session for our team which I found out yesterday around 4:30.  This kind of threw a stick in the spokes of my plan for the day, but it shouldn't be a problem.  I'm just worried because I haven't run one of these before (I've been there but my job was usually fixing bug issues that came up).  Regardless, I am going to try to get two to three testers or so tonight and get all their responses and I think we should be good after that.  I do believe we are having another Q.A. session tomorrow night as well so we can get some good feedback on it.

Well that's about it for today, I'll be posting again soon I'm sure.

New update on our mechanics.  Randomization is just about implemented.  The walls are randomized in each of the random rooms. The collectibles are randomized based on areas set up by my designers.  The way the trap and challenge randomization will include a prefab for each trap or challenge.  The game will pick one trap and a specified number of challenges and apply them as well as rotate them to fit one of the random rooms.  This should be fairly easily implemented (at least easier than the walls were).

The other thing I worked on implementing was the inventory system.  This is basically implemented as well I just need to fix the one bug I'm having where the inventory won't spawn the object with the rigidbody for some reason and I need to take the keys out of the inventory because you don't need to use them.

The last thing I want to discuss in this post is the A.I. that will be going along with the enemy in the game.  The best way to do this, and make it seem very realistic, will be to add a state machine into the game for the enemy.  States I want to include will be: normal, seeking, random, wander.  Normal will make him patrol his normal pathway.  Seeking will move the enemy towards the player. Random will choose random way points from the enemy's path, and wander will make him walk around the current room he is in.

As for this past week, we finally decided to implement some randomization.  This will make our game more interesting due to the fact that there are very few horror games with randomization in them.  Even if there is randomization, it is minimal and usually goes unnoticed.  For our game, I want the player to be playing a (relatively) different game each time.  The two main random factors of this game that we are looking at are the rooms and the collectibles.  What I worked on this week is random collectibles which seems to work fairly well and I like how Vinny designed the level.  The collectibles are fairly close to each other, but they do not always spawn in certain locations which gives the player a twist already even without adding the randomized rooms.

Most of last week was just planning on my part.  As for the team, we mostly just brainstormed how we were going to tie everything together and get the last few mechanics in.  We've had a few ideas for mechanics, but to do all of them would be out of scope.  Some things we brainstormed included randomization of rooms and collectables, blockades for doors and hallways to stop the enemy, and swinging ropes.  We presented these ideas in class and got excellent feedback in order to help us decide which direction to take.

Not too much has been happening in the past week except some tweaks and bug fixes.  Currently, I am trying to finish up all the mechanics in order to let Matt and Vinny finalize their levels.  Once the two prototypes are complete, we have some documents to write up and some QA testing to do.  Hopefully we will be challenging stage one by the end of the week.

Sorry for the late posting, but thank you all for joining me on our third week of working on our capstone team project.  Be prepared because there's a lot to catch up on, but I'm basically just going to lay out what has been done thus far, as far as programming goes.

OVERVIEW:

Our game would be classified as a stealth style game.  The stealth mechanics will be based off light and sound.  We wanted to go for a few others, but were recommended to focus on these two for now.

There will most likely be one monster in the level which the player needs to avoid in order to complete puzzles and open the door to the next level.  Having only one monster could easily change, but there will only be one actual active monster at a time, per level. 

PROGRAMMING:

There are no actual systems in place yet, we are still in the middle of prototyping, but I can atleast go over the mechanics we are planning on working with.

Last week, we got nailed on scope, so we managed to cut a bunch of things out.  We may still have to cut back on certain mechanics, but it's looking much better.

The first thing I will go over are the player mechanics.  So far, we have tested a bunch and gotten rid of a few.  The first cut was the grappling hook.  This mechanic was done, but we decided that it wouldn't fit for the style of game we are going for.

Other mechanics, that have not been cut, include sight jacking (where the player is able to take on the view of a monster or other npc), a very basic stealth mechanic so far (light and sound dont matter, we're just going off point of view for now using a cone for their vision), picking up and throwing objects (enemies get stunned for a few seconds when hit), and slowing down time.

So far, everything is going fairly smoothly; it's a little frustrating not working with systems quite yet because my code architecture is horrific, but that will all get fixed once we iron out which mechanics we're actually using that way I won't have to rebuild whole systems, only simple mechanics.