[Mitchell]

This is a thread mainly to learn about other's coding style for their respective game they code for.
If there is already a thread like this, possibly point it out to me?

Anyways i'll start it off, I like to see how far I can code a plugin without actually having to compile it. This mainly includes comments (comments are good! allows people to read my code and know what i'm accomplishing!), and me planning out what each function should do before hand. Then i write up some mock up code in each function, just to start off with a base. Depending on the plugin, if it is a small plugin, then i usually get around 75% of it done. Once i get that far I try and compile it. Of course there will be errors, mainly errors of me not defining variables that I use. I sometimes misspell a variable here and there. When I work on a bigger plugin, I usually break it down to pieces, getting the base code done first, and then adding in all the cool stuff later. Then I test it out on the server to make sure it works the way i want it to.
I find my method works for me because I go at least 4 days without being a PC that can handle any Source game (hardly even minecraft). I usually finish up a lot of the code while im on my laptop (at work) then spend a day debugging it at the end of the week.

TL;DR:

1. Code 75%
2. Compile for Errors
3. Test on server
4. Finish coding/Changes
5. Compile/Test on server
6. done.

I would like to hear about other's methods, since it's always nice to hear something new to try out. Also it might help some of the new people.

[Kia]

How I usually work

1. Defining main features of Plugin.
2. Code until I think they are done.
3. Test on Server.
4. (Optional) Fix Bugs.
5. Add Optional Features (Models, Sounds etc.)
6. Eat Cake.
7. Done.

[.Dare Devil.]

My things:
1. Planning what im going to do and how im going to do it.
2. creating all the stock and functions what needed
3. if plugin/program size is 20-40kb then code everything whats on my mind
4. Fixing compile errors if needed.
5. testing them on my computer ( not using any server or something like that )
6. Fixing bugs if needed
7. Always, adding some more stuff what i didnt plan for in the beggining
8. placing cake on kia's table
9. Program&plugin done.

[Powerlord]

If you really want a list of things...

1. Figure out if a plugin is feasible to do or not.
2. If this requires any sort of gamedata, figure out what the Linux gamedata is.
   1. If this is for Source games, such as TF2, cheat by looking for relevant code in the Source SDK 2013 because Valve forgot to remove the #ifdef TF and #ifdef TF_CLIENT parts, so you can see what the server is actually doing. This also helped me figure out what the TextMsg UserMessage actually does (print Valve-translations to clients).
3. If this is intended to be a permanent project, create a new source-code repo for it.
4. Copy my plugin template / plugin .inc template (if plugin will have natives) to said repo or make a copy in my snippets repo, then update it for the current project.
5. Sort out any required dependencies and make sure they're loaded.
6. Create any translation files that might be necessary. That way I can't forget to do it later.
7. Add the code to register any commands or events. That way, they error out if I forget to write them before coding them.
8. Write the actual code.
9. If the plugin is large enough, split it into multiple files along natural encapsulation boundaries (See: SourceMod's NativeVotes* plugin, which splits native handling, data handling, and game-specific code (which themselves are the wrappers and actual game-specific logic)).
   1. Make sure includes are all in the proper order.
10. Compile the code.
11. If the code doesn't compile, go fix bugs.
12. If the code does compile and my test server is empty, lock it and put the plugin up there for testing.
13. Add bots for testing if appropriate.
14. If it requires gamedata signatures, ask someone what the Windows signature is since I'm still not sure how to do Windows sigscanning.

*NativeVotes may be a bad example as it originally started out as C++ code with separate classes for L4D, L4D2, and TF2... with a shared base for L4D and L4D2.

[.Dare Devil.]

Originally Posted by Powerlord If you really want a list of things... Figure out if a plugin is feasible to do or not. If this requires any sort of gamedata, figure out what the Linux gamedata is. If this is for Source games, such as TF2, cheat by looking for relevant code in the Source SDK 2013 because Valve forgot to remove the #ifdef TF and #ifdef TF_CLIENT parts, so you can see what the server is actually doing. This also helped me figure out what the TextMsg UserMessage actually does (print Valve-translations to clients). If this is intended to be a permanent project, create a new source-code repo for it. Copy my plugin template / plugin .inc template (if plugin will have natives) to said repo or make a copy in my snippets repo, then update it for the current project. Sort out any required dependencies and make sure they're loaded. Create any translation files that might be necessary. That way I can't forget to do it later. Add the code to register any commands or events. That way, they error out if I forget to write them before coding them. Write the actual code. If the plugin is large enough, split it into multiple files along natural encapsulation boundaries (See: SourceMod's NativeVotes* plugin, which splits native handling, data handling, and game-specific code (which themselves are the wrappers and actual game-specific logic)). Make sure includes are all in the proper order. Compile the code. If the code doesn't compile, go fix bugs. If the code does compile and my test server is empty, lock it and put the plugin up there for testing. Add bots for testing if appropriate. If it requires gamedata signatures, ask someone what the Windows signature is since I'm still not sure how to do Windows sigscanning. *NativeVotes may be a bad example as it originally started out as C++ code with separate classes for L4D, L4D2, and TF2... with a shared base for L4D and L4D2.

And not giving cake to give it to @Kie...
Alright then ...

[Powerlord]

Originally Posted by .Dare Devil. And not giving cake to give it to @Kie... Alright then ...

I'm supposed to watch my sugar, so... cake limit!

[Impact123]

Some of you don't seem to use a local server to test, why not?

[Kia]

Originally Posted by Impact123 Some of you don't seem to use a local server to test, why not?

Because we / I have a VPS / rented Gameserver to test there?
Most often I test with other players, and my own connection is not good.

[Powerlord]

Originally Posted by Impact123 Some of you don't seem to use a local server to test, why not?

Because I lease my own game server. You can see it in my signature.

[Mitchell]

Originally Posted by Impact123 Some of you don't seem to use a local server to test, why not?

I do, cause i'm poor. not really. But when i want to test experimental features i most of the time do it on a srcds. Or if my test server a friend lends me then i just do it there. Mainly use a local server if its something i don't need another human to help me test.