Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 May 2009
Offline Last Active Yesterday, 11:35 AM

Posts I've Made

In Topic: How big is your project?

08 October 2016 - 12:00 AM

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.

In Topic: How big is your project?

07 October 2016 - 01:30 PM

With assets you easily get to 200 files even with a small project.

In Topic: How big is your project?

02 October 2016 - 02:36 PM


Most of my files have at least a few 100 lines of code. A fair portion of them have 1000+. What's your's like? I have to scroll miles and miles... hehe I hate scrolling ;-)


Typical "well engineered" software will end up with many files (corresponding to how many pieces of actual functionality you need) and files will be short.


What is the correlation between well engineered software and having many files?

I agree with everything you said, but this one I don't know about, especially with pretty much any editor with some navigation features. Possibly I just have no idea what "big" project means.

In Topic: How big is your project?

02 October 2016 - 01:55 PM

30-40 files at most, though I'm just a hobbyist. I hate tabbing between files too, and I rarely have to scroll because I don't have to work on many parts of the code at once. Usually the function I'm implementing and maybe the point where I'm using it. If I have to jump here and there in the source code, that means the system is a spaghetti.

In Topic: [Poll] Managing my limited free time while job seeking

02 October 2016 - 10:03 AM

Finish the project. Plus build up some portfolio site (some blogspot like thing would suffice), if you have things to put in it. You could even make some small and simple games with reasonable level of polish (I guess you want to be a game developer). I got a few offers because of my medicore portfolio.

Enter a contest, or Ludum Dare.