Now I'm beginning to understand.

Nah, none of my old code attempts remain. They're long gone. Wouldn't have even hit save if they didn't work on the day I made them.

I will try a look-though in the Classified section and post something there if I can phrase it well enough.

In the Beginner's board I initially saw several kinds of "I can't code or make art, but what I have are ideas and dreams" types of topics, which were met with encouragement and suggestions for first steps, so I thought it was the best place to put a beginner's first step of my own. But I begin to see that any kind of collaborative effort is just sort of categorically different than the purpose of that forum or maybe almost any forum. And I guess that is really true because theoretically, if I met a couple of people there and then we set off on PM, Skype etc. it would immediately be outside of a Beginner's board conversation. It would immediately have no more public use. That's true.

Okay, then. I get that. In my defense, though, I wasn't initially trying to assemble people right there on that board. I was asking if it were ever done, and if so, how?

I'll look through the Classified section now (it seemed at first as though that would be nothing but hard core professional stuff, so I didn't think my subject would qualify for something like that). And if nothing comes of it, that's fine. Maybe I could try Reddit or something. shudder.

Anyways, thanks for putting up with me and my perpetual lack of direction. I may not have the foundations of game devving under my belt or even a clear path towards getting them, but so help me I'll get one fun game done someday. Peace.

If you're a non-programmer, looking to get into programming, the best place to start is free tutorials online. Don't expect to make anything resembling a game right away - be happy when you manage to print out "Hello, World!" and even happier when you can actually process text input or read from a file. This is why so many people buy guitars only to never learn to play because they aren't playing like a rockstar right away, they want to do big things, and feel unsatisfied with minor accomplishments.

If you think C++ is your speed, I definitely recommend the tutorials at http://www.cprogramming.com/tutorial/c++-tutorial.html
They were invaluable to me when I was starting out, and once you're somewhat comfortable in C++ the C programming tutorials can prove immensely useful as well.
C# is probably more popular for indie dev now, though I'm just basing this on the number of Unity and monogame teams looking for help out there, but I rarely use C# so I can't direct you there.

Once you're comfortable with whatever language you choose, it might not hurt to find a position as a "grunt" programmer on a project with some more seasoned programmers, somebody they can offload more mundane tasks onto. You'll learn a lot by reading through and working closely with their code, and if you're lucky they'll actually explain where you messed up when you introduce a bug or write horrendously sloppy code.

But at least initially, you're going to have to get started on your own, just like most artists do.


...also, it's possible you're just not a programmer and it might be a dead end for you. If you feel like you're more of a designer, then maybe you should stick to the design side of things. There's plenty you can get into there beyond big picture stuff. UI design, concept art, and level design are within the scope of a game designer, and there's not a lot of people in the indie world that are truly good at those. Pixel art, vector art, music composition, sound effects, and modelling are all jobs that need to be done too. I honestly don't know why so many people want to be programmers, it's hard to get decent at and next to impossible to get excellent at and a simple typo or a little bit of forgetfulness can cause a show-stopping error that can take hours to resolve.

Look for an open source project that you like, and try to contribute.

It's not a group that you create, and the project is already decided, but it's a group with a common goal.

If you're at all interested in using Unity, you might want to have a look at their series of tutorials on scripting.

They're extremely thorough, and some of them were live applied sessions of doing relatively simple gameplay patterns step-by-step in the code and in the editor.

Though I had a lot of previous experience, and I felt it was a bit too slow for my personal taste, there's undeniable value for someone just starting.

What I'll say however is you can't get enough theory. I'm a self-made programmer for the most part, and the parts I'm mostly struggling with are generally design patterns, that is, ways to do things that people have thought about and tested long before me. Oftentimes, I settle for a much too complex and unclean solution, or I devise my own which looks alien to other developers, and we could have a much simpler discussion if we agreed to just make a singleton or something. Theory on design patterns, read on it!

Then, I suggest you just join an actual project. You'll fail at a few things, and probably won't get proper feedback, but you'll at least understand the path not to take the next time, and it is better than no feedback at all. It does pays off, even if it is perhaps inferior to what you are suggesting.

Keep 3 things in mind:

1) before trying to team up, make sure you bring some skills to the table. It is totally cool to still be a newbie, given you find equally skilled people that are okay with that and only want to produce games for education for now.

Just don't come with almost zero skills and expect your teammembers to be real pros...

2) Make sure everyone is on the same page. Sounds like you are pretty realistic about your goals... many people looking to team up are not. They expect to be able to produce the next GTA V like openworld hit, or at least a Minecraft level runaway Indie success with no real expierience yet whatsoever.

And when they are able to talk themselves into a team, you can imagine who they blame when things don't end up as gloriously as they should in their mind.

Best case they leave as soon as they had to throw the first few hissy fits because the rest of the team is more realistic than them... worst case they infest others in the team with unrealistic goals, and its the realistic minority that has to leave.

3) Work on your people and management skills if you intend to lead the team. Being a teamlead can be a fulltime job. Be ready and willing to spend a good part of your time coordinating your team and supporting team members. That can become tedious, but if you are not willing to do that, you need to find someone else to fill the role. And normally, its the most active and driven person that is most cut out for this role. That certain person certainly would have assembled his own team if he wanted to team up.

So unless you find someone else that wants to assemble a team and is ready to take the lead, keep this in mind. Just telling the least motivated person to take the lead because, you know, he seems to be unwilling to learn anything else, is normally not going to end well.

You might want to read up on agile methodologies.

These are not programming languages but are ways of working on a programming project and as well as being widely recognised as working quite well, they more often than not encourage working in a team.

For example "extreme programming" has nothing to do with base jumping whilst writing C++ and a lot to do with working in pairs.

You won't regret learning these things as they will help you work on a programming project in a team with others who already work by these concepts.

Keep away from scrum though as it is more suited to working closely in an office environment as it encourages regular face to face meetings.

Good luck!

Erh... while I am all for agile methods, I thought that XP had died a horrible death in the many "work trainwrecks" it caused many moons ago.

Whoever thought sitting two persons at one screen, and getting anything than REDUCED efficiency for double the wage should be shot, and then shot again.

On a more serious note, are there ANY newer scientific studies that prove that extreme programming does work as advertised, even if certainly not as well as the original authors believed?

My point it: you are basically preventing one guy from working flat out (he lacks his own machine), while disturbing the other guy in his work (while having another pair of eyes can be benefical at times, programming normally is nothing where constant distractions by another person is good).

Give both a machine, let them work alone, and instead do regular code reviews and meetings. You still get part of the "additional pair of eyes" advantage, while giving each programmer at least half a day of undisturbed work time instead of both constantly a) fighting for the steering wheel, b) fighting over coding standarts and implementation details, c) interrupting each other while implementing complex parts because of some minor ommissions ("you forgot to put a comment there", "your indentations suck").

Lets not get into how much strain it is on a work relationship when you constantly have someone breath down your neck, while you are trying to get work done. Even the most social programmer will get fed up of having to sit next to the other guy for many hours every day.

Office warfare certainly will get dead serious quickly

On the other hand, I heard many advocating using PARTS of Scrum even as a lone wolf of small team. While many practices certainly are meant to facilate managing the team with the least amount of overhead (15 minute standup meetings instead of 1 hour scheduled meetings where people get comfortable and chit chat for 1.5 hours - yes PLEASE!), some can be used for self management.

Kanbaan Boards and all....