The problem is that people start to see the number of lines they write as one of their priorities or tasks. They partially concentrate on ensuring they have written lots of lines each day or week, which impedes on the more important task of building games and tools.
A little under 2300 lines of code. Granted The code is insanely “spaced” so that reading can be browsed faster(3 lines of empty space between methods is very easy to find, one line between “thoughts” is fast, having the ‘{’ on a line is just plain easy to spot).
This is for an unfinished platformer: physics, resource manager, simple rendering, and a few other minor things.
My Java4k submission from last year is about 2750 lines.
I’ve worked on a project which used software rendering. The code to render a single triangle (taking into account that it supported different types of shading and flat colour vs texture) was several thousand lines of code by itself.
My current project is an application server for online games. It’s still at pre-alpha stage. When I calculated its size a couple of months ago (excluding comments and empty lines), it had 4400 SLOC production code and 7300 SLOC test code (90-95% line coverage). I’m changing its architecture to handle concurrency better (message-passing instead of shared mutable state), which means rewriting maybe one fourth or third of it before it will again begin to grow in size (I just deleted its garbage collector and next I will replace major parts of its task scheduler and database).
Lines of code is good for measuring how big an application is. It’s bad for measuring how good the code is or how productive a programmer is, not to even mention how useful the application is to its users. Good code is usually much shorter than bad code. Two projects may be of equal size in lines of code, but one of them might be much easier to extend because its code is factored much better. Two projects may have as much test code and equal code coverage, but one of them might be easier to maintain because its tests are better decoupled from the implementation details, document better why some code was written, run faster, are more reproducible etc.
2 jesek2:
the dragging of the figures looks really natural
and even though you get 13-15 frames, the animation is really smooth
i would appreciate it if you could tell me just the names of the tecchniques you use
(if they are common in game development/3d design. in case you use your own, then thank you for the inspiration)
i am new at game programming (hobbiest) , btw