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.
Subscribe to:
Posts (Atom)
