Thursday, December 12, 2013

How to Fail

Throughout my time at DigiPen I've had three or four really rough semesters for reasons out of my own control and I have learned some important lessons (both on my own and from others) how to fail and how not to fail

1. If you have a choice for a project, don't settle (be invested)

This one is dangerous if you don't understand what I mean, because it can easily be used for justification to overscope a project. I do not mean try to make your own Skyrim or MMO because that is your dream. What I DO mean is that don't just choose a project because it's convenient* or people around you want to do it. If you don't feel interested or invested in the project, it's a serious problem and needs to be fixed as soon as possible. This point boils down to make you sure you are getting something that you want to from a project if possible and feel invested in the quality of the product.

*caveat this is meant for larger projects such as Game classes or full-semester projects, not required smaller projects for other classes.

2. Don't live with broken windows

This point is taken directly from the Pragmatic Programmer and is basically that signs of neglect in any system or situation leads deterioration and can quickly make things feel like they are out of control. If you encounter a problem, do something about it, even if is not fixing it. You may not have time or resources to replace the broken window, but you might be able to quickly board it up to show that you are aware of the situation and are on it.

3. Understand "Fail often, fail early"

You'll often hear this repeated in anything related to software development. What is needed here is the idea of constantly reassess and iterate on what you are doing. If something isn't working, don't follow it down the rabbit-hole. Instead, reflect on the problem and see if there is a different path or even small change you can make before embarking to Wonderland. 

4. Let people, who can help, know you're failing (ask for help)

Simple point, most people are empathetic and can understand your situation. You don't have to elaborate if you don't want to, but letting instructors, teammates, friends, etc. know that you feel like you are floundering and that need help to continue can often result in some form of relief or re-invigoration. 

5. You can't do that one superhuman push

The most common trap I see people fall into at DigiPen is "If I just work really hard for the next two weeks..." or "If I don't sleep...". I've seen this work one time in my DigiPen time, and that person was always a hard worker. Don't expect that you will suddenly have a three-fold increase in productivity based on no evidence. Instead try to bring the work in line with your productivity* and accept the situation. Otherwise you will likely burn out and the cycle will repeat on a larger scale.

*if your productivity is zero, this is a separate problem.

6. Postmortem

All five of these points can be summed up as "Be pro-active", but even then sometimes, despite your best efforts, projects (or you) will fail. In this case the most productive thing you can do is a postmortem. Postmortems are great for almost everything in life in my opinion. The saying "hindsight is 20/20" is often used sarcastically, but it does speak truth about you knowing more now than earlier. Using this to reflect on your action and subject them scrutiny is an important way to improve on anything you do. Sometimes you might realize that there was nothing you could do without more information, but most of the time you can glean some lessons and improve for next time.



Upcoming Posts

I'll have three upcoming posts detailing what I consider the major things I accomplished during this semester, as well and one important personal post on something I have learned.

These will include:

  1. Embedding Lua into c++
  2. Importing Assets from FBX
  3. How I managed multiple shaders in DirectX 11

Sunday, October 6, 2013

Early Progress



So for my first progress update there's not a lot to show visually. The picture shows a model and it's bones being loaded from a fbx file.

Total Progress so far:

  • Model loading (mesh and bones) using an .fbx file importer written using the FBX SDK, based on code provided by Chris Peters
  • Shader loading and management using meta files to describe shader input layouts and constant buffers
  • Support for multiple cameras and viewports, as shown in the image above (two viewports, one with the model, the other with debug drawing for bones)
  • Handles window resizing and fullscreen toggling

Inaugural Post

A quick description of what this blog is about to get the ball rolling. I'm taking a class at DigiPen Institute of Technology called GAT399. The point of the class to take a project we are personally passionate about and accomplish the task using a particular set of methods (more on this later). The project I have chosen is a demo of different types of real-time graphics techniques.