Get the latest Education e-news
 
  • Postmortem: Fly-Guy

    [11.29.11]
    - Fredrik Albrektson

  • Familiar Ground

    One of the things that made our concept the most appealing to us was that we knew it was doable - Erik had worked on a small project by himself earlier during the level design course that used similar puzzle mechanics and kismet-scripting. This meant we could start work on boxing out the level and setting up events without having to wait for assets to be finished, and gave us the security of knowing that we wouldn't run into anything we wouldn't be able to solve down the road.

    Obviously this didn't mean we had everything planned out and ready to deploy instantly, but having that experience gave us a considerable confidence boost and allowed us to more tightly control what we put into the game in the planning stages. That meant cutting away features we knew would be too difficult or time-consuming to implement, but at the same time allowed us to bring in elements that we knew would be quick and easy to implement, thus letting us get the most bang for our proverbial buck.

    Open And Free Communications

    Another thing that really helped us out when working on the game was having a well working dialogue between both game designers and artists as well as between individuals in the group. We set up weekly meetings to go through the planning and to make sure that both sides of the team knew exactly how far along we were and what remained to do, while also allowing us to prioritize tasks as they came up. We also had frequent discussions between members to allow feedback and critique to be weathered, and thanks to this we never ended up with a blowout where anyone felt they had kept anything back or couldn't talk with the others. By maintaining and atmosphere where feedback was always welcome we always knew if there was something that didn't work, and oftentimes this gave us a chance to get a second perspective from people who had more distance to what we were working on. This meant we could get a fair and unbiased assessment of it, while at the same time talking to someone understanding of our limitations, timeframe, and capabilities.

    What Went Wrong

    Sandboxing It

    Using each room of a house as a discrete level made for an easily communicable progression through the game that would drive players to see what's behind the next door, but it also meant we had to create environments with many points of interaction. To accomplish this we set up a list of puzzles and assets for the room that would make it seem natural-too much stuff and it would get cluttered, not enough could make it seem empty.

    The problem was that we painted ourselves into a corner where we couldn't cut content (for time constraints or quality control) without making the level obviously miss something; cutting content in a linear game is by comparison considerably easier as thee game or level may become shorter but will not suffer a loss of quality in the same way. It also meant we were among the last of the groups to have a boxed out prototype up and running in the UDK, which in turn slowed down our ability to implement changes and test features.

    An Uneven Workload

    Once production was started we ran into a major stumbling block very quickly: having a one-man bottleneck, which led to an unbalanced workload. As Erik was working with the level design in the UDK and setting up the kismet for the puzzles in it we ended up with a situation where all thee artists would come to him with models to see how they looked when imported (and to get feedback on their work). Had we empowered our artists by teaching them how to test imports themselves they wouldn't have had too go to Erik for each asset (and all its iterations) and thus freed up more time for him to work on the level. Another factor in this bottleneck was the previously mentioned sandbox level: having a single level to work on meant only one designer could work with the level at any given moment. This meant that Erik, who was familiar with the level, had to do everything related to that and had a disproportionate amount of work to deal with.

    Seeking Challenges... Everywhere

    Having some very driven individuals in our team meant looking for challenges and trying to push our skills as far as we could. Our assignment was specifically a vehicle game so that we wouldn't be bogged down with rigging and animation, but Jonas, being interested in animation, went ahead and set up an animated character. The result was a great addition to the game, but had he spent that time working on assets with the other artists we could have seen a dramatic increase in production. Erik wanted to make complex puzzles, and so we ended up with an amount of kismet scripting rivaling that of thee other groups put together-once again this was good for the project, but with less complexity we could have had more time for testing or implementing different features.


    Another of these experiments was Fredrik's go at using Scaleform UI-a more modern alternative to the now deprecated UI- scenes that other groups used-that would allow for more advanced HUD elements and animated menu systems. The result were UI elements that were technically more advanced than what others could present, but there were considerable drawbacks in the process as well. Considering it was a system we had not previously covered, Fredrik had to sit down and learn it from scratch. But since Scaleform uses Flash in the creation UI elements, and Flash wasn't available on-site, he couldn't work with UI in conjunction with thee rest of the team. This meant that teachers and consultants who wanted to advise us on technical topics like light mapping and assset.optimization had to take it up with, Erik who didn't have the same technical expertise, and code/feature-requests sometimes had to wait.

Comments

comments powered by Disqus

UBM Tech