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.

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.

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.

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:

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