What do you do if you feel that your coding project is getting overwhelmingly complex? What tactics or techniques do you use to reduce complexity or tolerate it so that you can carry on with the project?
What to do if a coding project starts to feel too complex to handle?
Yeah I find when a project is getting too complex it's time to take a step back and take a look at the bigger picture.
I don't think you can "reduce" the complexity of the project without reducing the scope. You can try using diferent libraries or framework to reduce the amount of things you need to do, which is in fact reducing the scope of your project (instead of implementing a physics engine, use an external library).
If you want to handle complexity you need a good design, refactoring could work if you notice a change could make things easier for you, but refactoring alone means nothing, you need some plan. A good thing to do when working in a complex project is doing a divide and conquer strategy, divide the problem in smaller independant problems. If you need a leveling system, think of the leveling as a standalone feature independant of the rest of the game.
Something that could also help in complex projects is writing automated tests. With a lot of tests you can do things without thinking too much in the consequences, just do what you need and focus only in the tests that failed.
I agree with refactoring (depending on some things). At least with the type and scope of games I'm working on. I find when things have gotten too complex, much of that is due to just poor planning on my part. I hit a point where adding even small things to the game can a monumental task, but mostly only because I've designed things...not optimally. I'm having to rewrite code all over the place to accommodate the new change. I can usually refactor things to streamline adding new elements to some degree.
If your code is pretty clean and well planned out, then obviously this wouldn't be much of a solution. If your game is truly just complex, and not just the way you've implemented things, it's possible you've aimed above a single-person project, or at least a quickly finished single-person project. You can dig in and keep coding, acknowledging that it's going to take time, or seek out additional help.
I find, at least in my projects, there's kind of a natural curve of productivity though. The beginning stages of creating the game require little effort but result in huge payoffs. As things go on, you start adding that complexity, and dealing with the more difficult little problems. They take longer, and there's little to show for them. It can feel like you've hit a wall of sorts, but I think to a large degree that's just the nature of development.
I have pretty limited experience in this though. Just my observations so far :P
Complex code can be cleaned up by refactoring as mentioned previously. However, sometimes you're thinking "Man, if I go changing everything, then stuff will break."
This is when it is time to add some tests. It goes something like this
1. Try to make the change.
2. If it is too hard to make the change, refactor the code until it is easy to make the change, then make the change. (This is important)
3. If refactoring the code is breaking things, add some unit tests to the class/module/whatever so that you feel confident to make the change.
You don't have to go crazy with test-driven-development or extreme programming or any of that stuff. When you break something, figure out a test that would have caught the bug, then add the test, fix the bug, and move on. Eventually you will test all the scary parts and feel good about doing major changes to support new features.
I have found that this happens to me when there are too many inter dependencies in my project. This means parts of my code cannot exist on its own. When designing a large project, I like to think about what libraries would be useful to my project and design my code to have parts like libraries that don't depend on the rest of the project. Think of the dependencies as a stack of blocks. Upper blocks only depend on the blocks below it. You should be able to remove or switch out upper blocks and the lower blocks should compile and behave just fine.
If you have good structure in a project, it can grow to be very large without being overly complex.
Just saying "Refactor" isn't all that helpful. Refactoring is the correct term, but I feel like the original poster needs more than this. :)
Hacking in a new feature is fine. I usually spend a little bit of time thinking of a design, and then hack away at it until it "works". After it works, I better understand the problem and can design an even better solution. But at this point, most new programmers move on and keep on hacking in feature after feature until the code becomes a jumbled mass of crap. If you don't spend time to look back on existing code and making it better, eventually your code will become so complex that you can't do anything else with it.
If you've just been hacking away for months and haven't been cleaning up your messy code, there's a couple of directions you can go.
1. Try to salvage the project by identifying your pain-points and fix them.
2. Start a version 2 of your project. Migrate over any code that's clean, redesign any code that can be saved, completely scrap things that can't be saved.
And next time around, spend a little time after each new feature and look at your code. You can hack it to "make it work". But you should "make it right" before moving on.
- Eck