chris.software     development     reviews     feed

Workflow

I’ve been integrating a lot of different little technologies to help me with the development of Ne+. One of the things I quickly realized is that my main source code repository is precious, something that I need to protect and keep clean while I’m creating a new feature or adding in some existing code. There are many ways that one can do this. Sometimes, you want to drastically alter your code and refactor many of your core classes or functionality to be more organized, or create a more streamlined design. It’s entirely possible to accomplish this without destroying your project. If you aren’t using source control, you’ve got bigger problems on your hands and should take care of that immediately. However, if you are using source control, it becomes infinitely easier to manage changes like these effectively.

I’m using Git for my project. With Git, the technique for developing a little something on the side, as opposed to in your main branch, is to just create another branch. It’s a simple concept - you’re creating another branch in your development road, one that could eventually come back to the main road, or lead nowhere. If it leads nowhere, you can delete it… otherwise, you merge those changes back into the main project and continue on. There are a few source control methods that contain this concept, but if you happen to be using something that doesn’t, make a copy of your project and do it yourself! The point is that you need to be able to experiment.

Another way to introduce a new concept into your project is to prove it outside of your project first, so that you’ve got some code you can use, as well as a general idea of how you might want to integrate it with your existing code. Create a new project and do the absolute bare minimum you need to in order to see the new concept working - this allows you a sandbox environment where you can do whatever you want. I have found it easiest for me to do this, particularly when I was trying to get the lighting involved with my project - it was easier to make it work on its own before getting it to play nicely with the camera and physics that were already in place.

If you have a nice environment for testing new concepts, I find that it’s much easier to keep from making your main project a mess. I also like tagging my code in source control at major landmarks. If the lighting is working for the first time, tag your project. If you got the bugs ironed out, tag it again. Leave some breadcrumbs, because you can’t be sure when you might have the need to retrace your steps later.