Ryan Crim, Week 9 Journal PPJ, Blog post 9, GMAP 378

Personal Post-Mortem:

As we approach the end of development for Alien Arcade, it is as good a time as ever to reflect on how it went. In general, having joined the development after it had already been worked on for a term meant that there would inevitably be a lot of ups and downs as not only did I have to become accustomed to how the game was currently working, but I also had to bring a different prospective to improve/change it up.

Issues

Concepting

The biggest regret I have regarding this project was missing the first group meeting since it was on a Sunday at the time (mentioned in my first PPJ). In this meeting, most of the brainstorming for how Alien Arcade should evolve as well as concepting game ideas took place so the majority (about 80-90%) of the mini/micro-games made during this production were pitched to some degree in this meeting. In my opinion, some aspects of the game seemed to be ignored to an extent and had to be handled later in the process (such as scoring), and some of the game ideas seemed to be missing something, and I think I could have been an asset to bring up early issues. In general, I think not enough was done during the concepting phase and that caused issues later where myself or others in the group were second guessing what exactly needed to be done for a few different aspects of the game. Looking toward the future, I definitely never intend on missing the concepting phase of a project again because it is the most important part in determining how smooth the production goes.

Soft spoken

In the same vein, one issue that tends to plague me on group projects in general is the fact that I am naturally soft spoken. For the first half of the project, the combination of this and the fact that we were not consistently inspecting the progress of the game as a team in a meaningful way resulted in a lot of issues existing for much longer than they should have. Furthermore, there were situations where I feel as though extra/unnecessary work was being put into aspects of the game and I should have spoken up more to prevent what I considered time sinks. For example, while the resulting alien model and animations look really great in Draw at Noon, I still hold the belief that the four or five weeks it took to make them (especially the time spent on the complex animations) was not worth the effort since the animations only appears in a single five second game and it took away time from improving aspects of a lot of the other games. Toward the end, I got a bit better about speaking up and mentioning my thoughts/issues, but I think it may have been too little, too late in some cases. Therefore, moving onto future projects, I will definitely try to continue to improve my communication skills and speak up more.

Motion base

Despite the fact that this whole game was being designed for the motion base, I was not able to regularly attend it considering that the open hours on Wednesday conflicted with my schedule and I was generally busy throughout the week working on Senior Design, the multitude of changes for this project and assignments for other classes. Therefore, while I was putting a lot of effort into each of my mini/micro-games to try to make the motions as obvious as possible, I was never really able to test them to make sure they were working as I wanted them to. Furthermore, I was not receiving solid feedback about the motions since playtesting on the motion base was sparse. I definitely wish I would have been able to test more on the motion base (although my motion sickness would have made that tough anyways).

Successes

Mini/Micro-game creation

The most fun and rewarding aspect of production for this game was definitely creating and working on my own individual mini and micro-games. Over the course of the term, I ended up creating four micro-games (Abducktion, Draw at Noon, Dance Off and Whack-An-Alien) and one mini-game (G-Switch), which I believe makes up almost a quarter of the games. This included setting up each scene, writing all of the scripts and, in some cases, creating art assets. With all of these different games, I was able to test my prior knowledge of Unity development as well as discover a whole slew of new techniques and perspectives that I will be able to carry on with me to future projects. For example, prior to working on this game, I knew that sound effects were important, but for a mini/micro-game collection they are crucial since players can heavily depend on sound cues to take in information without having to break their concentration from the action on screen.

Bringing consistency to the game

Having learned of the importance of prefabs in earlier game classes and utilizing them in previous projects/games to make updating reoccurring objects (such as UI) a cinch, I was surprised at the lack of prefabs when I joined the team, especially considering that this game would have a lot of different scenes for the multiple mini-games. Therefore, over the course of production, I made sure to create relevant and useful prefabs that are applied in each of the scenes, which made updating aspects of the game a lot simpler. The biggest example of a prefab that has saved a lot of work is the Dashboard UI prefab, since it has been updated many times throughout the course of production and required almost no effort to update each time after I added in the initial prefab to each scene. In addition to UI prefabs, I helped bring consistency to the game in many different forms, including updating the scoring logic (humans vs. aliens, centralized score values, high score saving, etc.) as well as made sure that each game had their own unique music and that said music was balanced between all scenes. Moving forward, I definitely intend to continue to make sure every project I work on properly keeps everything consistent and as centralized as possible.

Meeting deadlines

Another aspect of the production that I am happy with was that I was generally able to meet all of my deadlines that were set. The only cases I did not end up hitting my weekly deadlines were when I was waiting for an art asset that was not yet finished. In those cases, I made sure to find another aspect of the game to work on so that I was not wasting time. An example of this would be the few weeks I was waiting for the alien model and animations to be completed, so instead I made improvements to the general structure, such as updating the InputManager to be more organized, creating a custom version of Unity’s RigidbodyFPSController to easily change its inputs and adding the ScoreChange prefab. Also, I made it a point to help anyone else out with any issues that they were running into. In general, this project provided good practice for setting realistic estimates for work, a skill that I have been working on since my first Co-op.

------------------
 

Content with Hours (Examples included):

With the second beta out of the way, this week marks the sprint toward gold build. Therefore, a lot of this week consisted of fixing small issues and polishing up each of my games as it was needed as well as touching up different aspects of the experience as a whole.

Over the course of the production, one thing that has seemed to be neglected has been audio, especially the music, with some games still lacking music or reusing music from other games. Therefore, since Corey had already downloaded a bunch of music clips from playonloop.com a few weeks ago, I went through each game, added the song that fit best and made a note of all of these in a document. In addition, I know that there has been serious audio balancing issues in the game, so I added a prefab to play the background music in each game. That way we could manage the volume for all of the music from a single place and to hopefully keep the audio a bit more consistent. (1.50 hrs)

Moving on to my individual games, I started by making a few updates to Whack-An-Alien. Based on the feedback from showing it in class and a small bit of playtesting, the obvious issues that were occurring dealt with the alien moving a bit too fast and the controls being not as intuitive as they could be. Switching the speed was a matter of changing a variable and testing, and switching the controls consisted of changing the input strings in the Inspector to allow human #1 to control moving the hammer and human #2 to control banging the hammer. Also, changing the controls made it necessary to update the human control image with Angela’s help. Lastly, there was a suggestion to add a green light to appear in the hole that the alien was rising from to make it more obvious and it made sense so I added it as shown in Figure 1. (1.00 hr)

Figure 1. Screenshot of Whack-An-Alien with green light and updated controls

Next, I made a couple of different changes to Dance Off to try to make it clearer, easier and more consistent. In terms of making the game clearer, I added team name bars to each side of the game arena and changed the background color of each side to green for the aliens and pink for the humans as shown in Figure 2. Furthermore, I updated the coloring of the notes that scroll so that are more readable against the background. In terms of making the game easier, I made the offset for a correct note more lenient, so in the case of the humans it is about 3.5x more lenient and for the aliens it is 2.5x more. Lastly, I made the controls of the game more consistent with the controls of other games, such as Refueled, Space Aim and Stello Says, by making human #1 responsible for the vertical axis and human #2 responsible for the horizontal axis. (1.25 hrs)

Figure 2. Screenshot of updated Dance Off game

For G-Switch, there was only one real issue and that was the fact that it could be difficult to tell when you are nearing the end of the current platform you are walking along. Originally, I intended for the platforms in the upcoming section to be the guide, however, with the addition of the alien instructions panel the next platforms may not always be readily visible. Therefore, I added transparent pink zones at the end of the jump-able platforms in order to try to more visibly let the player know they are reaching the end and should jump as shown in Figure 3. Furthermore, I made sure these pink zones were short, so if the player thinks they need to hurdle this then they would still have plenty of jump to make it to the next platform. (1.00 hr)

Figure 3. Screenshot of G-Switch with transparent pink jump zones

The last of my games that I made changes for this week was Draw at Noon. While discussing the current state of the game, the team was adamant about how unfair this game was to the humans. Therefore, in addition to adding a fourth arrow sign for the aliens to press as shown in Figure 4, I also made the signs prevent showing the arrows to press until the instruction bar disappears. In terms of cosmetics, I updated the animation script to also change the alien’s texture so it would show different emotions depending on the state of the game. Also, I fixed a visual glitch that was making it appear as though the human’s bullet bounced off the ground due to the recoil motion. To fix this, I moved the location of the bullet’s start point forward so it would not be affected as greatly by the camera as it recoils back. (0.75 hr)

Figure 4. Screenshot of Draw at Noon with four signs and angry alien

Lastly, toward the end of this week, Angela submitted a HUD gradient that makes the in-game UI (score and time bars) stand out despite the background of the game as shown in all of the game screenshots above. In addition to adding this gradient in the form of a prefab to each scene, I updated the ScoreBar prefab to remove the temporary transparent black box around it and I updated the TimeBar prefab to instead use the pink to green gradient version that Angela had created. (1.00 hr)

Content Positive:

- Made sure every game has their own unique music

- Balanced the background music generally between the menus and games

- Fixed various issues in Whack-An-Alien, Dance Off, G-Switch and Draw at Noon

- Updated in-game UI (scorebar, timebar and HUD gradient)

- Helped resolve issues in others’ games

- Got five playtesters (off of the motion base)

Content Negative:

- N/A

Total Hours for the week: 6.50 hrs

David Monteleone, Week 9 Journal PPJ, Blog post 9, GMAP 378

Content with Hours:

                Since this is our Post Mortem PPJ, I’ll keep what I did for the week to a short paragraph. Here’s a quick listing of bugs that I fixed: made aliens move faster in Water Gun, fixed Mech controls to be on the correct side for shooting, made the Press game slightly longer, added missing textures throughout the game, added and modified control panel images that were wrong, added alien controls to games missing them, and added human controls to games that lacked them.

(1.5 hrs)

                In addition to bug fixing, I also made the final credits scene to display our names and the music copyrights. I implemented the art for Press that Jinghan made. I removed the old and unnecessary UI elements from all of the games. Ie: the ‘X’ button, and return button in the top right corners. I added the Popcorn Popper texture that Joe made. I then started to work on the final GDD deliverable. In addition to these tasks, I spent a large amount of time playing the game as many times as I could. Every time I found a bug or issue I’d report it to the appropriate person via Slack. I love where the game is right now!

(3.5 hrs)

Content Positive (Duplicate hours from above):

-          Fixed various bugs throughout the game (1.5 hrs)

-          Added missing artwork, made the final credits scene, removed old UI elements, playtested the game like crazy, and worked on the final GDD.(3.5 hrs)

Content Negative

-          None

Total Hours for the week: 5 hrs

Personal Post Mortem:

                Since this is a personal post mortem, I will discuss how my efforts affected the team and where my efforts went right or wrong. In general, I believe that I was a great asset to the production of Alien Arcade. From the very beginning, I helped shape the game to be what it is today. Whether that was with my hard work or leadership the game was definitely impacted by myself. I’m happy to see the game be where it is today, but of course, there are always lessons to be learned by the mistakes made along the way.

What went right?

        1.       Documentation

During the term, I was in charge of all documents related to team organization, documenting the game, and putting in writing what the game is actually supposed to do. I put a significant amount of effort into each deliverable that related to documentation. The end result was a very good response from our professor. The game was also easier to understand and the group had a single document to go to for information on the game. I believe that this contribution was critical to integrating the new team members into our group early in the term. The documents explained how to make mini games and integrate them into our system. This is probably one of the best products that I produced for the team. This taught me the lesson that well done documentation can be one of a group’s greatest assets.

        2.       Game Making and Up Keep of Old Games

The group followed a similar development style as last term. As such, I developed three of my own games and maintained them. Because we allowed individuals to maintain their own games I was able to completely focus on keeping my games in tip top shape. I also took on the task of maintaining the games from the previous quarter. Trust me, there were plenty of bugs to be fixed in the original five games from last quarter. As a result, I polished a total of 8 games and am extremely happy with where they are at today. This taught me the lesson of being responsible for past work while also maintaining work that you have recently made. I didn’t make others find my bugs from last term. I went back and fixed the old games while still maintaining my new ones.

        3.       Communication

I made it a clear to everyone when bugs existed in their games or when things just didn’t seem right. During each group meeting I was an active member that participated and made sure that my voice and opinion was heard. Without this type of communication, many bugs would’ve never been fixed, controls would be flip flopped or nonexistent, and games would lack the proper art that the artists had put the time into making. I made sure that if an asset was ready to be put in a game that the person knew to put it in the game. I also made to sure keep the group on the same page when adding in new features, adding bugs fixes to another person’s game, or updating the GDD which is the final say in how the game is built. These lines of communication and networking are critical, especially when working with a group of 11 and using version control software. The lesson learned here is to always keep your lines of communication in a group open. People should always know what to do or what to fix.

What went wrong?

        1.       Time Estimation

Throughout the term, and even last term, I struggled to estimate my tasks appropriately. I ended up having many tasks being “Extra” when we would present the Status Reports for each week. This is something I know I have an issue with and I did attempt to fix the issue. I always tend to underestimate the amount of time it takes to fix bugs or implement features. The lesson learned from this is to use your past experience as a gauge for estimating the time required for tasks in the future.

        2.       Time Management

I did not have nearly as much free time as last term. This is a result of having more classes than I did in the fall quarter. As a result, I had to schedule my work for the project in tighter and more constricted time blocks. This resulted in many of my tasks being rushed and not as thoroughly completed as they could’ve been. An example of this would be the controls that I had to do two weeks in a row. I needed to manage, and space out, my tasks for each class more appropriately so that I could complete each class’s tasks well. This closely relates to my time estimation problem, but this is more so regarding my timing of everything in general. Balancing outside work with classwork and making sure each is given an appropriate amount of time. There were a couple weeks here and there that could’ve been given another hour of two of production for the game. This reason here is why I did not accept the leadership role that was offered to me at the start of the quarter. I simply did not have as much time to be the same leader I was last term. I think that was definitely a smart decision on my part, both for myself and the group. The lesson learned here is to make a schedule for each week or month and make sure each task is given an appropriate amount of time to work on it.

        3.       Not Play Testing Enough on the Motion Base

This is not just a personal issue that I had during this quarter, but this is a team issue. I did not play test ON THE MOTION BASE enough after making changes to the build. Granted, it’s difficult to find time slots that match the motion base hours and the teams. Last term, I felt like I was at the motion base on a weekly basis. This term, I did not have as much spare time to spend the game. The end result was a game that was well polished, but still needed a couple motion tweaks here and there. When the group did organize motion base play testing I was at every play test session. I even brought friends to play too. The lesson learned here is that setting aside time to test games is just as important as setting aside time to develop them.

Lessons Learned:

        ·         Documentation can be one of a group's greatest assets.

        ·         Being responsible for past work while also maintaining work that you have recently made.

        ·         Always keep your lines of communication in a group open. People should always know what to do or what to fix.

        ·         Use your past experience as a gauge for estimating the time required for tasks in the future.

        ·         Make a schedule for each week or month and make sure each task is given an appropriate amount of time to work on it.

        ·         Setting aside time to test games is just as important as setting aside time to develop them.

John Frankel, Week 10 Journal PPJ, Blog post 9, GMAP 378

Content with hours

Playtest 1

I was at the first playtest with the other group and we got a handful of playtesters to come and play our game.

(1 hour)

Playtest 2

I was at the second playtest and kindof had to manage people who wanted to go on the ride.  I played the aliens when we had no one else and I sent them to the survey after riders had completed.

( 1 hour)

Bug fixes and improvements

We had a list of bugs and improvements that we wanted to do in the transition and two of my games.
In the Transition:
I updated the controls, added background music, added a floor to the tent (although I think there might be a problem with it.), I changed where the controls on the slot machine were and that was it.

In Tic Tac O Noes:
I added a lookat script that had the Xs and the Os look at the player, I also increased the time by 1 second. I also updated the controls.

In Crazy Ball and Chase ball:
I made the crazy ball look at the player so that it would look like it was chasing them. I diferentiated the two games so they looked different.  Hopefully that will be enough.

Here is the code for the look at script.  It can be pretty useful.

 public GameObject player;
    public float offset = 90;
// Update is called once per frame
void Update () {

        transform.LookAt(player.transform.position);
        transform.eulerAngles -= new Vector3(0, offset, 0);

}


Total Hours: 4

Post Mortem

This was not my favorite project to work on.  In fact, if we are being honest, it actually is in competition for my least favorite projects and I will explain why.

While we did reach our goal of adding a large quantity of micro games and I was able to work on the framework which had some interesting programming involved the project suffered from two pitfalls.

Negatives

First, the project had a weak or really no leadership.  At the beginning of the project it was blatantly apparent that no one wanted to lead the group.  David lead the team last term and this term he did not want to.  After that Xavi was the one to be asked to be the leader, but he was reluctant at best,  some parts of the programming leadership fell onto me but I knew nothing of the game so at best I would give it a shot.  I used Trello a lot at the beginning and logged all of the tasks we came up with, but as the term went on no one used the trello so I gave up on it because it was a lost cause.

Now the second problem really hit the team hard and there are a variety of things around it.  The second problem was the loss of morale.  The group became less and less interested in the success of the project and just wanted the class to end, or at very least I did.  Without a group morale, and with no real leader to push everyone forward the group began to stagnate.  Work was only good enough from most of the group, with a few over achievers who still liked the project (props to them for hanging in there with the rest of us).

There was also problems with communication, that others have talked about and there was some problems with everyone going off on their own direction.

Positives

We did end up making a lot more content then I expected.  We started with 5 games, and ended with 22 games.  That is a large amount of progress.  We retooled the frame work to make it work better, and continually improved the art for the game.

The art has always been the saving grace of the game.  And the artist always stepped up their game, especially Angela, to produce quality art.

Tj Heiney, Week 9 Journal PPJ, Blog post 9, GMAP 378

This week was a lot of clean up. Refueled still needed some tweaking in the form of balance. To further balance the game, I shrunk the play space. This meshed well with the slow speed of the Alien ship. Ryan and I fixed the sound so it would loop when you were draining fuel.

Hours: 1 hour



Shooting Gallery had to have the alien cut out replaced with the 3d model. I finally got instructions in for both games.

Hours: 1 hour

Total Content Hours: 2 hrs

Post Mortem:

The project went well enough but there were many issues with project management. We never really had a firm leader and thus no one ever really knew what was going on. I ended up asking Ryan Crim what to do most weeks. The work load was really unbalanced as well so there were some weeks where things didn't get done or done on time. Time was a big issue as well since most art wasn't done in time to be implemented for the work. Usually the programmers would do the work over the weekend and art wasn't done until Tuesday. It was hard to find the art as well. 

Joseph Santos Week 8 PPJ

This week I finish textures for the tent and create transparencies for the ufo textures I did the previous week. Also, since we are rapiding approaching our final weeks, I took the time to check all the other fbx models. In the last couple of weeks, I've noticed a bunch of fbx models that weren't uv or modeled properly that I had to fix. Hence I wanted to check which models needed more tweaking. Fortunely, the ones that needed fixing were the ones I fixed already. While I got tent in, the I missed the deadline to get the modified ufo textures in on time due to another meeting that went overtime. However, I was able to complete all my tasks.

Pros:
finished all tasks
not all fbx models needed fixing which I was worried about

cons:
missed deadline to get ufo texture in on time
given that I worried about a problem that really wasn't there( fixing anymore fbx) wish I could done other art assets from back log

Hours:

tent texture:
2 hours

ufo texture:
1 hour

Going through project to see if any fbx models needed fixing:
2 hours

total hours: 5

GDC Vault: among friends uncharted 2 by Richard Lemarchand
being a huge fan of the uncharted series, I watched the post mortem on the the second entry in the franchise. After watching it, I'm still surprise that they run into time crunch and problem despite all the pre-planning they did to try to avoid such problems. Richard has said in the talk about how Naughty Dog cares about their employees and try to not over work them. The pre-planning was to help over work them yet they still ran into those problems.

An interesting thing they brought up was the marco design sheet they created instead of an actual game design doc. the marco design sheet was just a spread sheet with broad details about levels and characters. The reason this document worked so well for them is that with a regualr game document, there are lots of pages with the all the details about everything. Obivously, to change anything would be to go through all those pages and rewrite a page or 2. With this macro design document, they wouldn't be locked down with details that would work best as they added along.

Another interesting they did that I don't see much with the game classes at drexel is they used previz. A lot of times when creating a game, people start greyboxing the game, which at this stage could change. When doing pre-viz in maya, they were able to do a rough animation to show what gameplay could look like. It's something that I think some game teams can use even if we are on a 10 week schedule.

Since this Uncharted was a sequel, I thought the code would be only polished but not completely touch. To hear them they say they made their programmers redo some script completing from scratch to fit the new vision for the series made me realize some things could always use improve, even if you have a solid foundation.

Vincent Slifer PPJ week 08

This week was fairly good for me because I was able to reconcile aspects of my games that were either too complicated or I did not receive feedback on how they played.  While I was aware that the games were flawed, I needed the feedback provided to push the games in the right direction.  Because of that feedback, I was able to edit Ram the Planet to be more of the crazy situation, meant for a laugh, type of game it was envisioned to be.  I was also able to provide better visual cues for the players for the other games I developed, Popcorn Popper and Item Dodge, allowing both the aliens and humans to clearly see what is happening on screen.  Without proper feedback, I would have been lost in not knowing what flaws my games needed immediate fixing.

Positive Content

• Added background music to Popcorn Popper, Ram the Planet, and Item Dodge micro games
• Altered the games to reflect better controls & playtest responses

Negative Content

• Was not able to fully test out the newer versions of the games
• Will need to fix for next week
• Was not able fully complete the Item Dodge Variant
• Needs better art from artists for the controls

Work and Hours

Alterations (~3 hrs)
- Added music to Ram the Planet, Popcorn Popper, + Item Dodge
- Edited games to be easier to play + understand

Variant Creation (~1 hrs)
- Finished creating the variant of Item Dodge

Total Hours: 4 hrs


GDC Vault Post-Mortem Reaction
Presentation: Far Cry 4: Gameplay Team Workflow, Iteration and Philosophy - By: Marc-André Saulnier

The first thing that struck me with this post-mortem  was that a single department for the game had a diverse set of skills collaborating in close proximity to each other.  In contrast to us, from the perspective of someone in a similar position to Saulnier, we separately developed parts of the game that was then put together in the end.  This includes the fact that the group itself was split into two core teams of art and programming.  The difference being the Far Cry 4 developers had people with various skill sets working in the same team, unlike us that divided ourselves because of our skill sets.
The second key item I noticed was how Saulnier kept talking about how the players were important to the game making process.  He talked about how the team developed ideas that would give the player a variety of choice where they can accomplish something cool.  Feedback would be given to those ideas, be it within the team, from other departments, higher ups, or testing; the department would receive constant feedback on the ideas, features, and the design of the game as it is being developed made.  The difference compared our team is that our primary feedback was from playtesting, after the feature was complete.  Parts of the feature would be shown, but it would, more than likely, not receiving as much vetting as a complete feature.  Every feature was tested at every stage and was given feedback with every iteration, where features were either pushed further or scrapped.
The final topic that caught my interest was the communication within the team.  It was not just the fact that members were constantly talking with each other, it was that ideas and troubles that someone might have were dealt with help from other members.  The core difference, that was already said before, was that the teams worked together, in the same building.  Not only does this allow for better communication, but it allows members to be more proactive with each other.  Our team was able to ask for parts from each other, that would later better be integrated.  The difference there being the Far Cry 4 developers were able better and more quickly develop ideas for the game on the fly.  Beyond that, having the close proximity with each other would allow for more ideas to be thrown around and aid from peers to be available.  Saulnier presented a few items that describe how successful games are made by teams whose members are effective at working with each other.

Angela Buchanan, Week 8 PPJ, Blog Post 8, GMAP 378

2D art, interface, texturing

This week has been about refining assets and updating the interface to make it easier to understand or to reflect changes.

My big focus for the week was placed on updating the human instructions to add icons to their dash.This can act as an additional visual aid to let the humans know that the bottom instructions belong to them.

I added a gradient to the UFO to also help the humans feel more threatened when their spaceman approaches the enemy color.

The spaceman itself has an animation to allow him to look more panicked.

Positive Content   

-  Human players are represented by icons instead of number now

- UFO time bar implemented the green/pink seperation

- Human animation will add more panic to the time bar

Negative Content

- Finals are approaching. This will affect work for the remaining weeks.

Work and hours

Human Instruction screen update (1.5 hrs)

Instead of using P1 and P2, the players are now represented with a human icon with a number on his head. Visually, this is more interesting and will aid the player in knowing that these are human instructions.

.

Time Bar Update (1 hrs)

UFO now now has a gradient. As the space man moves up he will approach the green. Because green is the color of the enemy for the humans, they will see this is a bad thing. 

The space man has a "panic" animation now as well, to better convey the feeling of urgency.

Instructions Update (.5 hrs)

Just a general update on instructions that were needed for new games. 

Alien Gets Emotional (.5 hr)

The alien has emotions to help convey when he has been hit or is about to perform an action.

Also makes the character more interesting.

Icon Update (.5 hrs)

Icons for a couple of new games. One is for a dance game and the other is for a crazy ball variant game. 

Total Hours: 4 hrs

GDC Vault - Designing Without a Pitch: FTL Post-mortem 

I chose to watch postmortem of an independent game for as a student, I find them more relatable to my own projects. FTL’s post-mortem was especially relatable as they chose to jump straight into the construction of the game without having a clear end goal in mind.

I felt this is a common approach for student projects, so it was interesting to see how Justin Ma and Matthew Davis managed their workflow and design process to find their way to their end product. They didn’t intend for FTL to be full-effort project, therefor I felt this was a good way to start for them. They note during the presentation that the project was harder than what they had anticipated, and I feel that their lack of initial planning may be to blame.

Alternatively, I felt this method of design also benefited the development of FTL. Because they had a loose image of what they wanted, they were more prone to experimenting and attempting alternative mechanics and features.

However, once they launched their kick starter and they had expectations to fulfill, it became more important for them to decide on an end state. During their kick starter they wasted time trying to get features to work that were not necessary, out of scope, or did not fit well with the design with the game. After they were faced with feature creep, they knew that they needed to solidify their ideas.

Overall I felt they handled the project well, especially considering they did not intend for it to be a commercial product. Personally, I value having a well-established vision before diving straight into a project, but this isn’t always possible when given time restraints. I feel some of the lessons learned through FTL’s post-mortem can be applied to my own projects.