I'm willing to tutor anybody willing to change, i.e. to develop, Smokin' Guns.
Regarding coding, here's a mail I once wrote to someone: "You know that Smokin' Guns is based on Quake3 and therefore a very complex piece of software.
If you want to develop SG, you need
- some kind of a starting point (what and where to change),
- basic programming skills (good Java skills will do fine),
Developing SG means to change SG for the overall better. You first have to get an idea on what you want to change. Obviously some changes are harder to implement than others. How much work a change costs, depends on which parts of Smokin' Guns are affected.
As SG is based on Q3, it shares the basic architecture of Q3, most importantly the separation of the game into different "components". Mainly, there is
- the client (= the executable, a player runs to play SG)
- the server (= the executable, an admin runs to provide a SG server)
- the "game" virtual machine (= the logic of Smokin' Guns on the server-side)
- the "cgame" virtual machine (= the logic of Smokin' Guns on the client-side)
- the content (= maps, textures, sounds, graphics)
This figure depicts Q3's/SG's architecture, as I wrote:content (= maps)
server <-> game VM
client <-> cgame VM
content (= maps, textures, sounds, graphics)
The game VM and the cgame VM are most easily altered. They are very structured and abstract, using a predefined set of functions called "traps" provided by server and client. Also, game and - to a lesser extend - cgame are most easily updated: server admins can update the game VM without having to shutdown SG. Server updates are also possible, but they require a restart obviously. The client is the hardest part to update: it took several years to publish SG1.1 as an update, so the client should remain unchanged.
Assume, you want to change the game rules of Smokin' Guns, e.g. you want to change the amount of money a player receives. This is a change that affects the game VM. Basically, the game contains all server-side game rules such as how much money something costs, how fast you can run, how high you can jump, how much damage a hit makes.
My proposition for you is the following:
1. First think about something you want to change. Start with small ideas.
2. Consult me, before you start working on an idea. I can tell you how much work a change is and probably give you even hints at which files or functions you need to look at. I will also tell you, whether your changes would be suited for Baller Bude.
3. If your idea is interesting for BB, I will guarantee to test your changes and incorporate them into BB. That way, you can enjoy your own work.
In my opinion, 1 and 2 do not cost much time. So get creative and let's have some discussions.
Part 3 is where the major work lies. Of course, I will be happy and grateful for any contribution making SG more interesting. However, you shouldn't feel pressurized to implement something. It's optional.
For developing, use a editor that supports syntax highlighting as well as source-code hyperlinking. It is really helpful, if you can click on a type and you are forwarded to its definition. This really helps understanding SG much faster. You also need a program to search in all files to locate functions and strings. I use Eclipse, since it's free, but any powerful IDE will do.
Finally, I would like you to give you some general information about the architecture of Quake3. Probably you will understand this article only after several months of studying SG, but I found it enlightening:http://fabiensanglard.net/quake3/index.php
The part on the VM may be first part, which gets clear:http://fabiensanglard.net/quake3/qvm.php