Short schedules, GDC talks and arbitrary design

My previous dev blogs have been mostly about the WHAT of my development process, WHAT I did, WHAT I learned and sometimes HOW I came about it. And while that is all well and good it isn’t what is truly bringing Twin Switch to life. This dev log has taken some time to write because I have had trouble articulating my thoughts into a format that would be academically acceptable. But this dev blog should’t be for my school (even though it is being marked), it should be for me and whoever happens to read it. A question I have recently been asking myself is “What would I want to read a dev blog about?” Sure it would be interesting to read about some new technique or how a pipeline either succeeded or failed. But those are all results of a persons work, they’re results of their WHY. And that’s what this dev blog is about.

This dev blog is about WHY I choose to work on Twin Switch and WHY it’s important to know WHY you’re doing what you do.

If you were to ask the average student WHAT they want to do after graduation you will always get the same response, even from me most of the time. “I want a job”. If you were to ask them HOW they were going to do that they would probably say something along the lines of “By working hard or making a good game”, you would get a generic response that is more vague than asking them WHAT. But if you were to ask the average student WHY they wanted the job, I can guarantee you 90% would not be able to answer that question. Many of them would say they so they could make money or become successful but those are simply results. The average student would answer WHY with more WHATS.

By asking WHY are you making games I mean WHY do you come to school, WHY do you put in this effort? Not to get good grades or get a good job, but intrinsically, WHY do you want to make games.

Being able to answer this WHY is arguably much more important than any dev blog about skills and techniques because those can be achieved by anyone. There are thousands out there that all go over the same stuff, resources will always be available to you to improve you practical skill. But asking WHY goes beyond that, its not something a dev blog or tutorial video can answer for you. It’s a concept that has to be introduced and learned through working.

So WHY do I work so hard on Twin Switch? WHY do I put the game before my school work? WHY do I break the normal format of a dev blog opening  the possibility of receiving a bad grade? Because I believe Twin Switch is more important than all of that. This whole program has been about teaching students WHAT to make and HOW to make it, but it cannot teach the students WHY they should make them, that has to be discovered individually and sadly, rarely is.

You see a good programmer, a good designer and a good artist don’t make a game good, you can have the best people in the world working on your game but if they are not working for a purpose you just don’t get anything very good. Everyone in the world has access to the exact same resources, every game company is just a qualified as the next to make good games but the ones that produce good work are the ones that believe in what they do. The companies that succeed have a WHY. They know WHY they get out of bed in the morning. They don’t go to work for a paycheck, they work because they believe what they do is more important than they are. They belong to something bigger and more beautiful than any one individual.

Needs to be continued…


Twin Switch: Reborn


This is basically all that has been worked on modelling wise. Coming back from the break we realized we didn’t really have too much on the weapon side and that it was constantly pushed back. Now that the map is coming together and art is picking up speed, it was important that these assets get in as they help a lot with the readability of the game.

When I started I had a few ideas on how some of the weapons would work, and like a fool I went straight to modelling. Its odd, no matter how many times I do it I always find myself back at the sketchbook in less than a day. Anyways these ideas proved more or less fruitless.


But because we only had rudimentary understandings at best of how our weapons would function. We had long talks about how they would look and work, which resulted in lots of sketches.

I found a lot of inspiration in wild life for the weapons. Depending on the behavior I would suit the gun to an animal of similar theme. For example, the bullet hose has a “swarm” like feel to it, so I looked for reference and found the wasp to have a very powerful silhouette.

After the sketches I got the go ahead from the team and began, block-outs in maya to see what they looked like in 3D. The team liked them even more and that meant it was time to move on to, yet again, more sketches. This time based on more flushed out ideas. I brought the block-outs into Photoshop and began cutting them up.

I found I actually got much more familiar with where to cut and draw once I reached the last series of weapons. It is an iterative process and it was cool to see how my understanding of the shapes improved in only 1 day!

The result was a lot of very powerful ideas and a stronger sense of each of the guns’ functions. The silhouettes were much better at suggesting what the guns purpose was. Can you figure out which ones we decided to go with?


Hopefully you got one right, but these were the designs that the team agreed most resonated with each weapons function. So from here I was good to finally start modelling! I began with the Para rifle (last on the right) and so far have the basic animation done.


But as with anything iteration based, I know I will be re-visiting these animations once I get through all the other weapons.

Twin Switch: Reborn




These past few weeks have moved the art team from testing our pipelines to finally putting them into action. I worked closely with Mohammad Qureshi to create level art and direction and then to finally model and texture the environment.

Initially I had spent little time planning because I knew I was on a short schedule. I went right from the concepts to blocking out the environment, making low and high poly models and texturing arbitrarily in Substance Painter. After creating the level and pulling it into Unity I realised something was horribly wrong. Some of the assets looked good on their own, but together they were a mess. There was no visual consistency, no new geometry, no flow, no form and no direction. The map was a total flop.


But that’s okay. The whole point of doing this first pass was to learn where I made mistakes and fix them in the next iteration. The fact that we failed proved that this was an important step. This was a lesson I knew before but had now suffered from in my hubris. I thought that from Moh’s concept pieces, I could skip some of the designing and do it during my production of the assets. Boy was I wrong. The worst part is that I knew better at the time and I still didn’t put my knowledge into action.

As you can see in these screenshots, there is little to no sense of unity, no flow, no visual consistency, it looks like an amatuer map that was thrown together using standard assets.

To sum up the issues with the first map, I will list them off and explain why they are problems.

  1. No initial design, only concept work.
    1. This prevented me from forming a more cohesive idea of what specific parts of the map would look like, how floors would flow, how colours would mix. It was like trying to paint a painting without knowing what our colour palette is.
  2. Rush to production.
    1. I felt that because of my time constraint, I didn’t have time to go through and design the map more closely, this may have been true but I feel it would have been better to create a few good assets that made sense rather than a bunch that were essentially unusable.
  3. Too little communication with Moh
    1. Once I had his concept work, I began production without consulting him on his design decisions or what his vision of the map was. The concept work can obviously not cover all aspects of the map so there were times where I had to fill in the gaps, I should have consulted with him when I did this and should have asked for extra pieces when I needed them.
  4. No greater vision
    1. While it was true that we had concept pieces for our map, we had little to no idea of what context it lay in. How high up was it? What materials would be used in the future? How close to the clouds is it? How does it function? None of these questions were answered when they needed to be.

So moving onwards we addressed all of this and essentially rebuilt the map from the ground up.

Moh and I spent a considerable amount of time with the team discussing how the environment would work, something we really hadn’t explored. We needed to figure out what the structure we were playing on actually was, it had to be more than just an idea. So we spent a considerable amount of time engineering the whole thing and building something that made functional sense, this also helped us really visualise what it was going to look like once completed


This was our main whiteboard section for the design of the map.

Following this Moh came back and worked with me to create more readable and concrete concept pieces. We moved away from fully rendered ideas that were ambiguous, to more solidified line art and sketches where i gained a better idea of what was being envisioned. From these I was able to extrapolate and do more sketches of specific pieces of the environment.


This was just one page of sketches I produced to help better flush out the environment The more I design on paper, the less time I waste designing while modelling.

Throughout this process I kept a constant mindframe of design, always asking myself “why”. Why is this panel here, why are these grooves there what purpose do they serve?

Through this process I also kept things like form, silhouette and flow in mind to help create a map that was really “readable” rather than just some arbitrary set of pieces. The map had to be whole.

Because of this new design heavy mode of development, the map is taking much longer, but is succeeding as a result. Since the beginning of it I have already found areas in which my process can be improved.

I plan on spending even more time with Moh, better flushing out new geometry and architecture. I would like to spend more time exploring abstract shapes and forms rather than just simple block shapes, and additionally would like to explore more types of materials. What are these buildings made of 2000 years in the future? Surely there are new and better alternatives to concrete, plastic and metal? Just one of the many questions that will be answered in the coming weeks!


Project Clade: Exodus

Moving forward to now, a lot has changed in the project. The art pipeline is essentially complete and we are moving to more concrete process’ as a result.


One of the largest challenges I face as the 3D artist is figuring out how animations are going to work. As I am not an animator, a lot of this process is very new to me. Originally we had thought motion capture to be a good method of recording our animations. But after doing two different trips to SIRT in Toronto, we learned that motion capture may not be in our time budget for CLADE.


By simply losing one tracker, a lot of our data be incredibly difficult to work with, the clean up process became aggravating and a time sink.

Instead, we settled on buying motion capture animations that were ready to use, and after some simple searching we fell upon these guys: Their motion capture was affordable, diverse and completely royalty free. There was a small starter package that I picked up for $2 to test if they would work. I had Mohammad export a simple low poly version of our test character, I did a quick dirty rig to the skeleton of the mocap data and brought it into Unity. And the initial results were very promising.


(Our character on the left) The motion capture data linked up quite well to our character and despite there being absolutely no weights painted, the animation doesn’t look half bad.

The next steps are to complete the low poly test of the character and rig it to the mocap data skeleton. One of the issues that I ran into was the fact that the skeleton does not match up perfectly with our character’s proportions. I discovered that the mocap skeleton (the one that holds the actual animation for the mocap data) does not store translational data. This means that all the animation is driven purely by rotation values on the joints. Because of this I am actually able to extend and manipulate the skeleton to fit our characters dimensions without ruining any of the data, awesome!

The final topic to crush in my task as animator, is to figure out how to add simple animations to the already existing ones. I spoke to Brian, one of our animation professors, and he showed me a function in Maya called “Animation Layers”. This allowed me to add animation to certain joints in the project without disturbing any of the other animations. So, if say, I wanted to make a hand wave, I can isolate the arm from the rest of the body and add my animation there and still have the rest of the body follow the original track!

Topology and Character

The only experience with re-topologizing a character before was from my animation class in 2nd year where we were tasked with reducing the poly count on a character’s head in zBrush. Other than that I have never dabbled with topology. I began by looking up tools for re-topology online and discovered that most 3D suites actually have tools built in. Modo, 3DS MAX, Maya, and zBrush all have tools that allow you to re-topologize inside them. There were also multiple other programs that were recommended such a Topogun that were built specifically for re-topologizing objects. Alas I discovered that MAYA’s tools were very similar to Topogun’s so I stuck withing the program I knew.

The concepts for re-topology are the same everywhere so I just had to keep them in mind when re-topologizing within Maya. Things like such as keeping edge loops around circles, avoiding edge stars and keeping the polygons smooth and as close to the original as possible. After a very difficult run-in with Maya deleting my data, I had completed a lot of the re-topologizing manually and was very happy with the results.


A lot of the time was spent making sure that the contours were still crisp despite being populated by a much lower poly count.

I found it to be like a sort of puzzle, figuring out how little you can use to maximize the amount of detail kept. It was an interesting challenge and I enjoyed doing because I found it meditative in a strange sort of way. The issue was that doing re-topology manually can be very time consuming. Then, from recommendation from one of my character artist professors Thaddeus, I went on to use zBrush’s zRemesher which gave great results in a very low amount of time.


As you can see, the automatic re-mesh from zRemesher does a pretty good job of providing a good starting point for me to clean up in Maya. Although zBrush does have a tendency to create spirals in the meshes, it can be remedied by making sure your guidelines are closed and have their strength set to 100.

By the end I had a good mixture of manually remeshed, zRemeshed and zRemeshed then manually adjusted objects.


On the left is the high poly sculpt for baking, and on the right is the re-topologized character. I went from 1,100,000 faces to just 20,000. Although I believe I can get that a lot lower


Scheduling and producing took a sort of hiatus as we strayed further and further from our actual schedule. I found it would have been pointless to re-schedule every day to match our current progress. But now as we draw past our art pipeline completion and a really functional prototype. I am currently working on a schedule that we plan on sticking to for the next 6 weeks. Deadlines will be adhered to and cuts will be made, it was nice to dawdle in our first one and figure out how it worked, but now its time to get down to brass tax.

Project Clade: Exodus

Project Clade: Genesis

Part One – Doing something I have never done before

At the beginning of this project (back in January) when the initial idea and group proposal was brought up, I was listed as being a 3D artist. This is exactly what I wanted to do at the time and it fit my career aspirations. Of course, I eventually would like to move onward to a more senior role, but 3D art was what I wanted to do at the time. Now lets flash forward a few months to now, after 5 months of some slight pre-production I find my goals and aspirations have changed. During our initial charter and design meetings in early September, I took on the role of producer. Following one of the courses I took in the summer called “Production Design” I found that I liked managing a project and could see myself doing it to some extent in the near future. And here I am, producer for my capstone project. The only issue is that I have never had this sort of responsibility before and it feels a little intimidating. But with the help of my team and the guidance of my professors I believe I can guide this project to greatness (granted I fix my broken sleep schedule first).

Other than simple task management and “Kanbanning” I didn’t really have any tools available to me that I knew how to utilize. So what do? Learn a new tool of course. And at the recommendation of a professor and the suggestion of a friend and team member I began to use Microsoft Project. Now it is important to note that I typically hate anything documentation related especially when it comes to anything remotley similar to excel.

But I actually find myself enjoying Microsoft Project!

Having all our dates organized and available in a single document in a visual way makes it a fantastic tool for a visual learner such as myself. It also helps me plan and organize who has to do what, by when and who to depend on.

Without this program I most likely would have organized tasks on post it notes, possibly on Trello with everyone having access. And from what I have learned over the past 3 years, that almost never works. Teams need a designated person to track tasks and push development, and when everyone is involved in the planning, things tend to go downhill fast.


Above you can see our current schedule lists all our current (predicted) tasks as well as the overarching class schedule and necessary milestones. This was gone over with our code team as well as our art team to make sure that timing was at least somewhat accurate and that tasks could be organized in a somewhat waterfall like fashion. The issue with this schedule right now is that it is based on absolutely nothing but intuition. Since none of us have embarked on a project of this size before, it is difficult on all fronts to gauge how long tasks will take and in what order they should be placed in. This right now, functions as a framework for our actual development schedule come our “feature complete”. This whole schedule now will be revamped and re-done once we finish our current art and technical prototypes.

Part Two: Art, Animation and Anticipation

So in this project I am taking on roles of producer and 3D artist. As the 3D aspect of the art team I am responsible for creating all the assets and making sure they look good in engine. Now, historically I have created assets before, but never on this scale. So much like how I am trailblazing new ground with my producer role, I am discovering new techniques for production in 3D as well. During the first few weeks of prototyping, it is important to not waste any time creating assets that we think might make it into the final game. So with our technical team working on the actual greybox prototype. Mohammad and I will be working on a separate “art prototype”.

This will function as a benchmark and test run for our art pipeline. With Moh and I not having much experience in character conception and modelling, we thought it pertinent to practice it before we do any real production. This also holds true for all other aspects of production, practice first.

Throughout this art prototype Moh will concept and try new techniques, and will produce one production ready piece for character, environment and weapon. At this point we will discuss each piece and pull out all the individual sections of each concept and practice production for each. This means, for example, taking the environment and making; one section of the background, one asset, on decal and one skybox. We want to focus on not creating an entire level, but rather understanding our pipeline for each part of it.


THE ABOVE WILL NOT BE IN THE FINAL GAME, which is upsetting because I really like the shape… But that’s the point, this is functioning as practice.

Now just like our technical prototype, our plan/schedule for the art prototype is only based on speculation. We really have no idea which order these tasks should be done it or how to best manage our time. But that’s what is so good about it, it’s functioning as a learning experience. This means that when we do finally make it to our feature complete milestone, we will have a much better understanding of how our assets will be completed and I will be able to more effectively schedule our short 4 months.

Project Clade: Genesis