DOES LINE COUNT MATTER?
Summary (TL;DR): It depends – a well structured programming project will actually have less lines and assets, and thinking that more lines means a more complex game or IT product of any kind is a misconception. Code architecture matters!
Recommended music to listen to while reading: America – You Can Do Magic
Some background
We’re mainly using GameMaker for our work, which is an object oriented game development engine environment. It is excellent for making 2D games, and has everything prepared and designed for – you guessed it – OOP (Object Oriented Programming).
Why does this matter for explaining the answer to the question? Well, OOP can exacerbate the difference a programmer makes by using OOP to his advantage and actually simplify the project he’s working on – making a well-thought project and its mechanics almost a necessity when thinking about speeding up production.
I’ll try and give an explanation based on what I’ve seen after having worked on over 100 game projects in the past. Many of those were small ones, but still – a pattern emerges when your hands and eyes have seen so many projects. I’ll be focusing on code quantity and code line number as the most often used metric in that regard. I won’t be investigating how to write better code or similar topics. That can be a matter for another discussion.
Why less code lines is a good thing
Let’s try and think a bit about why less code lines might be helpful while programming an IT product. I’ll be mostly thinking about videogames, GameMaker and OOP, but most of the things mentioned apply to any kind of software product.
- Readability: the less lines to read – the easier it is to navigate code. Find stuff. Get into it. Less noise to work with, a smaller pond to swim in.
- Debugging: with less time spent going through hundreds or thousands of lines of code comes a faster recognition of the problem in it. Multiply it by the times a code you’re working on doesn’t work (probably every 5 minutes or less) and suddenly you find out where all that time goes and why experienced software devs cost more.
- Teamwork makes the dream work: What if I gave you a 1000 page long book and told you to read it and then find mistakes in it, translate it, or do something else with it (whatever fancies your imagination)? What if I asked you to do the same with a 20-page book? It’s similar in coding. Often times a project requires more than 1 programmers to work on it, and being able to work on the same thing is much easier if people don’t have to spend energy on reading a lot of code. Quality > quantity.
- Code execution speed: this is a bit tricky one, as it might not always be the case and depends on the compiler (or interpreter). Still – any kind of CPU will need more time to read a bigger quantity of code lines than what it would take for it to go through less amount of code lines. There’s compilation to take in account, as machine code quantity generated might be less in some cases than what you’d get from bigger code bases, but generally speaking, much more often (and especially the bigger the projects are), having less code lines will speed up the execution. This means less energy wasted by the end-user device (hello battery life) and also faster execution as well.
- Compile speed: this is similar to the point above really and even more often true – less code means less lines the compiler needs to go through, translate, optimize etc. When you’re making a game or another application, you will often compile and test things – and again here comes the time decrease with having fewer lines of code.
- Practice:Â implementing good practices even when working on small projects will benefit a programmer in the long run, as he grows habits. This is similar to great athletes – practice makes one perfect. As you regularly implement practices which prioritize having a smaller code base, it will be more and more natural to you. So much in fact, that you’ll stop to think about them, and they’ll simply become a natural way of working. What’s great about that is that all of the above points will have a compounding effect, making you a much faster programmer who produces quality code, and is a lot easier to work with, as a team member.
There's no way having more code lines could be good
Well… As you grow older, the more you’re aware there is no pure black & white. Everything has a pro and a con. Additionally, you appreciate more the things that are simpler – pure black and pure white 🙂
Although you could intentionally write more code lines to prevent somebody else from actually working on the same project, as that somebody would have to waste lots of time on getting into it, there is one (f)actual reason why having more code lines is sometimes beneficial.
Speed of development! Thinking about how to structure the code, mechanics and everything else in the project just takes time. Time to sit down and think (+ sometimes sketch on paper). This is time you could be spending writing code. So here comes the caveat – writing code is never just ‘writing code’. It is not the same as talking or writing a letter or a book (or writing a blog post). Speaking is easiest – you talk about what comes to mind and the process is fast. Writing a letter/email/post is slower – you need to think about what you wanted to say, how to bring emotion into words (as there are no facial expressions and body language) and so on. And programming is even more thought-intensive! You need to think and think about how to first solve the problem, but then also how to write down and structure the solution, so you don’t break other things. Plus, readability, optimization, and trying to avoid people (including you) to waste a lot of time reading it later when the code needs to change.Â
See what I did here? I’m trying to come up with a good reason to have more lines of code, and I’ve navigated around it. Well, it is actually simple: if mechanics you’re developing are light and the project is small – don’t overthink it! Just making it work sometimes beats having crystal-clear code which is short and nicely written. So if it will take you a few hours to complete the whole game (which is very unlikely and something I’ll talk about in another post probably) – don’t spend time making it small in terms of code lines. Just make it work. The bigger the project – the more you’ll HAVE to worry about keeping the code line count in check. Please don’t even think about working on a project which will take several months or more without spending time on thinking how to organize the code base. Just don’t! Well, unless you’re not a programmer (e.g. Undertale).
This is all just talk - real world is different!
This is where my trap is sprung! Remember when I’ve said at the beginning that I’m basing my notes on previous experience? Let’s take a look at a few examples of game projects of varying size and complexity. The tool I’m using for metrics was developed by Sebastian Nigro and had been made available on his itch.io site in the past, although I don’t see it being available anymore – at least not at the time of writing this post (February 2025). Anyhow, this nice little tool counts the amount of code lines and asset quantity in a given GameMaker project.
Project “A”
I’ll give no name to this project as it was never released publicly. This is a game prototype I’ve finished for a Japanese client in about 1 month – not a big project, but not very small either. The prototype was given to me as 20% complete, and boy was it a mess 🙂
These are the numbers in the project as it was handed to me (mind you, these are only for a 20% complete prototype):
- around 9000 code lines
- around 800 scripts
- 40ish objects
After I’ve completed the prototype (remaining 80% content & functionality implemented), the game code stats were:
- ~2500 code lines
- 16 scripts
- 31 objects
When starting to work on the project I had a choice to make – will I spend a couple of months going through the code to understand it first, will I continue working in the existing code hoping for the best and try to focus on what is important for implementing new features, or will I just rewrite the whole code from scratch? I’ve chosen the last one :D. A fun side note – completing the 20% of the original features took the original programmer about a year to make, while it took me one month to complete it fully (the whole 100%). Additionally, this is the project I’ve done somewhere at the beginning of my programming career, meaning the difference would be even greater today, with all the knowledge gained since.
This is an extreme case, where a previous programmer was not a professional (he is an artist), which is one of the main reasons why the difference is so huge. All in all – the end project took me >40x less time to make and had 20x less code lines, 100x less scripts and >5x less objects as well (if we take into account a bit less than linear increase in code lines and project assets for completing it in the original way by the original developer). Roughly, we can see that the difference between a professional developer and a beginner could be as much as 50x in terms of time, quality, and consequently – in terms of cost as well.
If you’re a manager, think about this the next time you hire someone cheaper, as even if the less experienced person (freelancer/employee) or company is on paper 80% less costly, the end result could be 5000% more cost in time and money at the end (if it ever gets completed). Also, think about how much return you get by investing in improving your employees’ expertise.
Air Hares
A fun game with nice looking visuals that got released very close to the time of writing this post. It is available on Steam, so if you’d like – check it out by clicking on the image 🙂
This is a project where we at GameGlis were given an incomplete game (less than 50% complete) and had to bring it to the finish line. The game had previously been in development for around 3 years and we continued working on it for the next 3 years. 1.5-2 years here were dead time – nothing was done during this time due to project finances, and our actual effective engagement came up to maybe a single year, all things considered.
The code line & asset number stats at the beginning, before we took over programming of the project are shown in the left image below, while the image on the right shows the state after the game had all the functionalities and was ready to release (100% complete compared to ~50% complete).
As can be seen from the comparisons of the project stats – the game with 50% less mechanics and complexity had around 30% more code lines! If the project had been completed using the approach from before, the resulting project would cost a lot more, take a lot more time, and also have almost double the complexity, all of it unnecessary. The biggest savings here were in all the unnecessary scripts used in the project previously, making the code bloated and extremely hard to work with -> the project had 15 times more scripts achieving less! That is all due to not utilizing all the capabilities of OOP.
As a final note for the Air Hares project, keep in mind that not everything was cleaned up or optimized as it could have been if the game was redone from scratch. The code base in that case would be, in estimate around 50% smaller than it ended up being, and would result in an even less time & money wasted. This means a better decision could have been made, if everything was aligned and the scope evaluation was done more precisely. The development of mechanics were decided at a pace of few at a time, without having a clear vision of the end product. This meant cleaning as you go, and trying to keep everything from exploding 🙂 We managed to that, woohoo!
What to do, then?
Well as you see from the examples, the real world does increase the importance of why keeping the line count in check and having the project organized makes sense. On the other hand, sometimes it makes sense to just continue making new features, without much regard to how well it is written – without worrying about the code architecture.
If you’re making a small prototype for your app, or a small vertical slice of a game, you might not want to be too organized, as the time (and therefore money) invested into organizing the code and reducing the line count will not pay back. It might be that the game demo will never become a full game.
If, on the other hand, the project will have multiple people working on it, it will be developed for a period of time longer than 1 month, or if you just want to continue growing good coding practices and turn them into habits – do keep your eye on how organized the code is and overall software architecture in your game (or any kind of software project). You (or your client) will benefit from having done so. Or hire professionals -.-
Â
You’ve been warned! 🙂
Subscribe
0 Comments
Oldest
