I spend about 99% programming, 1% optimizing. Is this normal for most people? What is your programming to optimizing ratio?
Probably 70% programming 30% optimizing, or maybe even 60% programming, 40% optimizing.
My game is a slope detecting 8 way scrolling platformer with 2 player simultaneous co-op (that might be removed for speed reasons if I can't optimize everything enough).
Everything has to be as fast as possible in a game like this or it'll hit lag quite often. I try to get a good feel for how slow each routine can be in a worst case scenario, and use a cycle counting emulator to time it. If it's slower than the goal, I go through it line by line multiple times to see if I can make it faster. If I can't the way it's written, I'll try to replan the logic so that it's faster.
Since I program more in HLL languages like C++, I'd say my time works out more like this:
Designing / Concept: 85%
Programming: 15%
Optimizing: 0% (let the compiler do it)
For me it depends a lot on the project and the platform.
In high level languages it's usually like this:
Designing: 20%
Optimizing the design: 10%
Programming: 60%
Optimizing the code: 10%
But in assembly it's more like this:
Designing: 30%
Optimizing the design: 30%
Programming: 38%
Optimizing the code: 2%
Dirty trick: run game logic at half speed, and motion tween between frames.
Dwedit wrote:
Dirty trick: run game logic at half speed, and motion tween between frames.
That's not a dirty trick, that's a very practical approach.
I do something similar with my PC game attempts.
It seems the better I get the less time I actually spend programming.
think it's something like this for me:
Designing: 20%
Programming: 40%
Optimizing the code: 10%
Documenting the project: 10%
Support: 15%
Bugfixes: 5%
I often forget about that documentation and support, and bugfixes takes precious time :/
With bug fixing in a separate catagory:
90% bug fixing
9% programming
1% optimizing
I'm surprised everybody else takes longer optimizing than bug fixing?
I find that bug fixing and optimizing are much less significant when you do a better job designing. Hence why I spend so much time on designing.
psycopathicteen wrote:
I'm surprised everybody else takes longer optimizing than bug fixing?
by bug fixes I meant post release bug fixes
psycopathicteen wrote:
I'm surprised everybody else takes longer optimizing than bug fixing?
Are you asking if you're surprised?
When I first learned programming, I hardly designed anything, or made it easy to understand. I kept all the state in my mind, and enjoyed spending time fixing things. Over the years, I've come to greatly dislike code that has lots of cryptic stuff that is error-prone. I don't know how I worked on the things back then like that. Maybe I just had more ability, but what a waste of it on the messes of code I wrote. I've come to see bugs as signs of design problems, not merely mistakes while coding. Design isn't merely about meeting the requirements, it's about making something that can be reasonably implemented and understood by humans. </rant>
I haven't worked on my game since 3 months I guess (will re-start as soon as my exams are over....) but back when I worked on it, at first you spend more time programming, but then spend a lot of time improving your code (not only optimizing, but also add features it lacked etc...)
Bregalad wrote:
but back when I worked on it, at first you spend more time programming, but then spend a lot of time improving your code (not only optimizing, but also add features it lacked etc...)
This is exactly what I want to avoid. When you keep working in new features, your code turns into a mess of hacks and addons.
Diving into the code right away can be fun, but it ends up being a mess.
Designing everything, planning out where things and going to interact and how, figuring out what features you're going to implement and how, and leaving wiggle room for possible/probable future expansion -- that is the hard part. That's what takes the time.
Get all of that out of the way and the actual coding flies by.
and +1 to what blargg said. I've been trying to get better about writing coherent code, but it can be hard sometimes.
Yeah, well, I still have plenty of improvement to do in writing comprehensible code. The single, biggest step I took to starting on a path to improving was to kick the optimization habit. I don't know about others, but I early-on picked up the habit of optimizing things. It became a kind of compulsion, very fun, but destructive to code quality and overall ability to improve the code without introducing many bugs. The mention of optimizing here is what prompted me to post, because that's the single biggest seductive trap there is in programming. As an aside, I think that doing NES and other assembly coding is good, because there optimization must be done more, and there are far more opportunities for lots of nifty and useful tricks. It gets that out of my system, so when I'm doing C++, I can focus on functionality rather than speed.
It depends on whether you're asking about the code I write at work or the code I write for personal projects.
At work I mainly use Java, and sometimes C/C++. There's practically no code optimization taking place there, because almost none of the stuff we write is speed-critical, and maintainability and stability are much more important than execution speed in our line of work.
Design and maintenance usually outweigh the implementation time if you look at the entire life-span of a piece of software.
When I work on my own projects it's almost the complete opposite. I barely ever design anything before writing it, and I can spend hours trying to optimize away a few bytes or cycles in a piece of code. I still fix bugs, but I tend to do very little testing.
Lately I've been doing a lot of bug trapping, since my dynamic animation engine reqiures a lot of rearranging code.
I think I spend an almost even amount of time designing and programming. I have developed a habit of always writing in a fair amount of detail in a text file about what I am developing. I do this at work and for personal projects. I did this out of necessity as I was very lazy for very many years, and couldn't keep my thoughts straight. When I was a kid I just let ideas/code fly out and this resulted almost always in hitting brick walls with my projects. Now I take it a bit slower. The irony is I think I get more done now, and better.
I can't say I've spent that much time at optimization; but I'm sure this will change in the future as the requirements of my projects become more demanding.
I think I spend a certain amount of time refactoring code as well. Sometimes I'll reach a point where I realize something is organized pretty badly with regards to maintainability/ease of use and I will spend a good amount of time brainstorming about a better way to organize it, and then take the time to re-organize it that way. Usually this pays off!