It has been said that there is not enough interest from the community for new devs. I would like to contribute code. Here's why I haven't been able to yet.
What should I do? Let's take a look at the todo list.
https://github.com/assaultcube/AC/blob/m...E_TODO.txt
Well, okay. I might as well go check out the rest of the code. Let's see if there's something I can work on.
Generally speaking, a program has a main.cpp (which we do!) and it is the file without a header file. Generally speaking, everything else should have a header file.
Do I need to look up function declarations so that I know how to use a function I need? Cool, let me go look at the header file so I don't have to scroll through definitions. Why is this object oriented? I don't care HOW you do something. If you CAN do something I need to do, I'm going to use EXISTING code. If you want to improve that function, cool. The handle is the same. That is to say, if I was using one prototype (?) before, I expect to be able to use it later (ie. void function(type var, typ2 var2) should not change).
Next, file name and function names should be descriptive. If it is not entirely obvious what something does, there should be comments. So let's say I decide to help out with some sound issue. How would I approach it? I would go to sound.h and check out what's there. I would look at things that sound like it would help. Then I would go search for the definitions in sound.cpp. But let's take a look a sound.cpp (I can paste the ENTIRETY of it here. If that doesn't scream "THERE's A PROBLEM WITH YOUR STRUCTURE", I don't know what does):
https://github.com/assaultcube/AC/blob/m.../sound.cpp
Maybe that was just a bad example. Fuck it. I'm going to check out main.cpp. Let's see how it starts what the important files are.... But wait, it only has #include "cube.h". at the top: https://github.com/assaultcube/AC/blob/m...c/main.cpp
Fine, let's dig through cube.h and figure out what's going on. It looks like the graveyard for "hm where should i put this? I have no idea. Let's put it in cube.h!" stuff...
https://github.com/assaultcube/AC/blob/m...src/cube.h
So how do you figure out where to start? Documentation? Comments? No go.
Why does AC not have any new devs? Because the only people who know what's going on are the people that already work on it.
So I propose a new structure. Let's call it a to-do list.
Yeah. That's what I propose. AC 1.3, AC 2 can be put on hold. Let's work on improving the code base and THEN adding features.
https://medium.com/on-coding/why-your-co...057c115a2b
What should I do? Let's take a look at the todo list.
https://github.com/assaultcube/AC/blob/m...E_TODO.txt
Quote:- monsters & jumppadsThere are monsters in AC?
- hide monsters until triggered?
- trigger when monsters die?
Quote:recent stuff:Let's say I'm new and I hop in and I want to look at stuff. What file? Why is something not reproducable on here?
- try and debug depth read? GL_DEPTH_SCALE/GL_DEPTH_BIAS
- detect if sw driver? glXIsDirect(dpy, ctx) (can't get context from SDL) / glGetString(GL_VENDOR/RENDERER) (many HW drivers use mesa as base)
- make server port configurable?
- not reproducable: When you pop out of edit mode where a bridge is right under a ceiling you get stuck.
Well, okay. I might as well go check out the rest of the code. Let's see if there's something I can work on.
Generally speaking, a program has a main.cpp (which we do!) and it is the file without a header file. Generally speaking, everything else should have a header file.
Do I need to look up function declarations so that I know how to use a function I need? Cool, let me go look at the header file so I don't have to scroll through definitions. Why is this object oriented? I don't care HOW you do something. If you CAN do something I need to do, I'm going to use EXISTING code. If you want to improve that function, cool. The handle is the same. That is to say, if I was using one prototype (?) before, I expect to be able to use it later (ie. void function(type var, typ2 var2) should not change).
Next, file name and function names should be descriptive. If it is not entirely obvious what something does, there should be comments. So let's say I decide to help out with some sound issue. How would I approach it? I would go to sound.h and check out what's there. I would look at things that sound like it would help. Then I would go search for the definitions in sound.cpp. But let's take a look a sound.cpp (I can paste the ENTIRETY of it here. If that doesn't scream "THERE's A PROBLEM WITH YOUR STRUCTURE", I don't know what does):
https://github.com/assaultcube/AC/blob/m.../sound.cpp
Maybe that was just a bad example. Fuck it. I'm going to check out main.cpp. Let's see how it starts what the important files are.... But wait, it only has #include "cube.h". at the top: https://github.com/assaultcube/AC/blob/m...c/main.cpp
Fine, let's dig through cube.h and figure out what's going on. It looks like the graveyard for "hm where should i put this? I have no idea. Let's put it in cube.h!" stuff...
https://github.com/assaultcube/AC/blob/m...src/cube.h
So how do you figure out where to start? Documentation? Comments? No go.
Why does AC not have any new devs? Because the only people who know what's going on are the people that already work on it.
So I propose a new structure. Let's call it a to-do list.
- Comment all of the header files and cpp files giving a short description of what each file is supposed to accomplish
- Create a diagram of dependencies
- Figure out what really needs to be included by what file
- Refactor
Yeah. That's what I propose. AC 1.3, AC 2 can be put on hold. Let's work on improving the code base and THEN adding features.
https://medium.com/on-coding/why-your-co...057c115a2b
