48 Hour 4 Post-Mortem
Wolverine Soft 48-hour Contest Post-Mortem
WHAT WENT RIGHT
After getting into the swing 7 hours in, we planned how to work the animations quite well and that ended working flawlessly. That was one of the first things we planned; the concept didn?t need to be changed much ? the basic mechanics were what we wanted, even though the game cuts off before you save the robot princess. How to get mechanics into the game worked well.
Pre-made resources helped; we took an hour at the beginning to plan. As for the originality rule, you can?t be too original with the game play type, but it?s not too hard to make an original story. Frankly, originality wasn?t high on our priorities.
Even though we overshot what we wanted, it?s good that we came out with a game that was playable at the finish. We communicated well about what we wanted. From Fosdick?s POV, good audio is a huge part of good visuals, and it?d have been really awesome to have more time beforehand to do music. Something like the 9th Symphony, though awesome, would be out of place in Mario; I think the game was campy enough that our music fit. The cartoony sounds helped the things hold together, though we didn?t have time to insert unique attack noises for each monster.
WHAT WENT WRONG
It took hours to get the models working and displaying, we should have tested the process and engine outside the 48 hours, but we didn?t. We had a slight communication problem between us with what we needed; Mitchell?s engine can?t handle morphs, and moving vertices and altering meshes. It?s a feature to be added eventually. Materials was our main failure, Vishnu assumed that everything needed to be loaded into one mesh, instead of one file. The first 6 hours were hell, but after that pretty smooth.
I think we worked decently well together. It?d be a really good thing if we?d had the process down before hand so we could spend more time on game play. Vishnu was disappointed Fosdick didn?t find a true lawnmower sound, though we had fun listening to the noises found. Fosdick was unable to find a lawnmower to record in February in Michigan on 30 CDs worth of sounds. If we hadn?t spent 6 hours on debugging; we could have tweaked the sounds better to get them to line up better. Mitchell didn?t realize that SDL has a half-second delay on everything so he?ll probably strip that out of future products. Fosdick would?ve built up a sound library before hand if he?d known he could have.
The game needs some good bug fixes, but we probably need to make more complicated battle mechanics before we?d be interested enough to finish. We definitely need more animations for getting hurt, and feedback on whether damage was dealt.
Good: Everyone having some knowledge of programming. This helped us for example, when Ryan had been programming straight for a long period of time and was having problems with collision detection, I could look at it without the fatigue of having been programming for hours on end and come up with a solution. It also helped us that Don could make the title screen while Ryan worked on the main game.
Good: Prioritizing the things that needed to be done for our game. Although we weren't able to get everything into the game that we wanted in the 48 hours, by prioritizing well, we ended up with something that was playable with the features that were there.
Good: Taking into account the skills we had before settling on what kind of game we wanted to make. Since I knew I was going to work on sound, and that I couldn't do both sound and art, and Don and Ryan are not artists (or so they told me), we intentionally tried to come up with an idea that did not require lots of art or flashy art to be good. This helped us play to our strengths and put out a better game.
Bad: Not being able to plug in 360 controllers to use on the Training Room computers, and not having a USB hub. This prevented us from using our preferred control setup of two 360 controllers and a pen mouse for the player controlling the line.
Bad: It was very hard coming up with original ideas to fit with the theme. We thought we had something original in the beginning with the ships being made out of two lines, but at that point, our game play ended up essentially being a tank game. I pitched the line mechanic as a way of trying to get out of that and add more originality (as well as a third player component), but I am afraid that may just seem to be tacked on from a player's perspective.
-Andrew
*Don ? there?s at least one feature that didn?t make it into the game; they made a list of the most important elements, and worked their way down the list. I wish we?d had a better sleeping schedule, less sleeping in on Saturday.
We have been working on it, and making a lot of changes; we don?t consider it done, and we think it?s worth polishing up.
We were pretty inexperienced programming-wise, and our only familiarity with the engine was what we learned from WSoft. We made a game that ran and worked and you could beat it, that?s something. You couldn?t turn the game off unless you beat the level. There are a whole lot of bugs we weren?t expecting because we had so much and only implemented most of it at the end. We were fighting the engine the whole way. We agreed what was going into the game and Dale had an engine working by the first night, and after that it was just filling in the gaps. Warren says we had pretty good communication, and we had bugs mostly because we didn?t have time.
If Steve could have rewound an hour, the game would still end right away, but you wouldn?t notice as many problems. To get animation and game play, I could probably get them to run in 4 hours of dev session.
BAD The teammate with the most time had no experience, though he did lay down a killer soundtrack. Sound was consistent, and he did it with a microphone. I was listening later to two tracks he did just cycling them, it was fun. We really didn?t have much that a low or no-experience programmer could do, we really need something we can hand off to programming newbs; I think he wrote one long switch statement.
Going into it, the theme while entertaining and bringing to mind Mortal Kombat, where to go with it? We didn?t want to do the physics for a fighting game, so we went with a rock-paper-scissors mechanic we were inspired by a website. Taylor made the balancing for a 9-choice set of attacks. We definitely got in a good 4-5 first hours of deving and plan time, and then I went home and slept for a good 11 hours. Marc had originally planned on a more active planning game; he did leave for 4-5 hours to shoot a movie and do homework; I don?t know how much time he spent on the art but it would?ve been nice to have him around long enough to do more than one character set.
While I didn?t get the animation to work, when I did get it to work, there weren?t a lot of frames available to see how it worked. I have my complaints about the art, but it has good style.
Making each animation didn?t take that long. Once the animations went up the data management ability went down. First time he used the frame work. He wasn?t sure what the frame work was. Final concept wasn?t hard it just took a lot of image placement. Problem with the animations was that they overshot their abilities, in their desire to build a fluid combat system.
Paul took many pictures of mohudar over several hours. 12 attacks, 6 oh I?m hit, various victory poses. Jason?s into finishing the game. Everyone wants to see the photos. We originally wanted a beat-em-up. Further production is leading more towards that. We almost made a whack-a-mole game due to a collision detection problem. Once the process for handling pictures got down, it became pretty rapid. An editor to put photos into and align them was useful, but Paul didn?t know enough programming to use it effectively. Musician was only able to come in the last day. He did well when he was here, good music and few graphics, but not time for much else. The game was well salvaged in the dwindling hours of the contest. An animation to show which room you move into would have been very helpful. Jason?s random level generation was great. Paul was able to do his work on little sleep, but the main programmer definitely needs at least one full day of sleep to keep the thought process well. Needed an extra person to take photos of because the programmer needed to code, and Paul couldn?t photo himself. Had a little problem with the photos being blurry, maintaining a set distance, taking photos in not well lit areas.
Good that we did actually have a team from another school. The sponsors came in well, Microsoft and EA are easy to contact because we have alumni there who know the contacts. And they have always been very good to us.
A new MS rep was going to be in town and I talked with her, they sent more prizes than we asked for, and I was specific that we didn?t want small T-Shirts. It?s important to know how many people are expected, how many people show, how the prizes were chosen, and thank them.
24 people are the most people we?ve ever had, and 8 teams tie our highest number of teams.
Last year we lucked out well, with 5 working games coming out (that was the only year that ever happened). Don?t be surprised that many games don?t finish.
I can?t find an Activision rep to save my life. They used to have a campus rep, but they?ve disappeared. It?s good to have as many sponsors as possible.
We had to change up some of the rules, and the process started and ended too late b/c questions kept coming up. You want to have the rules set 2 months beforehand so that when you contact sponsors, they can see the new contest page. You should give sponsors at least a month, and I gave them 3 weeks. We didn?t flyer until the last minute and didn?t email announce until late. You should plan and announce at the beginning of the winter semester and continuously update.
We should keep the contest intercollegiate and in the winter. The fall has to work around Halloween and football, which is a big deal because people have social lives. It?s important to have the contest the 2nd or 3rd week when people aren?t bogged down with work (but late enough so other schools are actually in session).
We need to thank the sponsors, and the Duderstadt people for letting us have the room.
Schedule the room as early as you can. Talk to Spartasoft and EMU ? say ?here?s a date, are you guys okay with it?? It?d really suck to not get this room because it?s the only one that can host the contest. I messed up the funding; MSA for hotel, UMEC for food because each won?t fund the other at all.
We should email department chairs and class chairs about this, and it?s a great way to put the group on the map. Contact Wayne state etc; not many people do a contest like this. Don?t limit people from other schools that they have to sign up with 2 and have a spot for a 3rd; trying to professionalize and mix it up is disconcerting for them b/c this is mostly an informal thing. Keeping the rule for UM people will teach us more skills.
We shouldn?t allow external code that?s exclusive to a single person b/c we need a level playing field.
The updates I demanded were just so that later on I can verify that no one is cheating. I?d recommend that we have two different coordinators to go back and forth. As the contest gets bigger, this will probably get more important. The contest should be 48 hours, but plan accordingly with an extra hour each before and afterwards. Before to plan for and handle stragglers ? set starting time before starting time, and factor this in for when the judges show up. Also have a strict cut-off when work has to end, and warn the teams at 47 (Steve says 46th hour, so people are less inclined to add extra ?necessities?) hours to have a build working ? then set the build aside. In the extra hour afterwards, set up the contest web pages and get the games working on other computers. Have judges arrive after the 49th hour.
Steve adds ? I have a friend that?s not a student of any of the schools, but he?d have enjoyed joining. Perhaps allow students or club members. Also, tell people to record what they do every hour, and only send every 6.
We need to make guest accounts for members from other schools so that they can log in and out at will.
Vishnu ? send more frequent reminders; the 494 class email list only exists in the fall, make sure everyone on that list knows about the contest.
We need to set up contacts with Sony and Nintendo, they can send good prizes.
3d graphics tend to rise to the top; your game only has 3 minutes of player attention, you should make sure it?s in an action-packed place, and open-ended games tend to be bad for that. Consider a tutorial (outside of 48-hour games).
Note: views and opinions expressed in this article are the author's and are not necessarily those of Wolverine Soft.