Helping Hand

Learn Version Control

Learning version control now will not only make your current life better, it will make your time in MSEAE and as a professional game developer much easier.

The University of Utah supports SVN, but if I can get my way we’ll hopefully being moving to git. Since I got one of the tech guys for the MSEAE program to set up gitlab (which is the best git repository application I’ve used. So if you’re going to set one up for yourself that seems to be the best way to go), it may now be a possibility! Git is the better choice anyway. ūüėČ

The tech guys for our game design lab are awesome and are super willing to help out with so much! (Word to the wise: Always be nice to the tech guys! They can make or break you!)

You’re going to be working on some seriously complex programs and while SVN (which I learned on day one of the C++ class) has it’s upsides, when compared to git it is seriously lacking. Branching and merging (which you’ll be doing¬†a lot¬†of) are seriously simple with git. Even if you run into a merge conflict — which will happen, I even did it to myself the other day — it’s easier to resolve in git.

If you learn git, I guarantee learning SVN will be a walk in the park.

SVN is pretty simple when compared to git. So if you don’t want to learn SVN til you get here you’re not going to be behind if you at least have an understanding of how to use git. Git is more powerful, and so there’s a bit more of a learning curve, but it won’t be time wasted, promise! LOTS of program companies use git, especially gaming ones, so you want it on your resume, no? Besides, it’s lots easier than learning a language. It’s like learning SQL or HTML, it ‘s not that hard. (Though I will say, version control is more complex than SQL and HTML put together, but you get the idea!)

Best book on the topic, which you can also get for FREE, is Pro Git. I’ve had people who are experts on git tell me this book is the best, so it really is. If you want to support the author you can buy Pro Git on amazon. He did a great job, so seriously consider it. Just saying.

Pro git will walk you through how to install git — for fellow windowers: I always get the command line and git gui over the git cheetah. I prefer the command line, but it’s also nice to be able to visualize all the changes and gitk comes with git gui. There are lots of things that are actually easier to handle through the command line — what version control is in general and how to use it, branching, merging, etc. The important chapters are one-four, and nine. You can almost read nine first, but be prepared: it’s highly technical and you’re not doing much other than reading. I read the first half of chapter nine and then read chapters one-four. It gave me a better understanding of what was going on when I used certain commands so I wasn’t wondering why I was doing them.

Advantages to Version Control!

I know what you’re thinking: I have to learn another thing! I already have a list of languages and programs to learn. Listen to me oh ye of little faith:¬†Dude, real version control is going to make your life so much easier!¬†Quit making copies of your entire project and renaming it. You can never remember the exact difference between the copies, it’s hard to merge, and it takes up a lot space. That stuff is for kindergartners, enter the world of professionals and gain the benefits:

  • Your can see (especially with gitk and other git commands), changes made between commits.
  • It’s a lot faster and easier, and you can do it more often, to backup your program.
  • It takes up less space to backup your program this way. (See Pro git for more on how git handles saving the differences, branches, etc. which saves so much space.)
  • It’s a TON easier if you need to revert changes.
  • It’s incredibly stupid easy to merge changes.
  • All the professional programmers are doing it! ūüėČ
  • A lot of game companies use git.
  • Your life as a programmer will be much improved. Once you get the hang of it you’ll wonder how you ever got along without it.

Basic guidelines on 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 an SVNer would tell you to do because the cost of branching in SVN is high. However in git it’s simple and this is where the power of git comes in. Keep seperate 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 or github.com 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 the heck would Suzy Day or George Flim 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!
  • 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 donut for being such a nice person. But really, in the end, it’ll benefit both of you, so buy them a donut too.

Good luck!

Advertisements
Helping Hand

The Light that Follows…

When our professor of Rapid Prototyping told us we had to keep a weekly blog, my thoughts were, “Sweet! I love blogging! … What do I blog about?”

So I started with something silly. But the thought of what I should blog about, it’s purpose ¬†has been on the back of my mind since day one.¬†I wanted it to be something more than just, “Here’s what I’m doing this week¬†as an MSEAE student. Blah, blah, blah,” with no direction or purpose. Having been a copy editor for school newspapers and a magazine, I helped pick out themes for each issue. From tis I know the importance of having a¬†central idea around which to build your work, because¬†the issues that had weak themes, or didn’t have one at all, were less well received. Why? Because the writing was hodge podge with no purpose and direction. It’s the writing with a purpose that grabs you. Actually, it’s true of game development, art, music, and any work we do: people are drawn to why, to purpose, not to the exterior. Whatever you do should be done with a clear why. Then everything that doesn’t belong to your why falls away, and everything that does is drawn to it. ¬†It’s this knowledge that has driven me to find the thread that will connect the posts on this blog. — (Phew! That was a long aside! Moving on.)

The MSEAE program, #2 graduate game development program in the US, is AMAZING! I am absolutely loving it! I love my cohort, the classes, professors, and I even love doing my homework, really! Who loves doing their homework! The creation and study of games is what I am meant to do.

But it ain’t easy. I’m putting blood, sweat and tears into this. My all and my everything. It’s rough. It’s a lot of work. And I’m very tired.

Yet I know that this is what I’m meant to do: create games to bring magic to life, have the people experience the beauty of games, and help everyone who follows after me, especially in engineering, so they have an easier time of it than I am having.

So that’s the thread: bring the magic of life through the beauty of games, and light & knowledge to those who follow after.

No small task. Yet I know it to be my purpose. I move forward undaunted, lighting the path.

Now if only I could get a little sleep. Well, I guess I can sleep in two years.

Game Dev Adventures!, Helping Hand

Game Prototype 1, Week 2 — Conquering Issues

I’m happy to say that none of the issues I encountered were with my team. They were all great. No, it was with the blessed and cursed computers.

Developing in Windows

All of my issues were with Moai and my lab computer which I had that first week through the weekend. By Tuesday this week, thankfully, I had them all sorted out.

Now last week we got our desks in our game lab, where our rapid prototyping class is with all our computers and all the software we need on them, which is in a locked area in a building that is only ¬†unlocked M-F 8am-5pm, but we do have card access. Now only if that card access worked…

That means if we need our computers we need to set up some remote access.

Computer issue number one was that Moai wasn’t even installed on our computers. When they gave us the language to use I thought they’d tell us how to use it, provide us a book, or at least have it installed on the computers already. Nope on all three accounts. But they did give us a website!

I installed moai-sdk, which was easy, but had issues setting up the proper environment variables because I wasn’t an admin. Wednesday and Thursday that first week I spent a significant amount of time outside of¬†class trying to get everything set up on my computer so I could remote access in, get my blog, and get Moai running locally. ¬†I got everything going by 8:30pm Thursday night, with one exception: I didn’t know the final piece of the remote access, which software to use.

My undergraduate degree was mathematics. I did all of my programming in linux and was used to remoting in via ssh. But that’s not the same as a Windows remote access. I feel like these first two weeks I’ve had to learn a lot about developing in a Windows environment.

(Note to those that follow: learn the following for developing in a Windows environment:

  • Setting up local and system environment variables; when to do which and why
  • VPN: if VPN is new to you it is just a way to connect to a network remotely. If you’re connected to VPN you can access the server files, and you can connect to a computer via Remote Desktop Connection.
  • Windows’¬†Remote Desktop Connection. For this to work you have to be on the network (either locally or connect via VPN), you have to have the computer’s IP address, and the computer you want to connect to has to be set to allow remote desktop access.)

Luckily I have a pretty smart network guy at work who told me about Windows Remote Desktop Connection.¬†Then it was just a matter of figuring out the U’s VPN access and connecting, which I did from work. The issue, Moai didn’t work.

I decided to set up the remote access at home too.¬†RDC works straight out of the box with Windows 7 pro, and Windows 8, but you need a patch for Windows 7 home. I needed the patch which my awesome brother found out and then patched my computer for me. (It’s nice living with a tech!)

Once all that was working I had access to my lab computer. I hopped on and ran Moai and the samples didn’t work. It took me all of the next day, and setting up local Moai instances, before it became apparent that there was a setting in the lab that wasn’t allowing Moai to run when accessed remotely.

I told our lab techs about issue, I was thinking it was the VPN blocking the host from Moai, they discovered it wasn’t the VPN but another issue, and basically said that we’d just have to use it locally. Well, I did have my local instances…

I let my team know, and a couple others, that running Moai remotely, if connecting to the lab computers at least, was a no go. So my time wasn’t completely wasted. Right?

Version Control

My team also asked me to be the lead on version control. The other two engineers had only just been introduced to Version Control (SVN) it via our C++ class (I think I’m one of only four or five engineers that have used real version control before), and Brenton had used SVN previously at EA I believe.

On day one the game lab tech guys said they had a git repo. So when I followed up on that it turns out what they had was a Perforce repo. Not the same thing. I promised I’d try it, but I didn’t like it and felt like it was too much for me to have to learn, on top of Moai, and then teach my fellow engineers that too especially since I’d already begun to teach them git and we’d received a brief overview of SVN in our C++ for Game Developers class. I didn’t want to throw a third VC at them. I know a lot of game labs use Perforce, but usually they use it with an app so that the developers can continue using git locally. Also perforce isn’t free (and the lab guys reached their license limit when they added me which left my team hanging), and, did I mention I don’t like Perforce. When the time comes I’ll learn it, but one thing at a time, not three! So I asked the tech guys to set up a git repo. I told them about git lab and they said they were working on “legit git.” On Saturday of week 2 I got an email from the tech guy doing the legit git work, that for fun he decided to try git lab and had it up and running really quick. I ended up spending the weekend of week 2 testing the git lab. Turns out he had missed an ssh setting. Once that was all set he sent out an email to all the cohorts and let them know how they could use it. By Tuesday of week three the EAE program had a git repo solution!

You’re welcome all current and future cohorts!

However, Tuesday by week three was a little late in the game for a git solution and to have my team switch over to that wasn’t going to work. Not with all the issues of Moai. So as much as I love git, I decided to run with SVN. Total bummer for me,¬†but you do what is best for the team.

Learning Moai

Learning Moai was the biggest hurdle.It is poorly documented and not widely used, the samples aren’t commented either. So most of the time you’re guessing about what is going on. ¬†It certainly didn’t help that my time was all over the board on solving computer issues and version control solutions. ¬†So we didn’t get far, anywhere?, on our game development this week.

Okay, okay, we weren’t getting anywhere on Tuesday. I was really stressing about it and while I was washing up Wednesday night I had a solution.

Moving forward on development

This week we were introduced to SCRUM and stand up meetings. During our stand up I told the group that our block, for all the engineers, was we felt we didn’t know Moai and so hadn’t developed the game, but that I had a solution. I took on the ¬†game environment, Binoy the mini game of the splicing, and Hailin the pet buying UI. This is when the real game development began. We were able to focus on just what we needed and began to create the pet world.