2/7->2/13
So last week was a week of questions answered from our greenlight. This week is pretty simple. The designers continued work on their whiteboxes.
The artists have made some good progress on their Bots. The first time I saw it I was surprised. It was a great improvement over what we had the previous semester. These things actually look scary. You look at them and instantly know that you shouldn't go near them. Spinner orbs of death circle them.
The gun's primary and secondary functionality is basically done. Now the rest of the functionality such as reloading and fire intervals are left for that.
We are also starting to get concerns with audio. We have not yet seen a lot of audio from the sound effect guy yet. We are worried about getting them all last minute and having to rush and cram the last few weeks. We have brought the issue up with the guy who runs it and hope to get some response from him. I know that he has set up a few sessions where he was going to show others how to do some basic sound stuff but I don't think know how many people have shown up at these. So he is trying to show people how to make stuff. We just haven't got anything from him yet.
The voice over work has been started. We have got a few different samples from the voice over guy but have not liked what he has sent yet. We will iterate through these until we find what we are looking for. We have two voices that are in this game. The main character and the AI companion.
I am wondering if the issues with the sound are a result of miscommunication between my team and the sound people. It may be the result of not wanting to hurt the people who are creating the assets. But I think it is best to be forward and honest with these people in what you are looking for. If you don't know what you are looking for then you should put some thought into it and try to work with them to figure it out.
Over all decent progress is coming along with some concerns in Audio. This week was nothing out of the ordinary just another production week.
Monday, February 21, 2011
Sunday, February 13, 2011
Making of a Student Game: Week 4
Week3: 1/31->2/6
Keeping what you are doing in mind is very important. You need to keep your mind on the big picture. Returning to questions like these is helpful.
This week was an off week as far as meetings go. Due to a really bad snow storm our Wednesday meeting was canceled. Then our Sunday meeting was rescheduled to Monday because of the super bowl so I will not include that in this post and wait to put that in the next post. We still met during our class times though.
I was pretty absorbed in my work during these class times though so I don't have too much information about what others have done. I'll do my best to inform you though. The video below is the new run through that is was created after this weeks work.
This week we did get written feedback from our professor about our green light presentation. Part of this critique were some general questions that I felt like I could explain here about our game.
- Professor Comment: Although explained in class, I want to know how you plan to deal with the problem of a 300 year old ship drifting in space
The ship has a few different bots that live on it. Some you fight (3 types) and some you don't the caretaker bots. These care taker bots have been there repairing the ship as it got damaged. They have been repairing the ship with the resources on it. In this case they have gold. So as you play through the game you will see patchworks of gold along different parts of the ship. We will be putting up different decals of these repairs throughout the ship. They will become more plentiful as you make it towards the end.
- Professor Comment: If the robots were caretakers, how do caretakers evolve into agents of death?
Again these are two different bots. There is one with the task of defending the gold. Those are the ones that attack you. The others are tasked with ensuring that the ship works correctly. These ones are the ones that will be making repairs to the ship and putting gold patches on the walls.
- Professor Comment: How does a salvage gun with a push beam actually salvage anything?
Our player is a salvager who finds the ship. He is wondering why his salvage tool is able to push the bots away from you. The reasoning behind this is that when working in a 0G environment it is useful to have a tool that can push and move objects around without actually pushing the user back as well.
- Professor Comment: Neon green and yellow textures? These are for testing, right?
Yes. These are place holder.
- Professor Comment about level 1: Will the green mesh holding the crate... wait... what IS the green mesh holding the crate? How does a structure like that function as a crane?
I thought I would share this because I thought it was a good example of how outside feedback is really useful. I played through that level and saw many people play through it as well. He is the first person to actually say something about this. I am not sure what the level designer's plan was for that part of the level. I have always just known to shoot that beam and it will solve the puzzle. Having people who are not as close to the project go through and think about the different aspects of your game is very important for flow and making sure everything makes sense and fits. Sometimes if you are constantly working on different parts you can miss pretty obvious questions like that. Look for this part in the video and you'll see what he is talking about. It is in the room where you walk down the stairs to a giant pit and you need to shoot this to move on.
- Professor Comment about level 1: I like the distracto-grenades. I also like blowing up the bots. Is there a penalty to that? I presume that the energy for my weapon will be toned down later?
When testing the game it is useful to have things like the length of the grenade longer so you can see how it acts easier. It is easier to see what the bots will do around it if we have it last longer. It also allows us to see what bugs it might bring about. In the video below right before the end there will be a bot that doesn’t seem to move and it just sits there. This is a bug from the grenade logic. Because there is an active grenade it won’t target you. But at the same time, since the grenade is too far away it won’t move towards it either. The grenade will have its own timer and will only be able to be shot about once a minute or so and the grenade will last between 10 and 30 seconds. (At least that is what we are thinking now before it has been tested.)
- Professor Comment about level 1: How much platformer do you want in this game?
- Professor Comment about level 3: Why is that fire there?
Because you just broke some stuff earlier in the level. There will be more in the final design.
Here is the link to the video from this week. You can see the changes that have been made over the week from this.
Thursday, February 3, 2011
Making of a Student Game: Week 3
Week3: 1/23->1/30
This week had a mix of highs and lows. The artist who was working on the Enemies was hospitalized and unable to work all week. He is fine and was out by the end of the week, but unable to get any work done.
On a lighter note, we found out that the requirements for greenlight were basically the same as the issues brought up in our critique. We had no issues getting greenlight and moving forward with our project. To do this we needed to show that we had put some more thought into our narrative and how the game would actually flow. Our vertical slice was based very much on mechanics and we hadn't put the time into narrative last semester. As I have shown in one of our last posts we put thought into that once we got back. Since then it has been written out more and it has been tied into the design of the first three levels.
We also had to show how we would populate the levels. We have to show that the ship looked like it was, at one point, a working ship. At the same time this can mean a few things. Are we going to go Star Trek or Firefly with our ships interior? Keith's concept art that he has been making about all of the assets and Eric's start on creating them allowed us to move past this.
The critique pointed out how we were not really reaching our goal of making sure the player would think about their environment and use it correctly. This was something that we knew at the end of last semester and we have worked on that a lot. Our design team has done a great job at ensuring that we made this happen. They have done a lot to ensure that this is in our levels and our lead designer has put up the tutorials on how to make the basics of these. You can see some of this starting to get iterated through in the video below.
Audio and scope were the other issues. These we have handled by working with our audio guy and thinking about what we would really need to do and what we didn't. How could we streamline stuff. We handled these issues and explained all of this to the professor.
We then spent the weekend working on our game. We spent about 8 hours or so on it on both Saturday and Sunday. This allowed us to make larges amounts of progress.
On the programming side we struggled with an issue all of Saturday. It wasn't until Sunday that we were able to fix it. However by finding the solution to the issue our weapon is very close to being functional in both the secondary and primary weapon mode. I did have the time to make some minor changes in the AI to get them to act slightly differently, but most of my time was spent working with Chris on his issue. When we figured out the solution he was able to make the fix in an hour. While I was struggling on Saturday, our lead designer got his hands dirty with some unrealscript. He went in and messed around with attaching lights and changing around some values in the AI to make them more to his liking as well as some other miscellaneous tasks. I love having a designer who knows how to do this.
The Art team continued working on assets. While our enemy guy was still out, our lead artist started making way on the gun. The gun we have been using is the default UDK one. The other artist made the assets that you will see in the video below. The doors, walls, floors and roof were done by him last week end.
The level designers took the time to make their levels more interesting and added in various different touches and they are starting to really come through, as much as they can with the amount of meshes they have. I had Bryan, our lead designer, make a video of a run through for me (Thanks Bryan). This is where the whiteboxes are right now. They are slowly moving away from BSP (the blue checkers) and adding in the assets they can. We have started adding in bots in different parts as well. The clip below was pretty loud on my computer so you may want to turn down your speakers if you have them on.
Through this you can see a few different things. The first thing you notice is the text greeting a tester. We have builds that go out every week that we then have tested by a bunch of Freshmen and Sophomore Game Dev students. We have a Senior who is assigned to our team who tells them what we are looking for and instructs them on anything we need from them and vice versa. He is essentially the liaison between our team and the QA testers. They report different bugs to us on everything from level design to programming bugs. The bug reporting is handled through a project management software.
The video shows some of our main mechanics early on. Our two weapon fire modes of the push back gun and the attraction bullets, which works similar to the pipe bombs in Left 4 Dead. The bullets really draw out an issue in how the AI are currently working and will probably be my next task. Right now they will path find to where you are and then move there. They don't check to see if you have move until they get there. I'll need to do something about this.
Looking at this video I'm liking the progress. All three levels were done since the start of this semester. All of the art is new as well. The AI is being subclassed from the base AI I made last semester. The weapon was easy to make since we could base it off of the classes that are already in UDK. While we may be done with three weeks about half of that was design and brainstorming.
This week had a mix of highs and lows. The artist who was working on the Enemies was hospitalized and unable to work all week. He is fine and was out by the end of the week, but unable to get any work done.
On a lighter note, we found out that the requirements for greenlight were basically the same as the issues brought up in our critique. We had no issues getting greenlight and moving forward with our project. To do this we needed to show that we had put some more thought into our narrative and how the game would actually flow. Our vertical slice was based very much on mechanics and we hadn't put the time into narrative last semester. As I have shown in one of our last posts we put thought into that once we got back. Since then it has been written out more and it has been tied into the design of the first three levels.
We also had to show how we would populate the levels. We have to show that the ship looked like it was, at one point, a working ship. At the same time this can mean a few things. Are we going to go Star Trek or Firefly with our ships interior? Keith's concept art that he has been making about all of the assets and Eric's start on creating them allowed us to move past this.
The critique pointed out how we were not really reaching our goal of making sure the player would think about their environment and use it correctly. This was something that we knew at the end of last semester and we have worked on that a lot. Our design team has done a great job at ensuring that we made this happen. They have done a lot to ensure that this is in our levels and our lead designer has put up the tutorials on how to make the basics of these. You can see some of this starting to get iterated through in the video below.
Audio and scope were the other issues. These we have handled by working with our audio guy and thinking about what we would really need to do and what we didn't. How could we streamline stuff. We handled these issues and explained all of this to the professor.
We then spent the weekend working on our game. We spent about 8 hours or so on it on both Saturday and Sunday. This allowed us to make larges amounts of progress.
On the programming side we struggled with an issue all of Saturday. It wasn't until Sunday that we were able to fix it. However by finding the solution to the issue our weapon is very close to being functional in both the secondary and primary weapon mode. I did have the time to make some minor changes in the AI to get them to act slightly differently, but most of my time was spent working with Chris on his issue. When we figured out the solution he was able to make the fix in an hour. While I was struggling on Saturday, our lead designer got his hands dirty with some unrealscript. He went in and messed around with attaching lights and changing around some values in the AI to make them more to his liking as well as some other miscellaneous tasks. I love having a designer who knows how to do this.
The Art team continued working on assets. While our enemy guy was still out, our lead artist started making way on the gun. The gun we have been using is the default UDK one. The other artist made the assets that you will see in the video below. The doors, walls, floors and roof were done by him last week end.
The level designers took the time to make their levels more interesting and added in various different touches and they are starting to really come through, as much as they can with the amount of meshes they have. I had Bryan, our lead designer, make a video of a run through for me (Thanks Bryan). This is where the whiteboxes are right now. They are slowly moving away from BSP (the blue checkers) and adding in the assets they can. We have started adding in bots in different parts as well. The clip below was pretty loud on my computer so you may want to turn down your speakers if you have them on.
Through this you can see a few different things. The first thing you notice is the text greeting a tester. We have builds that go out every week that we then have tested by a bunch of Freshmen and Sophomore Game Dev students. We have a Senior who is assigned to our team who tells them what we are looking for and instructs them on anything we need from them and vice versa. He is essentially the liaison between our team and the QA testers. They report different bugs to us on everything from level design to programming bugs. The bug reporting is handled through a project management software.
The video shows some of our main mechanics early on. Our two weapon fire modes of the push back gun and the attraction bullets, which works similar to the pipe bombs in Left 4 Dead. The bullets really draw out an issue in how the AI are currently working and will probably be my next task. Right now they will path find to where you are and then move there. They don't check to see if you have move until they get there. I'll need to do something about this.
Looking at this video I'm liking the progress. All three levels were done since the start of this semester. All of the art is new as well. The AI is being subclassed from the base AI I made last semester. The weapon was easy to make since we could base it off of the classes that are already in UDK. While we may be done with three weeks about half of that was design and brainstorming.
Saturday, January 29, 2011
Making of a Student Game: Week 2
Week 2: 1/16->1/22
For a second I thought I would miss this weeks post. Luckily, I had the time this morning before I start the rest of my day. Week two of our senior team project was pretty typical.
The designers ended with different amounts of completion on their whitebox for their levels. The three of them are taking on the first levels. We are using level streaming in our game in order to make the levels flow better. For those who don't know, level streaming is a pretty standard concept that happens in games you play without you knowing. What may seem like one level is actually different parts of that level glued together and loaded at different times. The load normally occurs when you are in some narrow and closed space, such as a cave tunneling through a mountain, or a long corridor or hallway in a building. One level is loaded and the other is unloaded once you make it through. One reason that this is done is to prevent one large load time up front of a level so you can play quicker. A few of the designers have started putting this in and working with it to make it flow.
They have a bunch on their plate since a lot is introduced in those first few levels. The gun's primary fire, destructible supports, and introduction of your first enemies happen in the first level. The second level is the introduction of the magnetic environment, the weapons secondary fire, and a quick encounter with the second AI type. The encounter requires no fighting, it is only a sighting in the distance. The third level is the introduction of the cold environment, and a new bot type.
While sitting in on the meetings that the designers have, it is interesting to hear the solutions they come up with in order to actually handle some of their tasks they need to do. How do you introduce an enemy in a way that doesn't allow you to hurt them? They have come up with several different ways, such as seeing it on the other side of a window or seeing it move by in a passing vent or under you as you move down a catwalk to name a few. This way the player can see them and wonder or fear what it may be.
The artists have continued on their planned path as well. The lead artist is conceptualizing the various different art pieces that are now needed in the new levels. Evan, one of our artists, has been working on the first of three enemies. It is modeled and the texture maps have been completed. He also started work on the animation for that bot. It is coming out pretty sweet. Our third artist concepted and started work on one of our major visual features, a tram hallway. It will be used throughout all of the levels as something that is familiar. The idea is that this hallway runs the length of this ship. He also started working on making modular hallways.
On the programming side we have been moving along. The AI have been given different meshes (two are place holder and one is the bot Evan made). This part was pretty easy since all I had to do was subclass our base AI and assign the subclasses different models. Although a bug occured while doing this. I am looking into what is making them blink. I found some leads and will follow up with them next week. I started on giving the AI slightly different attributes. I worked with Chris on getting the weapon together as well. He is still adjusting to UDK but we have decided on a path for him to take in order to get the gun moving along. The gun made no large mechanical change this week but the back end of it moved around quite a bit.
Greenlight for this semester is next week and we are moving along so none of us are overwhelmingly concerned about it. We haven't got what the teacher is looking for exactly yet for this milestone. However we have been working off of our critique that we got from our professor last semester on our vertical slice. we figure if we stick to that it will handle most major concerns. It is also what we were planning on doing anyway for the most part so it doesn't put us off of our planned track.
Here is some concept art that I pulled off of our repository (version control is key to making games). I think blogger will let you click these to see them larger.
This is one of the Bots you will encounter in its early mock up stage.
Here is the concept behind what an attack may look like.
This is a second enemy mock up.
Imagine an enemy in a dark area and all you see is its glowing search lights.
An old hallway
This is a mockup of a level. This version is not what made it into the game, but it shows that you need to think things through before you start your work.
Right now the project is at one of the stages where a lot of conceptualizing has been done and we are working on getting the functionality to move along. Once assets and mechanics start appearing it will be interesting how quick stuff moves along. I am actually pleasantly surprised that the amount of programming work that needs to get done is actually lightening. Hopefully it stays this way and no surprise mechanics spring up.
Next weekend is the global game jam. Champlain is one of the official sites for the game jam and I'm sure a bunch of students will give it a try. But instead of jamming on the a new game, my team will be jamming our game. It is separate from the game jam but essentially instead of sinking time into the game jam we invest it into our game instead. So, come the end of next week we should have moved pretty far. Last time my team did this we got the large hanger made that you saw in that vertical slice video I posted.
Comments and feedback are appreciated.
For a second I thought I would miss this weeks post. Luckily, I had the time this morning before I start the rest of my day. Week two of our senior team project was pretty typical.
The designers ended with different amounts of completion on their whitebox for their levels. The three of them are taking on the first levels. We are using level streaming in our game in order to make the levels flow better. For those who don't know, level streaming is a pretty standard concept that happens in games you play without you knowing. What may seem like one level is actually different parts of that level glued together and loaded at different times. The load normally occurs when you are in some narrow and closed space, such as a cave tunneling through a mountain, or a long corridor or hallway in a building. One level is loaded and the other is unloaded once you make it through. One reason that this is done is to prevent one large load time up front of a level so you can play quicker. A few of the designers have started putting this in and working with it to make it flow.
They have a bunch on their plate since a lot is introduced in those first few levels. The gun's primary fire, destructible supports, and introduction of your first enemies happen in the first level. The second level is the introduction of the magnetic environment, the weapons secondary fire, and a quick encounter with the second AI type. The encounter requires no fighting, it is only a sighting in the distance. The third level is the introduction of the cold environment, and a new bot type.
While sitting in on the meetings that the designers have, it is interesting to hear the solutions they come up with in order to actually handle some of their tasks they need to do. How do you introduce an enemy in a way that doesn't allow you to hurt them? They have come up with several different ways, such as seeing it on the other side of a window or seeing it move by in a passing vent or under you as you move down a catwalk to name a few. This way the player can see them and wonder or fear what it may be.
The artists have continued on their planned path as well. The lead artist is conceptualizing the various different art pieces that are now needed in the new levels. Evan, one of our artists, has been working on the first of three enemies. It is modeled and the texture maps have been completed. He also started work on the animation for that bot. It is coming out pretty sweet. Our third artist concepted and started work on one of our major visual features, a tram hallway. It will be used throughout all of the levels as something that is familiar. The idea is that this hallway runs the length of this ship. He also started working on making modular hallways.
On the programming side we have been moving along. The AI have been given different meshes (two are place holder and one is the bot Evan made). This part was pretty easy since all I had to do was subclass our base AI and assign the subclasses different models. Although a bug occured while doing this. I am looking into what is making them blink. I found some leads and will follow up with them next week. I started on giving the AI slightly different attributes. I worked with Chris on getting the weapon together as well. He is still adjusting to UDK but we have decided on a path for him to take in order to get the gun moving along. The gun made no large mechanical change this week but the back end of it moved around quite a bit.
Greenlight for this semester is next week and we are moving along so none of us are overwhelmingly concerned about it. We haven't got what the teacher is looking for exactly yet for this milestone. However we have been working off of our critique that we got from our professor last semester on our vertical slice. we figure if we stick to that it will handle most major concerns. It is also what we were planning on doing anyway for the most part so it doesn't put us off of our planned track.
Here is some concept art that I pulled off of our repository (version control is key to making games). I think blogger will let you click these to see them larger.
This is one of the Bots you will encounter in its early mock up stage.
Here is the concept behind what an attack may look like.
This is a second enemy mock up.
Imagine an enemy in a dark area and all you see is its glowing search lights.
An old hallway
This is a mockup of a level. This version is not what made it into the game, but it shows that you need to think things through before you start your work.
Right now the project is at one of the stages where a lot of conceptualizing has been done and we are working on getting the functionality to move along. Once assets and mechanics start appearing it will be interesting how quick stuff moves along. I am actually pleasantly surprised that the amount of programming work that needs to get done is actually lightening. Hopefully it stays this way and no surprise mechanics spring up.
Next weekend is the global game jam. Champlain is one of the official sites for the game jam and I'm sure a bunch of students will give it a try. But instead of jamming on the a new game, my team will be jamming our game. It is separate from the game jam but essentially instead of sinking time into the game jam we invest it into our game instead. So, come the end of next week we should have moved pretty far. Last time my team did this we got the large hanger made that you saw in that vertical slice video I posted.
Comments and feedback are appreciated.
Wednesday, January 12, 2011
Making of a Student Game: Week 1
Monday we had a meeting in the morning with all the game dev students from all of the senior team classes to make sure that everyone was on the same page. It went over what was needed by the end of the week. It was pretty standard stuff for what you would expect from a first day of class. They outlined everything we would need to know and what milestones we had to meet.
That night we did a team building group activity and the entire team (except 1 person who couldn't make it) went climbing. 4 of the 10 people in our group are climbers so we used that as a go out and have fun together team building exercise. I am one of those climbers so of course I enjoyed it, but I think everyone did.
Wednesday and Sunday we got together for our first biweekly meetings. we went over the main issues for the semester and brainstormed ideas. We covered different ideas on how to fix issues that we had. The first thing that was tackled was the Enemies. They just didn't look scary, see the previous post Game Overview for a video. So we came up with different ideas and through out ideas. Very quickly we dropped the idea that we were fighting swarms. Instead images such as that torture probe from star war or the sentinel from the matrix as other directions that we could go in. One of our artists also made a few quick models of what they would look like before the meeting and showed those to us.
We then addressed the mechanics that we were missing. We decided to try and use the physical environment more in the game. So we are adding in the ability to shoot pipes and have steam come out. then if you turn on the heat environment it will light on fire and damage what walks through it. then use the cold to turn it off again. We can also drop crates onto enemies to kill them by shooting their supports. This could also be used to jump up to another walkway or something else like that. Essentially we are going to be adding in more fun ways to kill the enemies. These two already have prototypes that were made by our lead designer.
We are also going to change the gun up substantially. The main gun will be more of a push weapon. This is because we noticed that when the AI jumped onto a railing and we shot them off it was awesome to see them fall to their death. so we want to see if we can do this more or replicate it to be used more. The secondary fire has been iterated a few times but as of the meeting Sunday evening it has become a luring weapon. Originally it was to be a suction grenade type thing, where all the enemies and boxes around would be pulled to it. but now it is more like a pipe bomb in left 4 dead where they are all attracted to it. The frequency that this can be used will have to be tweaked.
The lead designer, Bryan, has put up a tutorial on youtube so that the others can learn how he put these mechanics into the game. the first few seconds of the video will show the dropping of crates onto enemies.
We have also developed our story a lot further than it was before. We now have some ideas for who the AI who is helping you is. Our producer came up with a great narrative story behind him that, I know I couldn't do justice to. But I'll Try to summarize it. The ship you are on originally had 3 AI, The defensive (the guys you fight, the navigation, and Eli (your friendly AI). Something went wrong and Eli somehow ejects from the ship. years later we find him, or a damaged/later version of him, with the player as he makes it to the ship. Eli has motives to return to the ship as well. We are toying around with two different concepts on why that is. The first has to do with him trying to return to the ship in order to return to the place were years ago as the initial take over by the enemies occurred Eli failed to navigate a child to safety. He has since returned on a few occasions to try and fix the wrong that occurred there. In the second idea, Eli has since forgot some of what happened there through data corruption over time. He still know that he wanted to return for some reason though and continues to try to find the person who can bring him back. The Eli character is still up in the air about exactly what his motives are, but that is where we are right now.
The story about the ship and what you will progress through over time is being developed. There is now a theme of following the gold (or whatever substance we decide to make it). so in our levels you will see bots taking gold somewhere and you want to figure out why and where. As you progress you run into the defensive security in the ship that has caused all of these issues. We have different encounter ideas as well but I feel like that is a bit too much detail for now. Ask about them if and I'd be more than happy to comment on them.
The designers have started white boxing the first three levels and are making good progress from what I could tell as I was listening in to their meeting (I was coding away at my computer) I have looked into how to make the AI states work a bit more efficiently, as well as fix some bugs from last semester. I made a quick prototype of the force gun as well so that designers could use it in their white boxing.
The other programmer is new to UDK and is learning it as he goes, just like I did last semester. He has actually picked it up pretty fast. He is working on making the weapon that will be in the game. So he has been looking into how to go about doing that.
The artists are making asset lists and concepting out what those assets will look like. They have also been involved in the design meetings and brainstorming. I do not have any of these to put here but I'll ask the artist if they can post some work and when/if they do I'll link it.
Any questions or comments are more than welcome. Feedback on what you want to hear more or less about are great too. Future posts will include the about me and of course next weeks update.
That night we did a team building group activity and the entire team (except 1 person who couldn't make it) went climbing. 4 of the 10 people in our group are climbers so we used that as a go out and have fun together team building exercise. I am one of those climbers so of course I enjoyed it, but I think everyone did.
Wednesday and Sunday we got together for our first biweekly meetings. we went over the main issues for the semester and brainstormed ideas. We covered different ideas on how to fix issues that we had. The first thing that was tackled was the Enemies. They just didn't look scary, see the previous post Game Overview for a video. So we came up with different ideas and through out ideas. Very quickly we dropped the idea that we were fighting swarms. Instead images such as that torture probe from star war or the sentinel from the matrix as other directions that we could go in. One of our artists also made a few quick models of what they would look like before the meeting and showed those to us.
We then addressed the mechanics that we were missing. We decided to try and use the physical environment more in the game. So we are adding in the ability to shoot pipes and have steam come out. then if you turn on the heat environment it will light on fire and damage what walks through it. then use the cold to turn it off again. We can also drop crates onto enemies to kill them by shooting their supports. This could also be used to jump up to another walkway or something else like that. Essentially we are going to be adding in more fun ways to kill the enemies. These two already have prototypes that were made by our lead designer.
We are also going to change the gun up substantially. The main gun will be more of a push weapon. This is because we noticed that when the AI jumped onto a railing and we shot them off it was awesome to see them fall to their death. so we want to see if we can do this more or replicate it to be used more. The secondary fire has been iterated a few times but as of the meeting Sunday evening it has become a luring weapon. Originally it was to be a suction grenade type thing, where all the enemies and boxes around would be pulled to it. but now it is more like a pipe bomb in left 4 dead where they are all attracted to it. The frequency that this can be used will have to be tweaked.
The lead designer, Bryan, has put up a tutorial on youtube so that the others can learn how he put these mechanics into the game. the first few seconds of the video will show the dropping of crates onto enemies.
We have also developed our story a lot further than it was before. We now have some ideas for who the AI who is helping you is. Our producer came up with a great narrative story behind him that, I know I couldn't do justice to. But I'll Try to summarize it. The ship you are on originally had 3 AI, The defensive (the guys you fight, the navigation, and Eli (your friendly AI). Something went wrong and Eli somehow ejects from the ship. years later we find him, or a damaged/later version of him, with the player as he makes it to the ship. Eli has motives to return to the ship as well. We are toying around with two different concepts on why that is. The first has to do with him trying to return to the ship in order to return to the place were years ago as the initial take over by the enemies occurred Eli failed to navigate a child to safety. He has since returned on a few occasions to try and fix the wrong that occurred there. In the second idea, Eli has since forgot some of what happened there through data corruption over time. He still know that he wanted to return for some reason though and continues to try to find the person who can bring him back. The Eli character is still up in the air about exactly what his motives are, but that is where we are right now.
The story about the ship and what you will progress through over time is being developed. There is now a theme of following the gold (or whatever substance we decide to make it). so in our levels you will see bots taking gold somewhere and you want to figure out why and where. As you progress you run into the defensive security in the ship that has caused all of these issues. We have different encounter ideas as well but I feel like that is a bit too much detail for now. Ask about them if and I'd be more than happy to comment on them.
The designers have started white boxing the first three levels and are making good progress from what I could tell as I was listening in to their meeting (I was coding away at my computer) I have looked into how to make the AI states work a bit more efficiently, as well as fix some bugs from last semester. I made a quick prototype of the force gun as well so that designers could use it in their white boxing.
The other programmer is new to UDK and is learning it as he goes, just like I did last semester. He has actually picked it up pretty fast. He is working on making the weapon that will be in the game. So he has been looking into how to go about doing that.
The artists are making asset lists and concepting out what those assets will look like. They have also been involved in the design meetings and brainstorming. I do not have any of these to put here but I'll ask the artist if they can post some work and when/if they do I'll link it.
Any questions or comments are more than welcome. Feedback on what you want to hear more or less about are great too. Future posts will include the about me and of course next weeks update.
Making of a Student Game: Game Overview
Our game is a FPS in space. Our designer from last semester made a great video giving the basics on the game. To save you a lot of reading I have embedded it below. Our team last semester consisted of one artist, one designer, one programmer, and one producer with a background in both business and design. This semester we have that same team with some new additions. We have two more artists, three more designers, and one more programmer. This makes our team 10 strong and we are happy with these numbers.
now that you know the basics, I'll go over how we got to that point.
Art:
When coming up with the game idea we wanted to avoid having to model and animate a person due to the time it would take to create it. With one artist to make the environment, characters, and everything else you see in the game. It wouldn't have been feasible to do this in the semester. So we decided to make it first person so you couldn't see the character, who is assumed to be human but never actually stated. We made the enemies swarms so that they could be represented by place holder particle effects. The designer and artist, who had worked in UDK before, knew that UDK could do amazing stuff with lighting and post-process volumes. This put points in UDK's corner for being picked as our base.
Design:
Our designer had a large amount of experience in UDK and knew a lot about how to use it. He would be able to use Kismet to help do smaller programming tasks, leaving me more time to work on the main chunks of code I needed to do. I liked the thought of that. He also knew how to work with the lighting in UDK and a lot of its other features.
Programming:
I was open to learning something new. I had done it the semester before in our Production II class where we made a smaller game in one semester. I picked up Unity and C# and liked that I was broadening my skill set. So when they proposed it I wasn't turned off by the idea. I also have an interest in working with AI programming. So our game was likely to have AI in it in some way or another.
We originally were considering Unity, UDK, and XNA. Then our game concept began to develop and as it did we went with UDK. Out unfolded what you saw in the video.
As we start this semester we still have a long way to go. As of the end of last semester our combat was missing something, we couldn't put our finger on it though. Our enemies needed a revamping graphically. The weapon was basically the stock UDK gun with only a few tweaks to it. I believe the Gun was the only asset in the vertical slice that wasn't done by Keith, our artist. While there was some concept art done up for it, we never started the model since it would take some time to complete and we had to populate the environments we were already doing. By the end of this semester we need to present a finished and polished game with at least 30 minutes of gameplay.
In the next post, Week 1, I will detail the results of the brainstorming sessions and work that we did this week.
now that you know the basics, I'll go over how we got to that point.
Art:
When coming up with the game idea we wanted to avoid having to model and animate a person due to the time it would take to create it. With one artist to make the environment, characters, and everything else you see in the game. It wouldn't have been feasible to do this in the semester. So we decided to make it first person so you couldn't see the character, who is assumed to be human but never actually stated. We made the enemies swarms so that they could be represented by place holder particle effects. The designer and artist, who had worked in UDK before, knew that UDK could do amazing stuff with lighting and post-process volumes. This put points in UDK's corner for being picked as our base.
Design:
Our designer had a large amount of experience in UDK and knew a lot about how to use it. He would be able to use Kismet to help do smaller programming tasks, leaving me more time to work on the main chunks of code I needed to do. I liked the thought of that. He also knew how to work with the lighting in UDK and a lot of its other features.
Programming:
I was open to learning something new. I had done it the semester before in our Production II class where we made a smaller game in one semester. I picked up Unity and C# and liked that I was broadening my skill set. So when they proposed it I wasn't turned off by the idea. I also have an interest in working with AI programming. So our game was likely to have AI in it in some way or another.
We originally were considering Unity, UDK, and XNA. Then our game concept began to develop and as it did we went with UDK. Out unfolded what you saw in the video.
As we start this semester we still have a long way to go. As of the end of last semester our combat was missing something, we couldn't put our finger on it though. Our enemies needed a revamping graphically. The weapon was basically the stock UDK gun with only a few tweaks to it. I believe the Gun was the only asset in the vertical slice that wasn't done by Keith, our artist. While there was some concept art done up for it, we never started the model since it would take some time to complete and we had to populate the environments we were already doing. By the end of this semester we need to present a finished and polished game with at least 30 minutes of gameplay.
In the next post, Week 1, I will detail the results of the brainstorming sessions and work that we did this week.
Making of a Student Game: Introduction
I have been inspired by an acquaintance of mine to try and get at least one blog post written a week. She is doing the Wordpress blog post a week challenge. Her blog covers a variety of topics, but caught me initially due to its perspective and pointers on management and leadership. It is written by someone with years of experience on that topic. I encourage you to check it out at blog.socketsandlightbulbs.com.
I decided to blog about my experiences working on my Senior Team Project at Champlain College. This is a two semester long class that all seniors in the game development program have to take. The first semester consists of teams of 3-4 students from different backgrounds (programming, art, design) working together to make a vertical slice of a game that they will make by the end of the year. In the first semester there were 15 teams working on a variety of projects. At the end there is a big presentation where each team gets 10 minutes to show what they have done in the semester. During this presentation they are also trying to convince the game faculty why their game is feasible to move on next semester as well as pitching it to other students to get them interested in joining their game.
The pitch to the faculty consists of showing what we have done so far with the number of students we have as well as a plan for the next semester. We need to prove that the game can actually be finished with one more semester. This pitch along with our work effort over the semester are the major determining factors in who goes on. The pitch to the students is to get them excited about the project so that they would want to work on it the next semester if their team gets cut. For example in our project part of our pitch to the design students is that they will be able to own at least one level as a portfolio piece that they could then point to in an interview and say I made this.
Moving to the next semester 10 of the teams were cut this year, leaving only 5 left. The number of teams change from year to year as the number of students change from year to year. The teams that are cut are split up and the students are placed on teams that require their skill set. The teams that move on could request to have certain students on their team with a reason why.
My team was one that went forward to the next semester (this semester), which is something that I am really happy about. On top of that the students that were put on our team were all great additions. Those of us who were on the team last semester are the leads our disciplines this semester. So, for example, I am the lead programmer on my project.
So in an attempt to keep this post from becoming too long I'll end here.
Future posts will include:
If you have any questions, want more information about any part of this post, or just have something to add please leave a comment.
I decided to blog about my experiences working on my Senior Team Project at Champlain College. This is a two semester long class that all seniors in the game development program have to take. The first semester consists of teams of 3-4 students from different backgrounds (programming, art, design) working together to make a vertical slice of a game that they will make by the end of the year. In the first semester there were 15 teams working on a variety of projects. At the end there is a big presentation where each team gets 10 minutes to show what they have done in the semester. During this presentation they are also trying to convince the game faculty why their game is feasible to move on next semester as well as pitching it to other students to get them interested in joining their game.
The pitch to the faculty consists of showing what we have done so far with the number of students we have as well as a plan for the next semester. We need to prove that the game can actually be finished with one more semester. This pitch along with our work effort over the semester are the major determining factors in who goes on. The pitch to the students is to get them excited about the project so that they would want to work on it the next semester if their team gets cut. For example in our project part of our pitch to the design students is that they will be able to own at least one level as a portfolio piece that they could then point to in an interview and say I made this.
Moving to the next semester 10 of the teams were cut this year, leaving only 5 left. The number of teams change from year to year as the number of students change from year to year. The teams that are cut are split up and the students are placed on teams that require their skill set. The teams that move on could request to have certain students on their team with a reason why.
My team was one that went forward to the next semester (this semester), which is something that I am really happy about. On top of that the students that were put on our team were all great additions. Those of us who were on the team last semester are the leads our disciplines this semester. So, for example, I am the lead programmer on my project.
So in an attempt to keep this post from becoming too long I'll end here.
Future posts will include:
- The Game Overview: so you know what we are making and who the team consists of
- About Me: more about the author of these posts
- Week 1: a description of what went on this week since the first week of classes are not even over yet
If you have any questions, want more information about any part of this post, or just have something to add please leave a comment.
Subscribe to:
Posts (Atom)
