Git Branches, Branching Strategies

Making and Managing Branches

The philosophy in git is to branch often. Since branches are lightweight in git, be sure you are taking advantage of this philosophy. Git branch and switch commands will be the most frequently used.

Basic Branch Commands

To view branches:

$ git branch

To view remote branches

$ git branch -v -a

To create a new branch

$ git branch new-branch-name

Create a new branch AND switch to it (two-step):

$ git branch new-branch-name
$ git switch new-branch-name

Create a new branch (one-step):

$ git switch --create new-branch-name

which is the same as
$ git switch -c new-branch-name

Switching branches

It’s easy to switch branches. You can always use $git checkout branchname to switch local branches, but after git 2.23, the switch command is the accepted method:

$ git switch branchname

If there is a remote branch of that you haven’t added to your local workspace and you use the switch command, git will guess that you want to switch to the remote branch of the same name. As switching to remote branches comes up frequently enough, here is a stack exchange that explains this more in depth.

Branching Strategies

There are many branching strategies for git repositories. If you have more than one branch, you are using a branching strategy of some kind. As git has been around for a while, people have formalized some branching strategies.

These are great for large teams and complex projects, but I’ve found they are often too complex for small teams and simple projects.

My personal philosophy, for personal and small team projects, is to keep it simple. At the very least have the master branch protected — this is the STABLE version branch. Then have a dev branch. This branch should be as stable as possible and is the branch that the majority of pull requests, and hence code reviews, should happen on. That means, lots of branching off of and back to dev. In my own personal projects I frequently only have the master and dev, but I always have at least these two. That way one branch is always safe for a quick show and tell. In any situation, I tag important version commits.

Basic Guidelines for Using Version Control

Personal projects:

Just a note, these are more git based notes. You can only commit changes locally with git. That means you have to push things to the repository with other version control, which you don’t always, or can (say, if the internet is down) do. Even when my team uses a different version control system (like SVN), I still use git t control my local changes.

• Make lots of small commits. Commit even, or especially, after small changes that work so that when you go through and refractor everything you don’t end up losing that small change when you have to revert. There’ll be times when something just like this will happen to you and you’ll wonder why it doesn’t work anymore because you didn’t commit that one small change! Trust me: commit small, commit often
• Commit before a major change. Often times while coding you come across times when you know that
• ALWAYS MAKE A COMMENT WITH YOUR COMMIT AND YOUR PUSHES. Sure you know now the reason. You won’t 30 commits down the line and when it comes time that you need to look up this commit, your comment on the commit is going to save you a butt-load of time.
• MAKE THE COMMENT MEANINGFUL! Seriously, don’t make stupid comments unless they are coupled with a real reason. I don’t care if it’s “Iteration 15: tried -20 instead of -15”. COMMENT SMART! Seriously! Especially if it’s a working version before a big change, “Simple working version. Commit before adding more sophisitication.” You can even let yourself (and your team) know when a commit isn’t quite there, “Not a working version, but need to refractor and want to commit before the big change.” COMMENT, COMMENT, COMMENT SMART!!
• Branch often! This isn’t something someone using source control like perforce or SVN (do people still use SVN?) would tell you to do because the cost of branching in other version control systems is high. However in git it’s simple and this is where the power of git comes in. Keep separate branches for your master (the working, stable, version of your code), development, testing, and hot fixes. Branches for testing and hot fixes can be made and deleted as often as you need them and as soon as you are done with them. Branch away!
• Practice branching and merging on projects you don’t care about. As simple as git makes it to branch and merge, you can seriously mess some things up if you do it wrong. Purposely create merge conflicts (edit the same file in the same place on two different branches) and try resolving them. See if it turns out the way you really want. Do it lots of different times so that you’re sure if a merge conflict ever occurs in the future (which it will, especially when working with people who don’t understand how to manage large projects) you’ll be confident in your skillz to resole the issue.
• Push to the repository. You may not necessarily need to do this for your own personal projects, yet if you work on different computers it’s really nice to be able to pull down the latest from the repository which is quick, rather than having to transfer files between the computers which can take a significant amount of time especially for large projects. You can always sign up for a free account on assembla.com, github.com, or bitbucket, to start practicing. REMEMBER TO COMMENT!
• Commit small changes locally, but only push working versions to the repository. This is true especially when working with a team. Yet that doesn’t mean there won’t be bugs, it just means that you don’t push code you haven’t at least partially vetted to the repository.
• The exception: you have local work that isn’t vetted that you need to be able to access on a different computer and you gotta go. Create a branch on the repository to push those changes to. Merge them back into the working branch once you’ve fixed any issues
• The second exception: you need help resolving the problem. This one gets a bit into the next section (workng with a team), but again, create a branch on the repository and have your buddy check that branch out. Resolve the issue using that branch, then merge it back into the working branch.
• Practice reverting. There will come a time, lots of times, when you’ll need to revert changes you’ve made. That’s the beauty of version control at it’s heart: to get back to a working version when you need it! And now that you can branch and merge it’s the perfect time to learn how to revert. Make a bunch of branches (try making them from different commits you’ve already made), make and commit changes you don’t want, and practice reverting. This includes resetting from uncommited changes, and reverting to a lower down commit.

With a team

• ALWAYS MAKE A COMMENT WITH YOUR COMMITS AND PUSHES! Sure you know now the reason why, but how the heck would Suzy Day or George Film know? For that matter how the heck would you know why they’ve committed and pushed? ALWAYS MAKE A COMMENT WITH YOUR COMMITS AND PUSHES! It will save you and them a butt-load of time and work. JUST DO IT! Also, you probably won’t remember in a day or two anyway. Just do it. Okay.
• It’s best to avoid merge conflicts. When working with a team on a project the way you avoid conflicts is to not edit the same file at the same time. Communicate openly with your team on what files you’re editing and how you’re editing them. If you change a function’s parameters you better let your team know about asap. Pulled down a teammates file to edit it? Better let her know what you’re doing to it and why! You won’t know all the reasons why they did what they did. You’re working as a team because there’s too much to do alone. Ask before you change their code.
• Be willing to compromise so you can avoid merge conflicts. You may  change how you’re handling things. If someone is unwilling to change you can either help them see how the change you want will make their code better and easier, or change your own.
• Be willing to wait! If a teammate is editing a file you need, it’s still worth the wait to make avoid a merge conflict. Can’t wait? Create a new branch and make changes there. Merge their changes into your branch once they’ve pushed, and resolve the merge conflict. Once you vetted your code, then merge it back into your working branch, test and vet again, then merge into the repository.
• Only push working code to the repository! That’s not to say that there may still be some bugs, but don’t screw over your team by not vetting out your code as much as you can before pushing it.
• Bring your teammates that are unfamiliar with version control up to speed, and be nice about it! Show them how much easier their life will be when they do version control correctly and help them out when they have questions. It is a bunch to learn all at once. To get them started you can give them a link to this post and a copy of Pro git. Then go buy yourself a doughnut for being such a nice person. But really, in the end, it’ll benefit both of you, so buy them a doughnut too.

Good luck!

You’re not on your own though. You can always do an internet search for help with git or check out the version control guide here.

Quick Git Tag Reference Guide (Make, View, and Rename)

Here’s a quick reference to the basic git tag commands that I use frequently, but not frequent enough to always recall offhand. For a more detailed explanation of everything you need to know about the basics of git tags go here.

Basic Tag Commands

These will get you through most things you need for tags.

Make a new tag
git tag tag_name -a -m "message about tag" //creates the tag

View tags
git tag //will show list of tags
git show tag_name //lets you view information about the specified tag including the message

Share tags
git push origin tag_name //will push specified tag(s) to repo

Advanced: Renaming Tags

After creating several tags on a game we were making, I realized we should have added version numbers to the tags so we could visually identify when each tag was made by its version number. This meant renaming tags, pushing changes to the repo, and then having my teammates clean their local repos.

I garnered valuable information on renaming tags from this stack overflow.

1. Rename the tag

Simple tag (not annotated)
git tag new old
Annotated Tag
git tag -a new old^{}

2. Delete the old tag and push changes to the repo

Both kinds of tags:
git tag -d old
git push origin new :old

3. Have team members update their local repos

Have team members run this:
git pull --prune --tags

Git Pro

To be a git pro just start practicing with git. Here are resource links I recommend to get started with git. For convenience, this is the book I recommend: Git Pro, which I explain on the resource links page as well. (#ThanksForYourSupport #CommissionsEarned)

10 Ways to Improve Your Game Cameras

Game cameras can be some of the most tricky coding you do. That’s why when John Nesky’s 50 Common Game Camera Mistakes from GDC 2014 went live on youtube (The talk is embedded below), I immediately watched it! We can all benefit from these lessons from Nesky for refining our cameras!

When I first started watching Nesky’s talk I didn’t think he actually had 50 mistakes nor that he could actually get to all of them in an hour talk! But not only did he do both, I also realized that he was also right about these only being some of the issues we face. Which means we should keep the conversation going!

So here are my 10 Ways to Improve Your Game Cameras as takeaways from Nesky’s talk:

1. Use a bigger FOV for heaven’s sake! 🙂
2. If you can use a simple camera, do it!
3. Player’s intent should supersede camera scripts
4. Use the camera to give the player subtle hints, but don’t be overbearing.
5. Don’t use quick camera transitions in place of cuts. Either cut, slow down the transition, or find an in-between.
6. If rotating, camera shouldn’t rotate in place (on its own axes). Should rotate around avatar.
7. WATCH FOR SIMULATION SICKNESS (SS). It’s a disconnect between movement you see and movement you feel. Any movement seen and not felt can cause SS. Have options to turn off extra movement if you want to leave it in the game.
8. Avoid jerky camera movements and constant camera angle changes, especially during combat! It not only leads to SS, but can also be disorienting to players as controlling movement changes with camera angles. It also doesn’t look as pretty, ahem, as aesthetically pleasing.
9. Allow players to invert controls. It’s a significant portion of players that want to invert (like me!). You’ll lose players otherwise.
10. Implement, test, iterate, test, test, test! Repeat.
11. Re-Watch John Nesky’s talk as needed. 😉

I just love GDC talks. There’s always so many of them at the event that you literally cannot attend all of them. So thanks to GDC for posting this treasure to the public. Thanks to John Nesky for being willing to share his own mistakes so the rest of us don’t have to suffer… as much! And for the rest of us I wish a big: Good luck!

Game Projects I: Week 11 — Game Developer Conference (GDC)

GDC was amazing. This was my first time going and I’m so glad I went! I would have loved to be there for more of it, but family business took me away for two days in the middle of it. However I got to listen to some amazing talks. The Friday before GDC I actually pulled out my Mathematics for 3D game programming and Computer Graphics by Eric Lengyel and read throught chapter 2. I’d been avoiding linear algebra stuff since most of it didn’t fall into my area of math expertise and I remember some parts of the class being very overwhelming even though I did get an “A.” However, when I got to the part in chapter 2 about Vector Spaces I knew I wasn’t in the same place I was as a freshman in college. Vector Spaces are just special groups. It was group theory! I’d taken Modern Algebra my senior year (study of groups) and I’d never had a reason to look up my linear algebra theory until then. It made so much more sense. It’s funny what sometimes how new knowledge makes once difficult things simple. After taking modern algebra and lots of time for my to think on the idea, Vector Spaces got a new slot in my brain.

Well Monday morning of GDC I was looking forward to a day of math tutorials. I knew my friend Skip would be there. While I was riding the escalator up to the room I took a look at the day’s speakers. First up, Eric Lengyel on grassman algebra. No way! I was just reading his book! It was so cool to get to hear a talk by someone who’s book I was readig. Eric’s talk was by far my favorite and I can’t wait to implement the grassman algebra he showed us into my game engine.

There was one other talk during GDC that I loved. It was the post-mortem on the Human AI for The Last of Us. It made me feel so much better about all the crazy meshes and ray casts I was doing and thinking about doing for the projections (previously known as ghosts) in Ragwheel. It made me feel like it was doable as well and that I was on the right track, so to speak, to making the projections a reality.

I had a hard time at the career fair my first day there. I ended up just going to a couple talks instead. Then I went to my school’s booth. I’m so glad I volunteered to work there! It helped me break out of my shell and start talking to people. It was fun being on the other side of it and I understood both sides. It got me really excited to go to the career fair the next day and talk to some people!

The career fair was awesome in that I wasn’t looking for a job from there, just feedback on my resume. After breaking myself to talking to people again the day before, I was able to get some excellent advice on my resume.

Advice for people going to GDC: take some printed copies of your resume and ask people to give you feedback. The very least you’ll get some good advice on what to make better, the most they may LOVE your resume and you could get an interview! I didn’t stop by anywhere that I was sold on working for, and most places weren’t looking for interns or weren’t taking resumes, but I got what I wanted. It gave me what I needed to improve myself as well as a game engineer. It gave me more focus and I got to learn about some companies and whether or not I actually wanted to be there.

Also, if you have the opportunity and you’re a bit shy, like myself, and just need a kick start to talk to people, then volunteer at a booth. It will really help you see the otherside and help give you the confidence to go talk to other people. Getting a wingman to go with you is always helpful to. I chose to go by myself so that I wouldn’t chat with my friends and possibly miss opportunities. This also allowed me to meet some cool people in line while we waited. However the wingman thing isn’t a bad way to go either. It’s best if you go with someone in a different area of expertise. For instance a game designer and an artist. A producer and an engineer. Or if you’re two engineers than make sure to distinguish yourselves. That way you’re not competition to each other. Even if you’re both game engine, which areas do you focus on. Or perhaps you’re both graphics but one does more gameplay and the other more engine, etc. Just always present yourselves as doing two different things, even if you overlap in what you like. You’ll hear about more job opportunities and have more to talk about with the recruiters.

 

Game Projects I: Week 10 — Spring Break

Spring break was amazing! I got to go to my brother’s work and meet his team and bosses. We set up a meeting with his bosses and I got to interview Christina. She was really nice and open. She, like myself, had a degree in something other than computer science for her undergrad and then switched to computer science for her masters. She was doing really well in the company and had excellent experiences. She asked me what I wanted to do and I told her I was open to new experiences. Then she gave me some excellent advice: make a list of all the things you want in a company that you want to work for. For herself, her company met everything she wanted.

She also told me, in talking about being a woman in engineering, that she’d never experienced discrimination. Being in the workforce in California where they’re more forward-thinking and woman are urged to seek more professional jobs, if anything she’d experienced anti-discrimination where she was actually helped out a bit more because she was a woman.

On that same note she told me to always think of myself as an asset.

“You’re an asset to the company. You are. You’re worth every dollar they spend on you. Be confident.”

A Reference for Setting Up Git for the First Time: A Very Brief Overview of Installation and Set-Up

This is a very brief overview of installation and set up of git for reference purposes. This isn’t for teaching you git. I’ve found that as I’ve taught people git these are the things I constantly had to look up or have them look up just for getting started. So I thought I’d make a brief overview of the steps to make everyone’s lives easier.

For information about git resources, including a book that can teach you all you want to know about git, I have a post about that here.

Important note: some of these steps are specific to the gitlab git server repository. If you are using a different repository check their documentation.

Git Installation Overview:

Basically all you need to do, for Windows, is download git from git-scm.com. Install git bash (which will be your command line interface). A git gui is not necessary, but can be helpful if you’re not a command line pro. (The pros use command line! Just saying! 😉Become a pro!)

Git Set Up:

Set your user name and email. These “tag” your commits. In git bash:

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

At this point you can start using git locally. If you don’t have a git repository there is nothing further you need to do for set up. The rest of the article is for connecting to (in this case a gitlab repository) git repository to push (like SVN commit) and pull (like SVN update), and lots more for easy collaboration among your fellows.

Connecting to a Remote Repository

Create your SSH Keys (You can add multiple):

(Should match your email from above)

ssh-keygen -t rsa -C "your_email@example.com"

• The default place to save is correct (unless you’ve changed your settings) so just hit enter.
• If you want a passphrase enter it followed by an enter twice. Otherwise hit enter twice.

The ssh key will now be saved in your user folder under “.ssh”. By default in Windows this will be in your user’s directory. Open the idrsa.pub file and copy the whole thing.

Save the key in your repository.

In Gitlab go to:
My profile -> Add public key
paste the entire key in the “key” box. Title will auto fill.
Select “Add key”

You should now have ssh access to the git repository and will be able to push, pull, clone, etc.

Make/Update your server repository

If you have a blank project: Clone/create a new repository:

Navigate/create the directory where you want the cloned project to go. (For SVNers, this is like checking out a project.)

In general, to clone from a repository via ssh the command is:

git clone git@:/.git

For example project it’s this:

git clone git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git

Once that is done, you need to create a local repository and then tell local git where your origin is. Git won’t make an empty repository unless you tell it to. So make a dummy file and add it to the repository and push to origin and tell git to track the upline:

cd project_folder
touch README.md
git add README.md
git commit -m "add README"
git push -u origin master

If you have an existing project (but not a git repo)

cd existing_project_folder
git init
git remote add origin git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git
git add .
git commit -m "Initial commit"
git push -u origin master

If you have an existing Git repository

cd existing_repo
git remote add origin git@git.eaemgs.utah.edu:john.doe/BestProjectEvah.git
git push -u origin --all
git push -u origin --tags

The “-u” in the “git push” tells git to track the branch on the remote branch. In future pushes then you don’t have to tell git which branch on the origin to push to. Just do a “git push origin $branch_name”.

Update your remote url

Sometimes your remote url will change. (curse the techs right?! 😉 )

To check your remote url run

$ git remote -v

This will list any short name remotes along with their urls.

To update run:

$git remote set-url  

If you need more details the

$ git remote set-url --help

is in fact very helpful.

Good luck! 🙂

Let me know if you find anything that is incorrect or other important startup commands to get going. I’m happy to refine. 🙂

Game Proto-Publishable 4, Week 5 — Submitting for Certification

We did a LOT of work on this game and it was fun to see it all come together with all the work and additions that we did after the post-mortem. Gagan, Robert, Brad, and I put in a TON of hours to get it done over the weekend.

The buttons have been updated from this screenshot. They’re very snazzy now. They’re rounded and gray, and on hover they are a very cool orange.

I added in the “real” UI complete with feedback buttons (complete with a form that sends us an email!), replay, next map, and a “How to Play” screen. Robert did all the art, though occasionally Gagan helped me pull out assets from Robert’s art.

We built all the levels, got the colors down for the overhead map, I got someone to play test the first level so we could decide on the amount of time, got rid of actor mesh, IO (by removing it since our game isn’t currently dependent on it), and many, many more errors.

Gagan, Brad and I stayed in the game lab til 4AM Saturday night to get it done and submitted. Around 1:30am they started saying let’s just come back, but I knew I wasn’t coming back (especially cause we would have just spent more and more time on it), so we stayed. It was fun and painful all at the same time!

At one point I just needed the master and Gagan and Brad needed a break. So while I was busy working, they made paper planes and had a competition. 🙂

But we got it all built and submitted. Yeah!

On Monday I had several people asking me how to build and submit to Windows8 so I sent my notes to self on the process the whole cohort. I told them to tell me if there was anything wrong, since they were just my notes to me, and I know people used them because two of the producers added notes to mine. I’m glad I could turn it around and help out my cohorts.

Hailin also asked me in the lab to help her out with building. Her team depends on IO (they read in the narrative to output to screen), so we did some research together on that. From what we found it is going to be a lot of work on her part to get it to standard with Windows 8. Windows 8 is a bit of a pain to work with. It is very particular and the notes on how to post to the store and the requirements, especially with libraries, and with Unity, etc. are all over the place, and sometimes extremely hard to find, if you can find them at all.

And so, I have attached my notes on how to build from Unity to Visual Studio 2013, to the Win8 store. I don’t know everything you have to do for certification, but I do know how to get it built at least.

If you use the notes and find anything wrong, some important details that have been left out, or a better way, please let me know in the comments below!

Deploying a Game from Unity to Windows 8 Store Notes

Submitted!

Brad called me late Tuesday (yesterday as I write this) to ask me my opinion on what to put for description and notes to testers for the certification submission. We got Casey involved in editing and it turned out very nice, and Brad submitted!

Thank goodness Brad figured all that stuff out! And Casey has been busy on making a website and media pages for our game. So grateful for my producers!

Oh no!

Brad called me early Wednesday morning (or today as I write this) to let me know we’d failed certification but it didn’t look like a lot of errors. The big one was it wasn’t working with touch as we anticipated. This was a hard thing to test because my team only got the tablet for a few minutes at a time and most of the time I “had” it I was sharing it with other teams who were trying to figure out the deployment to tablet. Once that got figured out I didn’t see the tablet again! I did have my laptop which rotates into a tablet, but it isn’t a true tablet because it’s still behaves like the real PC it is, so the touch on my computer doesn’t work like it does on a tablet, which is why it didn’t work for the Win8 Store testers like we’d hoped.

However, Microsoft donated three tablets to our lab. They only came in yesterday, but it is going to be a big help to at least my team. Hopefully they have accelerometers!

There is more to this story that has yet to have happened. We’re going to do whatever we need to do to get this published, but first Gagan and I have to finish our monster final C++ assignment that’s due Friday. We have to write a memory manager! Despite it being Wednesday, I don’t know how much I’ll be able to get done. It took Joe, our professor, eight hours to program his. We don’t have to have ours working (accept for alloc and free), but the more we have done the better our grade, and he’ll also be looking over our other code which I know I want to beef up a bit. Lots to do! I’ll probably spend the rest of today and all of Thursday and Friday up to the due time (midnight Friday) working on it. I know Gagan will be doing the same.

Stay tuned…

Game Proto-Publishable 4, Week 4 — Build and Present

Side-loading on the tablet

The biggest issue this week was figuring out the build for the tablet, and then the store…

In this I have to give another shout out to my fellow class mates. Nathan originally had figured out how to do a win8 build, but he hadn’t actually side-loaded it, like we’d all assumed at the beginning because that’s what his producer told us. But it got me started with the tools I needed: Unity, Visual Studio 2013, and the inital build setting option. Sidd B. and Vinod really helped me get the build from Unity to Visual Studio 2013 without any errors. Sean, Abhishek, and I tried for quite some time to get the Visual Studio Remote Machine debug to work,and I believe a couple others tried as well, but it just didn’t want to budge. However Tony was able to figure out how to just side load it onto the tablet and then showed Sean who then showed me. PHEW!! It took us til Wednesday 11pm to get it all figured out.

Just in time

My team stayed even later that Wednesday as Gagan continued to work out bugs in the movement and I finally got us a semi-working menu screen just in time to take a video and get it off to Casey for the presentation.

Oh, and I can’t remember if I mentioned it last week, but Robert figured out why the 3D text was blurry, (the default image size is SUPER small so it’s always blurry unless you make the default image size bigger), and fixed it. Took him five seconds. He’s a genius.

The presentation

Casey did another great job on the presentation and the game was well received. Most of the feedback we received was already incorporated, or was going to be incorporated into the game, so we didn’t worry too much about that.

All the teams received feedback that they wanted to incorporate into their games so Brad, our amazing producer, got us all an extension through Tuesday! Go Brad!

Post-Mortem

It felt a little strange to do a post-mortem when we knew we weren’t actually done with the game. Especially since right after we were done writing up our postmortem time-line with the good and the bad, we flipped the whiteboard around and started writing out a final to do list!

 

I love this team.

The bad

I’m going to change things up this time because honestly, there isn’t that much bad to talk about. Lots of bugs, some issues with different version controls, would have been good to have just a little bit more artist to engineer conversations especially since our artist was involved in some of the programming just so that we didn’t have to spend time fixing code later, it would have been nice to have more involvement from Casey, and then BUGS.

Casey gave Gagan and myself a small critique each: Gagan says, “It’s easy!” too often, and as for me Casey said that he didn’t mind my involvement with editing and writing and presenting, but warned me that some producers might. Something I’d already noted in my last group, but it was a good reminder.

This really opened up the conversation for me to be able to talk to Casey about his lack of involvement this go around. From what he told me it really sounded like he was experimenting with his identity on the team as on previous teams he’d experienced that his team members didn’t want his involvement. However three of us at least chose to be on this team because of him and because he wasn’t here we felt let down. He was sick for part of it, but he also didn’t communicate that to us.Casey also mentioned that a big reason he, and Brad just a tad too, weren’t quite as involved was because they felt I was handling it just fine. Which I was keeping engineer/artist stuff organized and solving problems, but then I didn’t have anyone solving my problems! Either. But that was a big compliment to me, and I’ll take it. I wish he would have asked us what we needed/wanted from him instead of assuming, but then one of us probably should have asked him to be more involved. Of course that didn’t occur to any of us until we had our post-mortem discussion. Whenever he was here he was awesome, which is why we needed him there more often. However, I think he really listened to what I had to say, and what Brad and Gagan said as well, and I think he’ll be more involved moving forward.

The good

So much to say! Strong concept, excellent collaboration. Brad really stepped up and became the lead producer. He did an excellent job and was nearly always here with us as late as we were! Excellent engineer collaboration. Casey pointed out that he was concerned that Gagan and I were going to have issues, but then was pleasantly surprised that we got along so well.

Learning git and then switching to SVN when it was better for the team. Being flexible. Artist/engineer collaboration. Our artist doing the overhead map, enemyy movement, and animation. Getting the 1st, 2nd, and 3rd playables! Great pitch and final presentation. Working game. Sound (Brad). Mock-up levels from Brad. Figuring out build. Getting everything merged.

Being awesome.

What I learned

ASK FOR WHAT YOU NEED! Collaboration among teams is essential! There’s no way we would have figured out the build for the windows 8 tablet and store if we hadn’t collaborated outside the team.

I discovered for myself that I could figure that stuff out, even if it was just googling, asking others, and lots of trial and error.

My team is awesome. We’re going to continue building and creating this game and I think it’s going to go directions we still haven’t considered. It’s going to do awesome!

Apparently, I love the word AWESOME!

After a certain bad experience, and still feeling upset, I wasn’t so sure about producers and I was okay with Casey not being as involved. But then, one day, Roger stole our producers away. Kyle stood up about 5 minutes later in a panic, “Where are my producers? I need my producers!” I wondered what he was thinking, as I was still feeling slightly embittered. But then, 20 minutes later, I needed my producers! Where were they! And then I proceeded to be angry with Roger. 😉

When Casey and I were having our post-mortem discussion and I shared with him that story, it finally came to me what it was and I told him:

“It’s not so much about the role [producer, engineer, artist, whatever]. It’s about the people. And I, and our team, needed you here.

I really hope that everyone in our class gives everyone else some slack. We were all experimenting with our roles and learning. That’s what this whole experience is about. And for those producers that felt their team didn’t want them as producers, then don’t act the producer! Act the person that is creating a game with them! That’s what they want anyway: someone who’ll help them make an amazing game! It’s not about the role, it’s about the people.

Game Prototype 3, Week 3 — 2nd Playable

This has been a very interesting group to work with. The mix of personalities and leadership styles, especially as we are all leaders, has been a bad mix, mostly because the disagreements have really gotten in the way of us being able to get our work done. As I mentioned last week, engineers and artists, and especially engineers, need time to do our work.

However, it has all worked out in the end. There has been some good collaboration, and some excellent ideas from every person. The game definitely would not be as good as it is without this unique set of people, and I have certainly learned a lot so far!

Also, my fellow engineer, Sty, has been great to work with. Not only was he willing to stay as long as we needed to, but he always treated me as an equal. I could also rely on him getting his work done and him, me.

 

I LOVE MY FELLOW STUDENTS!!

With all the disagreements, we were really worried about getting our game done in time. The 2nd playable was due Thursday! The work flow was as slow for Sty and myself as last week’s, but never fear, our fellow students from different groups willingly helped out. It was still rough because every game has its own unique mechanic that no one else knows how to resolve, but it certainly helped when someone could just throw you a function you needed, even if they weren’t sure how you were going to use it.

Sty and I also had to merge our code this week which was not an easy task with Unity. It’s not real programming (not this initial part at least) and I’m not really liking it, but I do see all the advantages. It was definitely easier than programming our game in 2.5D on our own, but still a pain. We had major issues with getting our code to merge and work correctly. Win for me! I was able to get it to work and collaborate with Sty to add a few lastminute details right before Roger, our EP, came over to review the game. PHEW!!

2nd Playable Review

Roger gave us some excellent ideas. My favorites were: 1) Since we didn’t have time to engineer only being able to build X number of towers with Y amount of Zzz’s (our money system), he told us to tell play testers they could only build X towers. This was an EXCELLENT idea and really helped us in our play testing. 2) Since the player has no time to study the map before waves of trick or treaters come, we could use that fact to really sale the game: frenetic pacing! This is actually what made me love our game: that you have literally one second to decide what goes where. It’s super fun!

Week 10 Lecture

Roger gave an excellent lecture this week and I took crazy notes! Here is a sum up of what he told us and some of my thoughts mixed in.

Roger started out by saying that some of us have either started to, or are about to, question: what am I doing here? or feeling like, I don’t believe this crap. He told us, “That’s great! Embrace it. It’s wonderful. That’s how you should be feeling.” Why? Because we’re in ten weeks, we’re tired, stressed, and learning a ton. It’s also the beginning of the journey and a natural time to start questioning. Part of us are also feeling like, “This is the best thing ever!” and “I’m finally where I belong.” Clearly the two thoughts are dissonant and he told us to become comfortable with feeling dissonance. We can feel, I hate this class, and at the same time feel, I’ve discovered my future! It will all work out.

Since artists and engineers have hard skills, and producers are more about having to sell their soft skills/processes, he told us what producers should be doing. The main roles of producers are:

 

1. Communication: make sure everyone is on the same page, dealing with the proper problems, and communicating the game to outside people. They are not the manager, but the communication officer.
2. Filling in: help out with engineering or art as needed.
3. Triage: make sure everyone is working on what is important and that the program gets out the door, is fun, and is understandable.

Producers’ primary goals are:

1. Game is good
2. The team health is good: He told the producers (and the rest of us) that just as you’d give yourself slack, give your team slack too.

At the beginning of the semester everyone gave everyone else the benefit of the doubt. Now we’ve all been evaluating what everyone else is doing. This is the perfect time to give everyone the benefit of the doubt again. People have been playing with their professional identities as we were encouraged to do. We’ve all been learning throughout this process, and have sometimes chosen identities that don’t work well with other people’s.

Time to take a step back, take a big breath, and move forward with an open mind.