Yeah... I don't include assets. Unless their scripts, because that's kinda of like programming. If I were to include all my current source, original game source and all the assets I think I would be sitting around 140-150 files. It seams a lot for a simple Asteroids type game. I could condense but I don't want large files I have to scroll through. Besides, it won't just always be for an asteroids game and some of the features I want require more. I write everything from scratch too. All home brew here! My current setup mainly consists of OpenGL related files. There is hardly anything that sets up sound, states and input, etc.. OpenGL is the heavyweight in my project. Oh... I also use glew currently. I wonder how big some of Blizzard's games are? Like... Diablo 1 or 2.

Maybe I should be looking into WHAT I need for a stable platform to work with. I see in the Quake and Doom source code the initialize OpenGL almost exactly the way I do. I think most of the bloat comes from special classes that handle things like VAO, VBO, IBOs and shaders. Then there is all the sound, image and model loaders. I wonder if it would be best to implement my own custom formats and a set of tools that works with them. Like image and sound conversion. Models are easy, since Blender lets you pretty much run a muck there. I might use Blender to generate my sprite sheets to. It has a UV layout, why not right? Its a lot better then looking at that ugly code that generates them.

Anyways, I think I'm being to hard on my self or judging my self on how large my project is. Like I'm doing something wrong...

     719 text files.
     388 unique files.
     408 files ignored.

github.com/AlDanial/cloc v 1.70  T=2.00 s (176.5 files/s, 40714.0 lines/s)
-----------------------------------------------------------------------------------
Language                         files          blank        comment           code
-----------------------------------------------------------------------------------
C++                                160          14436           6583          32110
C/C++ Header                       188           7051           7337          13611
HLSL                                 3             65            109            113
Windows Resource File                1              3              8              1
Markdown                             1              0              0              1
-----------------------------------------------------------------------------------
SUM:                               353          21555          14037          45836
-----------------------------------------------------------------------------------

45836 / 353 = 130 lines per file ...doesnt sound right, are ppl counting headers?

c++ alone is 32110/160 = 200

Yeah... I don't include assets. Unless their scripts, because that's kinda of like programming. If I were to include all my current source, original game source and all the assets I think I would be sitting around 140-150 files. It seams a lot for a simple Asteroids type game. I could condense but I don't want large files I have to scroll through. Besides, it won't just always be for an asteroids game and some of the features I want require more. I write everything from scratch too. All home brew here! My current setup mainly consists of OpenGL related files. There is hardly anything that sets up sound, states and input, etc.. OpenGL is the heavyweight in my project. Oh... I also use glew currently. I wonder how big some of Blizzard's games are? Like... Diablo 1 or 2.

Maybe I should be looking into WHAT I need for a stable platform to work with. I see in the Quake and Doom source code the initialize OpenGL almost exactly the way I do. I think most of the bloat comes from special classes that handle things like VAO, VBO, IBOs and shaders. Then there is all the sound, image and model loaders. I wonder if it would be best to implement my own custom formats and a set of tools that works with them. Like image and sound conversion. Models are easy, since Blender lets you pretty much run a muck there. I might use Blender to generate my sprite sheets to. It has a UV layout, why not right? Its a lot better then looking at that ugly code that generates them.

Anyways, I think I'm being to hard on my self or judging my self on how large my project is. Like I'm doing something wrong...

Why would you implement everything from scratch? I mean image loaders, sound and everything? It's hard and low level enough to make a stable program alone (handling lalt-tabbing, resolution change, alt-tabbing while resolution change, just something "fun" from the top of my head).

In my opinion:

For me, making a know-it-all engine for an Asteriods game doesn't seem to be a good direction.

According to my hobbyist and professional experience (Labview tools and pneumatic test bench programming), one can't design a system up front, if it's the first time one is facing a specific task. It takes 2-3 iterations (remaking the architecture from zero but obviously using everything one can, mainly subroutines from the previous iterations) to make a somewhat maintainable and expandable system. It's pretty much impossible to see up front what problems, feature requirements, etc you will face. Give the product to the "customer", and he will ask for 1-2-3 features that totally make sense, you never came upon, and your current system won't be able to handle it without ugly hacks. Any yes, the customer will find bugs that will make your product horribly fail (not crashing, just maybe corrupting/silent-editing the data the customer is working with) because (s)he will use your program in ways you never tested.

I think it applies on an order (or orders) of magnitude more on game engines. That's why I don't think developing a generic engine by developing something on the level of Asteroids is a good idea. For this reason, I have never got into engine programming, I just make games, and reuse everything I can from previous games.

Just some stats:

*minesweeper clone (3 game types, saving-loading mechanism, windowed GUI made from scratch): 4500 effective LoC in C (not counting comments, empty lines and lines with only { or }), 12 source files.

*a tank simulator demo thing (physics programmed from scratch, openGL (cascade shadow mapping for example), custom menu, camera modes, etc): 7300 effective LoC, 36 source files

*A gamedev 72-hour contest winning game (levels, loading saving, basic menu, simple animations): 2000 effective LoC, 10 source files

*Tankwars clone for Dos (save/load, a pretty capable AI, menus, weapon system, animations, collapsing ground, etc etc, almost everything from scratch. Even hardware interrupts handlers, text functions like printf, circle drawing, etc. Many inline assembly code. I was crazy, this was my first big project). 3400 (!) LoC including tools.

You can find them in my portfolio linked in my signature.

Yeah, maybe you're right. I'm doing a lot for such a simple game. But I intend to reuse it in other games. To each, their own.

I just refactored my entire game. It works a lot nicer(smoother) now its down to 75 source files. I got rid of a few unused features. I was planning on using, but didn't. If I want them later, I'll put em' back in. Its pretty simple. I separate classes a lot. I think that is why I have so many sources and headers.

My 2D game engine is 66500 lines, but only 43000 lines are actual code.

The core of my DirectX11 3D engine is less than 100 source files because I moved out as much as possible to separate tools. If something is easier to do outside of the engine than to read about how to do using the engine, the user of the engine will implement it outside anyway for flexibility and the feature is just dead weight causing more bugs. By keeping it simple, reading the code over and over for hundreds of hours with checklists, doing millions of test cases with random generators, using static analysis tools and writing mathematical proofs of correctness that would make most companies go bankrupt from the time spent, it takes one year between each minor bug found in the engine by fading away exponentially when no new features are added.

Hi!
I love inspecting metrics (even though they are somewhat "useless" :lol: ), so I thought I join (used source monitor the gather them, not counting empty lines).

I have a common code-base in C# sitting on top of XNA/MonoGame tailored to 2D games with the following metrics:
Files: 199
Lines: 47 235
Statements: 14 559
%Comments: 1,1
%Documentation: 40,7
Classes: 324
Methods/Class: 9,95

It is accompanied by a bunch of unit tests separated into another project with with the following metrics:
Files: 178
Lines: 51 206
Statements: 27 772
%Comments: 0,5
%Documentation: 5,4
Classes: 359
Methods/Class: 16,05

The huge number of lines and statements in the unit test project relative to the runtime is due to my approach of writing unit tests, where one unit test only checks one singular case/requirement/execution-path, so they usually contain only one assert, thus there is a huge number of 1 and 2 line-long functions...
This also results in a "low" percentage of documentation, since there is no actual reason to document the individual test cases themselves (the name of the test function already does the job, e.g.: XYZCallShouldResultInNull, ABCCaseThrowsException...).

There is a small "samples" project too, which is used for trying out the higher level services of the code and testing the integrated modules/systems as a whole using automated functional tests (essentially a collection of minuscule template games, trying to exercise as much of the library as it can):
Files: 29
Lines: 4 776
Statements: 2 095
%Comments: 7,1
%Documentation: 16,1
Classes: 38
Methods/Class: 7,00

I have a bunch of tiny tools too (e.g.: profiling assistance, content/build tools, functional testing framework...), but all of them is less than a 1000 lines of code and even combined they are smaller than the "samples" application.

I shipped two small games using this "framework":

Memorynth, a small-scale arcade-y memory game:
Files: 34
Lines: 3 666
Statements: 2 371
%Comments: 0,9
%Documentation: 1,0
Classes: 36
Methods/Class: 10,31

Operation KREEP, a couch co-op retro shooter game:
Files: 114
Lines: 14 650
Statements: 8 061
%Comments: 1,6
%Documentation: 10,7
Classes: 155
Methods/Class: 7,24

+ I have one currently in-development called Unified Theory, a strategy game with a focus on management and puzzles (somewhat around 33% done code wise):
Files: 42
Lines: 5 407
Statements: 2 244
%Comments: 2,1
%Documentation: 28,7
Classes: 49
Methods/Class: 6,80

In my game projects I focus much more on higher level documentation (GDD, feature requirements, development tasks) and higher level testing (automated functional tests) and spend much much less time with documenting and unit testing code (only focusing on core, complex or wildly used parts).

My two cents for the topic:
This data/information is really fun and interesting to look at :) , but how "large" a project is such a relative term. It literally means nothing, at least when comparing them to your work. Compare your project to wildly used OSS projects, e.g.: in game development you can check unreal engine 4 as an example, and bammm: you face MILLIONS! of code lines and ten thousands of files (I worked at a company having 32000+ classes in the c++ engine code as an example). Does this mean anything related to your project :huh: ? I think even comparing hobby projects will not result in much "useful" info. Languages, base frameworks, work ethics, number of people working on the project for the number of months/years, all different and makes a HUUUUUGE difference in the outcome.

Apples and oranges...

Instead the focus have to be whether you are productive with your code-base and does it work well (align) with your short and long term plans.
If not: re-factor, re-structure, re-write or choose a good middle-ware for a large part of the job :wink: !

Br.

272 Files, 11 Folders

only 22.5 MB