Overview: This article is a summary of some of the things I learned about game development as a Game Design and Development Student at FullSail Real World Education. It is meant as an accompaniment to the Developer's Diaries found in the following pages. Though extensive, these diaries serve as a journal of the entire development of a game demo. For the speed-readers, the most significant dates are 11/24, 12/8 and 12/15; these are the Alpha, Beta, and Final presentation dates respectively.
As I browse the internet, it seems there is no shortage of people willing to share advice on game development. They cover how to break into the industry, how to stay in, and in the occasional post-mortem they even tell how the game was made. Of all the various ways to convey game knowledge, the developer's diary has become my favorite. It covers from start to finishuwith a few holes in betweenuthe entire process of a game's development. I created a dev diary of sorts of my own during my final project at FullSail. Originally, the entries were scrawls of scattered comments and expletives that I typed in between builds into Notepad. The version you'll read has been reviewed by MSWord and formalized into complete sentences.
Our game, Aeons of Strife is a cross between a MMORPG and a FPS. It takes the real-time action of the First Person Shooter with the setting and combat elements of the Role Playing Game. In the three months that the four of us we worked on the project we found a lot of things out about ourselves, as well as the game development process.
In the beginning there was the Design Document, and it was good. A good design document is the basis of a good game. For the veterans out there reading this article, that statement is probably nothing you haven't heard before. With that said, there are many people, newbies and oldbies alike that do not heed that advice. Our DD was not limited to just the look, but the feel of the game as well. In order to keep a game consistent, everyone's vision of the game has to be consistent from beginning to end. A game charter and a game vision will help remind you of what kind of team you were when you first started developing; before the arguments, before the unhandled exceptions (or segmentation faults for you Unix coders), and before everything in general became stressful.
Change is Constant
From day one, the game is always changing. It will continue to do so until the day you burn the Gold CD or start on the sequel. In my experience, there were two primary reasons for why that was known to happen.
Of the two, the first is technical realization. This is when the idea or concept for a certain module doesn't work, doesn't work as fast, or look as cool as it was supposed to do. The failure of one module does put a stop to an entire project if it has adequate technical and design documentation.
My second major reason for why games change is a term known as feature creep. It is a common term in gaming, used to denote how often additional gameplay elements creep their way into a project.
In my experience, "Wouldn't it be cool ifa" is easily both the most ominous and auspicious phrase in all of game development. It can be the start of such sentences as "Wouldn't it be cool if Samus and Kirby fought to the death?", which is the premise Super Smash Bros. This is a game that breathed new life into the fading Fighting Games genre, and has spawned one sequel thus far. Contrastingly, "Wouldn't it be cool if we made a game about that new Spielberg movie with the alien?", is a phrase that I'm certain someone now regrets having said.
On a related note, there is another term I have become accustomed to, and that is feature kill. It's what happens when you know you have a time limit for a project and want to keep it from getting bloated with unnecessary features. To elaborate, if feature creep were a creature named feep, feature kill would be the shotgun that shoots it dead. As a result of feature kill, you may end up killing off an exceptional feature that just might have made the game for your target audience.
In the case of our game, two of the three key gameplay features that we received the most praise for in our game were scheduled in after our Alpha milestone. In general, your first priority when developing a game is to maximize the funativity for the consumer. It is also your responsibility to know that with each new proposed feature the expected risks and rewards to both team and consumer must be weighed and a decision must be made.
There is a strange interdependent relationship between artists and programmers. Some people see them as the guys down the hall (in the case of FullSail, they were across the room), and I would imagine the inverse is true as well.
Two Different Worlds
Programmer types and artistic types are based in the left and right hemispheres respectively. Separately, the work of an artist is something that can be seen or heard but not interacted with, and the work of a programmer is a series of nonsensical words. In the game world, these two hemispheres come together to make a finalized product. The person that serves as the interface between the two worlds has to know that fact and reinforce it in the people he works with accordingly.
A Good Team is Hard to Find
Finally, a good game is nothing without a good team to develop it. Codus Vivendi was a very balanced team of four. We each had a specific interest in a different part of the game (Engine Mechanics, Physics, Networking, etc.); for that reason, when it came down to handing out responsibilities for the game there was little think about. Working on something you believe in makes you work that much harder. That applies to both the code we wrote as individuals, and the game as a whole.
My name is Vernon Dunmore. I am one of four members of the team Codus Vivendi.
I spent the last year of my life at Full Sail Real World Education, in the Game Design and Development Associate Degree program. The last three months of the program are devoted to a final game project. Students break into groups of 3 u 6 and create a game of their own design. Classes are scheduled from 9-5 three days a week, and the rest of the scheduling is left to the individual groups.
The game we created is a cross between an MMORPG and an FPS. We wanted to take the intensity of the FPS and give it the substance and ambience that is associated with the MMO. The classification we came up with to describe this cross-genre game is MORF3 , which stands for Multiplayer Online Role-playing First-person Fantasy Fighter. We named the game Aeons of Strife. The following is a journal of the events that occurred over the course of our development.
12:14 AM 09/30/2004
Today was the first Asset Production & Design class, and first presentation of our game projects. There were a lot of racers, some RTS games, a flight sim, a Smash Brothers Fighter, and us. Our enthusiasm for our game showed during our presentation of our idea -- we touted our wish list features (B List) as core features.
As a result, when we presented our idea there was a noticeable doubt by the teachers, TAs, and students of our expectations and capacity. And by 'doubt', I mean that Rob Garfield (the APD course director) loaded up an imaginary hand-gun and pantomimed blowing his brains out the moments after we said the word oMMOo. I did damage control by stating melee, magic and ranged combat were our core elements. I also said that we would add the fanciness once that was finished, but couldn't tell how well that went over.
After class I had a chat with Rob and I reiterated how we planned on prioritizing the tasks that lay ahead of us. He suggested that I make a list of the minimum amount of game elements needed in order of importance. We called this mini-maxi-hierarchization. Don't bother looking it up, it's not a real word.
It seemed to me that the members of Codus Vivendi all had different ideas of what our game will become. After class we clarified the game vision and redefined the core components necessary to finish. I plan to be able to refer to that throughout the course of the project.
5:23 PM 10/4/2004
I went over to Jeff's place to talk with him about the technical specifications. He is a very adept programmer, however at this stage he needs a little motivation to get started. We outlined in even greater detail the exact order in which tasks need to be accomplished in order to create our core game. Our next move consists of nailing down the APIs and the software we will use. We also need to design more game elements (as we did today), and prioritize the details of our core technology.
5:00 PM 10/5/2004
We started to assign group roles today during an in-class meeting. The tasks are well fit for each member; we are all doing things relative to the capacities that we're interested in doing once we get out in field.
Project Lead: Vernon Dunmore
Tech Lead: Jeffrey Houde
Design Doc Manager: Vernon Dunmore
Tech Doc Manager: Jeffrey Houde
Asset Director: Vernon Dunmore
Render Czar: Jeffrey Houde
Audio / Physics / Collision Czar: Petrus Bonang
Networking / Interface Czar: Jeff Marr
AI / Gameplay Czar: Vernon Dunmore
The group roles are pretty straightforward, so I won't explain them any further. The Czar system is a more specific group hierarchy that states that a specific person is in charge of a particular section of the game. Furthermore, the Czar makes the final decisions about the implementation of his own module, since he is going to be the primary person writing it.
We also began a walkthrough for the game; what would occur, when, how, etc.
12:56 PM 10/7/2004
Slowly realizing that our design documents aren't being produced as fast as they need to be. We are slightly behind on some, but since I've never made one before, I can't be sure. The course syllabus has deadlines for components of the doc, but the amount of detail I need to put into it for my particular project is still unclear. I'm just going to put everything I can think of into it to leave no room for any oversights.
I have taken the brunt of the DD because it interests me, and because I want the rest of the group to have the time to work on the parts of their modules that don't really require heavy design. This is what we did last time in SGP, and I feel I caught it earlier than before, but it still concerns me. I will give some tasks to some people that relate closely to the work they will eventually do. Beyond that though, I want to be certain they can program. I am just going to design the rest of the game DD on my own, as soon as possible. Switching between tech and design mindsets is draining.
5:14 PM 10/11/2004
We are now later into the 'month', with sufficient documentation, but not superfluous documentation. Tomorrow after class we will meet to cover the complete details of our game.
Spread myself too thin working on all document aspects. I gave code-relative DD tasks to others, and am waiting on their completion.
Additions to the statistics system were made. Writing the spell / skill learning is a big dependency, that definitely needs to work, and soon.
JeffH is having problems getting animation in RenderWare to work, our solution is asking Troy, (a TA here who wrote the base RW wrapper that we use), how to go about fixing it.
Also, JeffM cannot get DirectPlay to work. I am going to look for information / tutorials about the API to help keep him going.
PeterB has no work to do, since NovodeX requires animation capabilities from JeffH. The current solution is to give him the Component Interaction Matrix, since he is covering our physics and collision detection, it only makes sense that he draw up the matrix.
I have most of the design document to myself, but it is disorganized and discontinuous. The solution for me is to leave myself time to polish details and have a competent non-group member look it over.
3:27 PM 10/15/2004
At a meeting last night, we got a small amount done. Half of the time the group seems unmotivated; I realize I need to create a sense of urgency, but don't know how to go about doing so.
Peter is apparently an artist, and a good one at that. I just asked the group if anyone could draw concept art and he volunteered himself. Most of our class sees him as shy, but I think he's just not vocally loud. But anyways, 'shy' people are not shy when they are with an individual or group of individuals that make them comfortable. I think that as a whole, we make him feel comfortable. His art is going to be very useful in terms of asset production. He grabs the intentions of my 'programmer art' and makes it look nice enough so that the artists don't vomit while looking at it.
12:45 AM 10/17/2004
JeffH took the initiative to continue work on the flowcharts and modules in the tech doc without being told to do so. JeffM is looking into the way NetZ handles things, and plans to incorporate some of their methods into his DPlay code. Peter began work today on a model that will map death animations through NovodeX to RenderWare. He has this week to do it, after that I need him to begin Collision Detection wrappers and physics.
A number of scattered arguments have occurred over the past week. In the past they've gotten to me. I wonder how a group can be unified if so much time is spent bickering. Some days are good, some days are bad, nothing more. I can't let one day make the project for me, or anyone I am responsible for.
12:50 AM 10/18/2004
It is early, but we're trying to keep the memory requirements low for our game. Since we have a limited number of PC models, we're looking into putting models into bins for rendering. RenderWare has some nice features that let you copy and reuse a model residing in memory, instead of reloading it. The Memory Decrease from using one load per model, to one model being cloned is 195K -> 47K.
Also, I'm trying out a different meeting format. I go through each member and call attention from people only when their issues are discussed. This way keeps people informed, but doesn't bombard them with things that don't relate to their code. This keeps unnecessary 'events' from happening.
I started formally scheduling the tasks for our project today. I always dislike having someone estimate the time it takes to do something they've never done before. The best thing appears to be this:
- Try to keep times low
- Keep an eye out for overestimation
- Allow those who overestimate by safety to do what they will - but make suggestions,
- Granularize tasks as much as you can. Of the two:
Write Paper ( 5 days )
Research Topic ( 1 day ), Write Outline ( .5 day ), Write Intro / Conclusion ( 1 day ), Write Body ( 2.5 days )
which task is easier to determine when it's behind?
10:28 AM 10/26/2004
A major risk came in the form of the network. Not the API being used, but the client / server setup (that means JeffH and not JeffM). Initially, JeffH wanted to make a zone server and a gateway server, in an MMO setup, shown in the diagram below. Since our game is a cross between an MMO and an FPS, the rest of us thought that might be too slow to keep up with the fast u paced FPS action we want in the game.
Today we had Tech Doc Sitdowns, which is when a TA (or two), and John Fairchild (the APD tech specialist) go over the tech document and point out the parts where they see holes in the technical design of our game.
We were told that the above setup would be too difficult to synchronize, and more importantly too slow. JeffH had a hard time letting go of his design, but after some heavy coaxing, we convinced him to handle all aspects of all regions on the same server. In the long run, this way is what's best for all of us in terms of finishing what we want in this project.
12:10 AM 10/30/2004
Client and Server are now connected. They transmit data, and the client loads a world specified by the server. A problem arose when the client tried to load a level asynchronously, but was resolved by just making it load outside of a thread. A bit of delay is caused by JeffH learning JeffM's network API. He has questions that he wouldn't ask if he wrote it. Fortunately, since they're roommates, Jeff can ask Jeff questions in person, as opposed to online.
JeffM is finally free to start working on input after fixing all of the network issues that were revealed during integration.
Assets are not in yet, and Peter is scheduled to start on Collision Detection. He can use generic shapes to start testing, but it will still prove more difficult to do without the real artwork. Our collision detection is core (obviously), and I am concerned with its completion so much that I've put it at the front. I considered rescheduling to have Peter do audio first, since test assets can be downloaded easily. We're scheduled to have collision and physics done by the Alpha milestone, and rescheduling Audio first would push those two to the brink of the deadline. I suspect that the schedule will take bumps over time and don't want to take that risk.
10:51 PM 11/1/2004
I am garnering confidence with the choices we made as a group early on. I am also making sure that the rest of CV knows that fact as well. Other groups (at least 2, by my numbers) currently do not have a working build. They have nothing showing onscreen.
We knew in the very beginning that our project would be a lot of work, and concluded that cutting a corner with RenderWare would be a good idea. A client model is now moving and updating on both DirectPlay server and client, and visible in JeffH's latest build. Peter is testing collisions with the 10/31 build, and I am drawing flowcharts for Npc Motion.
With my Asset Acquisition, Scheduling, and Argument Resolving, I feel I have a lot to do before the AI. However, I can't allow myself to be the weak link in this chain. I am also personally ensuring that the artwork for this game is exceptional, and beyond what anyone has ever seen come out of FullSail artists.
8:01 PM 11/4/2004
Yesterday I met with Zaid about the Female Chainmail Model. He tried to show me the file, but it was corrupted. _And_ he said he made a JPG, but it was apparently missing from the drive he used to give me the files. For the second time, he brought James with him, whose artwork is not what we're looking for right now. Zaid seems unreliable at the moment, but a flash of inspiration came to me today. I saw a spark of competition in his face when I told him that Rory, our Modeler, made a very good model. If necessary, I will play off of his competitive nature to get better and more consistent work from him. There doesn't seem to be any other way.
5:35 PM 11/5/2004
Earlier this week we found that some groups were going to lose members due to unforeseen circumstances. As a class we decided that some people would need to be picked up and added into other groups. CV lost no members, but after discussing it, we said we would be willing to take someone on to help us complete our B-Grade Features.
Given the list of potentials, we found a handful of people to be competent and compatible. While discussing with my group, I brought up the clichT of thinking that new people would expedite work, but that training and rescheduling could wind up dragging us down. By the end of the week some individuals married into other groups, and the stragglers merged into a new group. Ours remained unchanged.
I feel it is better than worse this way -- we don't have to sell someone new into our idea, or de-n00b anyone to our practices. But most importantly, we don't have to deal with another voice during heated debates.
5:39 PM 11/6/2004
After another check-up email, Zaid submitted the model, but I believe it is in Maya 6 format. Comparatively speaking, Rory is far more consistent and reliable. But we need more models, and fast. I have no problems with spending an hour of my time talking to someone outside of class if it means we get more content into our game.
8:30 PM 11/9/2004
I felt the need to re-inspire my group; to both remind us of what we're up against, and of what we're setting out to do. A lot of our classmates continue to have doubts about what we can do, and I reminded us of that fact. Most of the group was inspired, but one of us was not. His behavior would have been counterproductive if the rest of us were the types to allow that to happen. It is a bit strange, but by making the expectations of our classmates our competition I feel a renaissance of drive in my group as well as myself. Go figure.
7:49 PM 11/10/2004
Today was a very good day. It appears that the morale of the artists is affected by the work of the programmers, and the morale of the programmers is affected by the artists. Joel, The Art Director, came by and told us that our 2D Menus (JeffM) was queued to an artist that would start on it soon.
PeterB has test models as of Monday that he can use to visually test the collision detection algorithms that he has. And JeffH and I have the actual game model to use in our tests of our respective parts of the engine. We also spoke with Chops Washington about our spell & weapon models.
Near the end of the day, Erick Fenstermaker showed us his first pass of the Endres Pathway level. It looks good, and he is very excited about working on it.
Rory, our primary 3D Modeler, also seems comfortable with me personally, which I also like. I want to make the artists feel like they're not working, but more like getting paid to do what they want to do themselves. When you keep people feeling that way, they yield better work.
12:12 AM 11/18/2004
Today was an asset day. I spent the most of it exporting files from Maya6->5->RW.
Erick came by and showed us the forest minus the leaves. The normals of the leaves point to the sky, which means that you cannot see them if you look straight up from below. We thought up solutions to the problem, and came up with two. First, since the level is all outdoors, most faces are not back face culled, turning off back face culling for this level (or parts of it) might not be as bad as it would be in others. The second is adding in alternate faces for view from below. Both have reasons for why they work in this situation. We're asking him to make a small test level for us to test out our theories and make a decision on that basis.
2:39 PM 11/19/2004
Today was another asset day. There were no exports today, but I did have to glance over a first pass of the spell models. Chops hooked it up, each one looks nice. The fireball has planar aspects to it that won't render when directly behind, so it will have to change.
There was also some discrepancy between what we met about and what was in the actual asset list I sent him. I also had to give him a scaled model to be able to figure out the relative size of the projectiles that he was working on.
Today I put Rory on to the game Guilty Gear XX Reloaded. I designed our enemy similar to 'Faust' from that game. I really like how his transition from squatting to standing is so intimidating and disabling. I wanted the player to get that feeling the first time he attacks one.
I can finally get started on the Fight / Flee State, but I still need to write up some structures, and finish the flow charts so that I can just dive in without thinking about the dependencies.
9:58 PM 11/20/2004
Peter found another weird flaw today. The first was that the OBB's were oriented badly; the second is that getting the triangles from a world sector sometimes returns absolutely nothing. He's not sure whether the problem stems from NovodeX or RenderWare, but I told him I thought it was cool that he could even find a bug in a system that polished.
I put together a minor PowerPoint presentation today, just the basics. The ppt is complete with concept slides, expert slides, and things of that nature. We have an Alpha presentation on Wednesday. We're looking pretty good for Alpha, Peter is working on our death animations, and that's our big
B B+ feature.
3:09 AM 11/22/2004
We are closing in on our Alpha Build. Peter finished the Physics ahead of schedule; he's always good with that. He is working on NovodeX RagDolling stilll. I'm concerned that I am having him work on that too much. We still have yet to move on to audio. However, once he finishes that, and JeffM finishes the menu components, all of our core tech will be done.
The Engine runs at 90fps, which is ok, but that is without integrated AI, or anyone else in the world. I make note of this, because in addition to Project Lead, I also bear the title of Risk Assessor. However, I find it difficult to do so when my knowledge about the engine is limited to what I ask and decipher by reading the code of others. I try to keep myself informed though.
The client has a good connection, but I can see the server updates occurring as ticks in the game. It's not fluid, but it still looks nice. The level is lush and very RPG-esque. Our second level looks to be a cave, which to reinforce the FPS aspects with multiple levels, jumpoffs, etc. The level artist has no way of testing out his levels to see how they look in our game because he cannot output his Maya levels to RW. I think if he could do that the process would be expedited a lot, and he wouldn't need to wait 2 days for us to give him more work. He's very excited about the project, and I like that. I keep finding myself trying to find more work for everyone to do, since they're all ahead of schedule. But that's a good thing. I have rough concept art (as best as I can draw) in my Sketch Book for PeterB to make fancy. I plan to pass it by the group, and hand it off the the Level Artist in the evening.
12:21 PM 11/23/2004
Our Alpha build is due today. Late last night we finished integrating the majority of all of our Alpha expectations into the game. Peter is working with NovodeX still, and I have decided I want him to continue doing so, even though he won't make it in time for Alpha. He's worked hard on it, and if we're all putting this project on our resumes, he deserves to have this in the game. If time requires it, I'll schedule him to start the audio just to get that done, and then go back to attempting Ragdoll Physics again.
Last night was the first time the game felt like a game. The rudimentary (run here, run there) Articifial Intelligence looked moderately intelligent, the collision detection algorithms detected collisions, and the network....networked. With all that going on, JeffH and I joined the same server and began slaughtering a few defenseless NPCs. It was the kind of moment where you smile for so long that your face gets tired. It was then that JeffH said what we were both thinking; "Now it's starting to look like a real game". The collisions only checked PC Sword to NPCs, so we couldn't actually fight each other. Of course, that isn't to say that kept us from trying...
1:53 AM 11/24/2004
Alpha presentations occur in the morning. Earlier today, we put our perfect, spotless release build on the test machine at school that our games have to demo on and... it crashed. We ran the game on all of our laptops and found no errors. If we could run the game on the machines we use to develop tomorrow we would have very little to worry about. However, that is not the case.
As the designated Risk Assessor, I concluded that we needed a backup plan, and the group agreed. The error has some relation to the test machine having more than one NIC card. Since we cannot test on it tonight to see if the latest build works on that machine, we're going to make a safe version of the game. JeffH (Tech Lead) knows the engine best, and is currently making a dummy client which doubles as a server. If all else fails, it will be able to exhibit collision detection, ground clamping, input, 2d components and all the other stuff that will show some (not all) of the progress we made. Hopefully, 'all else' will not fail. Right now I need sleep...and then when I wake, I imagine I'll need some caffeine.
10:15 PM 11/24/2004
Alpha presentations were today. The classroom was filled with classmates, teachers, TAs, and a few unfamiliar faces that snuck in while the lights were out. The actual presentation part went fine. We all knew our slides and made decent transitions amongst ourselves. During the game demo part of the presentation, we came incredibly close to being completely 0wnt by Murphy's Law.
I said I didn't want to be dependent on the network for our game to work, and as luck would have it, the network was down today. We knew the server wouldn't be able to run on the test machine, and prepared for it by running a server on one of our laptops. However, with no network capabilities, and no way to run the server on the test machine, we had to drop to our last resort.
The test machine couldn't connect to any outbound ports, so we basically had a network game with no network. Right now, the server crashes if it does not find an outbound internet connection. And as we expected, it crashed today, much to our dismay. If it weren't for that quick backup plan that we made last night a we would have had absolutely nothing to show to the class other than a bloody front end menu. JeffH ran the single-player mode after the server crashed, and I made a seamless transition during my narration of the gameplay. We left a handful of would-be detractors only enough time to snicker at our temporary misfortune, but soon after their jaws hit the floor. The level was lush, the animations were seamless, and the trails were hypnotic.
Nonetheless, two bad things happened and we were prepared for the both of them. We went through the game presentation as though nothing happened and made note of the game basics, the weapon trails, and the time of day / fog effects. The lesson of the day is that Paranoia is good a sometimes.
We got the collision map from Erick Fenstermaker today. It's not exactly what we wanted, but we have no way of letting him test his levels without our game to check his progress. A while back, we considered making a sandbox for him to use. However, since he does not have RenderWare installed on his home machine he cannot export RW files on his own, thus rendering the rendering idea useless. To resolve the situation, we're making a diagram of where we want all the boundaries to be in our game.
Now I'm off to do more asset related work. We need game music badly, and our 2D Artist needs feedback on the buttons he created for us. Also, I said I would send some videos of our game out to my brother Jay (to use in our trailer video), but he will need some theme music to serve as background music for the intro video for as well. The log ends for now, but in all, today was a good day.
11:21 PM 12/11/2004
Today was Beta Reviews. That's when the teachers all tell us the things they didn't like about the Beta version of our game so that we can fix whatever was wrong with it. When we actually sat down, all they really could do was nitpick. Mind you, the reviewers (John, Justin, Joel) said that when they're at the point where all they can do is nitpick, then you know you have a good game. Their comments were little things like having different reticles for the different spells, or fixing minor bugs in the HUD and things like that. Fortunately, we'd actually fixed all the bugs that they had listed over the 2-day period since Beta. The most important note that was made was the fact that the combat system doesn't _feel_. It's as though it just doesn't respond to you. When Player A hits Player B, B does the stun animation, but you barely notice. There's no particle, no flash of light, no numbers popping up to tell you how much damage you did. Right now it's like a bread sandwich, the combat needs some substance. I suggested the incorporation of a pain flash into the game and the techs thought it would be good. Assuming Peter finishes the particles, we should do well to use that in combination with flashes, and maybe an RPG-style number pop-out for damage. Oh, and we also were told by one of the reviewers that our game is the best MMO to come out of our program in the entire time that he's been teaching here - which amounts to about 130 presentations or so. Forgot to mention that.
I'm also coping with the fact that a lot of my code is slowly fading out of the game. As it stands, there's no way I can balance the spell / skill leveling in time for the presentation in 5 days. However, the party system and damage functions should make it in, time permitting of course. I gave Jeff my Gameplay Sandbox and tomorrow I'll pick up the revised Fikk model and put them in so I can start using the AIs.
The AI was finally integrated today, they follow their scripts as they should. All that remains is adding additional objectives and manipulating their script files to make them a challenge. I'm tired. We meet tomorrow at 2 p.m. to finalize all of the new code we're putting in. I also need to edit the wavs and convert some songs to mp3 format. The code is getting chilly, seems like it might freeze over some time soon a
12:10 AM 12/13/2004
We're finalizing the game today. A code freeze occurs tonight. We're locking the code and fixing the bugs so that on Wednesday we have nothing left but the presentation to be concerned about. We've integrated the new (crash free) AI and the particle engine is being added in as I write. Since the last log the inventory screen has been finished, as has the character creation screen, combat log, and chat system. They told us not to add any more features and just polish a but there's nothing saying we can't do both now is there?
We had a few people connecting to our server earlier today. We have yet to get more than five people to log on at once, so our max server load stands at that for now.
For some reason I feel as though I'm the only one concerned about the project now. There's still a sense of urgency here, but I'm the most urgent of the four of us. Tonight I go back to my Asset Director role and find some cursors for our game to use. Tomorrow I'm editing the audio files so that they cue up closer to how they are meant to, and I'll see to it that we re-export the cave level. I might even see about Rory putting in a jump animation into the Fikks. That was missing from the last export. Right now the big deal is getting all the assets into the game. All these artists have high expectations for what we're going to do with their artwork, it's my obligation to them to see that their work is not in vain.
8:28 PM 12/13/2004
Today was a decent day. FullSail has a number of accolades that they give students in addition to Salutatorian and Valedictorian. I found out this afternoon that I was voted the Advanced Achiever by my class. What I gathered from querying the teachers here is that it's a combination of Most Likely to Succeed and Most Likely to be a good Class Commencement Speaker. The speaking part is nothing catastrophic, I'm quite comfortable with speaking in front of large groups a it just means I have to come up with something to talk about between now and the presentation date.
Particles are acting funny in the game; they aren't quite exploding correctly. Not trailing correctly, it also seems like they render on top of each other, even the transparent parts. I'm growing impatient with a lot of things about this project, including my group. It feels as though I'm the only one concerned with the stability of the project. But I suppose that's my job.
Nothing to talk about right now.
12:52 AM 12/15/2004
Today is the big day. Or rather, tomorrow is. I can't say that I've ever been more nervous about anything in my whole life. A big issue for me up until a few hours ago was the AI. After an integration they stopped strafing. Turns out that the engine was clearing a movement Boolean that wasn't being cleared before. It took two lines to fix.
I left JeffJeff's @ 12:00. I have been trying to keep my mind off the game. We were bug squashing for most of the night, and I set Twelve o'clock as my aeleave and stop thinking' time for the night. My computer is off to quell temptation. This entry is actually being written in a notebook.
The presentation tomorrow is two parts; first a powerpoint song and then a game demo dance. With the code pretty much finished, we've all had time to rehearse our speaking parts for tomorrow. In the back of my head, there's that concern that the game might crash. But that's always there. I trust now that JeffH fixed all the major bugs that we found during playtesting.
10:51 PM 12/15/2004
Final Presentations were today. Jeff Marr picked me up in his hunter green Eclipse and we headed over to McDonalds and picked up some breakfast value meals. I've been eating there way too often. For the last month or so, my refrigerator has held a total of 4 things: a family size tub of I Can't Believe It's Not Butter, a package of instant grits, parmesan cheese, and air.
We arrived at the Enzian and set up our game on the test machine. The release build crashed because of a network issue and the debug build ran slowly. However, as always, we came prepared. As I noted on prior journals, we have had a number of problems with the router the school uses, and we just brought JeffJeff's wireless router with us to the presentation and used that instead. Code Fusion also used the router for their 3D Hover Racer game; I believe they had similar sentiments. So, we ran the game on the safest system, our own, and used our own router.
After that, I took a few moments to 'ruminate' in the lavatory. It was a strange place because the Enzian is a sort of independent theatre, and as such they have all sorts of movie photos framed on every wall. My stall was subject to a faded Charlie Chaplin picture and a close-up shot of Alfred Hitchcock pointing to a pocket watch he had seemed to just pulled out of his pocket, with the time 7:20. It was quite odd, I attempted to get some higher meaning out of the time being there, but it...was really just a picture. It reminded me that I had something I needed to do today.
Just before the first group presented, all of Funk 'n Games (that's our studio name) were brought outside for a nice hype up pep talk. Liam Hislop reasserted the progress that we'd made in the past year, and in the past 3 months. He also made a joke about frenching some guy, but I made my best effort to forget the details of that statement. It had a noticeable impact on the others, I think it made us feel a lot better about presenting whatever we had, regardless of the progress that each of us had made.
We ( Codus Vivendi ) were the third group to present this morning, after Element X [ "They came from Planet X" ] and N20 ["1094 Racing"]. In retrospect, I think it was good that we went that early. The idea of the game doing something funny on the huge 30ft square screen in front of scores of people troubled me so.
The powerpoint part of the presentation went swimmingly, without a hitch. I made a few jokes to loosen up the crowd that coincided with the slides, and I actually think it made the rest of my group a little more comfortable talking to a room half filled with strangers about what was their life for the past three months.
And of course, after the powerpoint comes the game demonstration. I just pictured a big message box popping up on the front end menu saying "Bill Gates doesn't like you and needs to shut down"
During a break, I talked with a number of people. Many of them told us that it looked like a commercial game. I spoke with Dave Arneson, my former teacher for the Rules of the Game class about our game. If you know that name, he was the co-creator of the original Dungeons & Dragons. Some months ago, I spoke with him about the gameplay algorithms we would be using for spell / statistic leveling. He was visibly impressed and expressed an interest in seeing the final version of our game, with all the gameplay algorithms implemented and balanced.
There were also a few "dude, you had the best game"s from the people that had no desire to practice restraint. I just smiled. I knew that to be true from the very beginning, and I even told JeffH that back in May when we first started talking about our game. I just spent the last 3 months waiting for everyone else to realize what all four of us knew from day one.
When I got outside, after the very last presentation, I socialized with the people. A number of my classmates are going on from our associate degree program on to the bachelor completion program to get a second degree. The Jeffs are going on to the bachelor completion program, but Peter and I are not. When asked, I stated my plans to get into the job market as soon as possible. Peter and I both have Bachelor Degrees in Computer Science that we received just a few months before we enrolled at FullSail. The road ahead for the four of us -- as well as the rest of our studio -- is an undetermined one. We know where we want to go, but aren't certain how to get there.
This journal has two purposes, the first is to tell all the forum lurkers and gamedev.net one of the many ways they can get started on their path. The second purpose is to help us where we're going. It is my sincere hope that this article can be a reciprocation to all those involved in our project over the course of our development cycle and give them all the recognition they deserve for being a part of what was easily our magnum opus.
11:30 PM 12/17/2004
This is the final final entry. The prior entry was the end of my coursework at FullSail. Today was the graduation ceremony. As the "Advanced Achiever" award winner, it was my task to be the commencement speaker for my class. I only had 5 minutes to speak, but did my best with the time I was given. I noted where we started, what we learned and where we ended. In a year we moved from a text-based RPG tutorial to a full out 3d game written and designed by us. In another year, I believe we can continue to expect great things from all of these graduates, and there's no reason for anyone there to prove me wrong. A number of the people I called my friends walked across the same stage that I did with the biggest smile on their face. There is no doubt in my mind that our experiences (both social, and experiential) at this school will aid in our lifelong dream to become game programmers.