On Process:I'd agree with everyone so far about the development process. It is very easy to underestimate the investment of time required for even seemingly trivial games. And as necessary as planning is, it's also very easy to get stuck in the planning phase and never move on to implementation. Start small (and be willing to scale down even further if necessary), and focus on getting a running, playable product over planning out every minute detail.
To quote the Agile Manifesto, working software is the primary measure of progress. Present your work, get feedback, and iterate. Scale up as you gain more experience.
Also of the subject of process, I would like to add: if you are collaborating with others on a project, go in with the expectation that people will disappear, and be pleasantly surprised if they actually come through. Fan game development tends to mean a lot of work and relatively little (and/or very delayed) gratification, and projects tend to rank low for people as far as priorities go. When life gets busy, expect the fan project to be one of the first things culled from the to-do list. Thankfully, my experience with collaborators has been very good, but I've watched this happen on other projects. The only way you are guaranteed to get something finished is if you do it all yourself (or are willing to pay people).
I actually saw a thread on r/gamedev just the other day that may offer more insight into this topic.I'd also emphasize this point:
Expect your first project or two to go down like this, at least. Actually, expect it to go down like this forever (though hopefully to a lesser extent). Also, if you are the perfectionist sort, expect to be tested. You're an artist, so you probably understand how it goes. I would suggest you avoid redoing old work just because you no longer like it; at the very least, try to finish all the incomplete stuff before swinging back around and polishing up the parts that are rough but serviceable.
On Programming:But you asked about programming, so let me try to lay out my thoughts on that. (My background: I code a decent amount in my free time, I've finished
two dinky fan games from scratch (one solo, one as part of a team), and I have a lot of opinions (to be taken with salt). I have also not worked on a 3D game ever; my personal experience is all 2D.)
I guess to start with: you asked about programming, but if the goal is to create a fan game, know that coding may not be necessary. Writing code is just one possible means to that end. You can get quite far into a project using something like
GameMaker without having to write any actual code, and save yourself a lot of time. The main drawback of such tools is that they generally don't scale well; they are going to be less flexible and less performant than actual compiled code, so there is a practical limit on what can be achieved. But realistically, that's a limit most fan games will never need to worry about.
Consider some of the excellent commercial games that have been made with GameMaker. And if you have absolutely zero programming experience but would still like to learn to code, this can also be an enjoyable way to learn basic programming concepts. You may be implementing your program logic using drag-and-drop tools instead of words, but the knowledge is transferable.
Other than GameMaker, if you have a specific genre in mind, there may be more narrowly-focused tools you can use. For example, if you're making a JRPG,
RPG Maker may make for an easier lift (most of the products there are paid,
but there appears to be one free version). If you're looking to create something like a visual novel, you might consider
Novelty. If you want something 3D, you might consider
Blender, as
Rockman Striker suggests. Decide generally on what you want to do, research your options, and don't be shy about trying stuff out. A lot of high-quality tools are available for free.
But if you decide you want to go big and actually learn a “real” programming language, I'd disagree strongly with
Chiz (or at least, with his wording) here:
It's true that all of those languages could in theory do what you require, but this might be taken to imply that they are therefore all equally viable options. Some of those are going to require significantly greater effort to achieve equivalent results. You want something modern, with a robust user community and ecosystem of tools. Please do not actually write your first game in LOLCODE or, heaven forbid, C. I might suggest a couple of possible starting languages:
-
Python, along with a decent game-making library. I think
PyGame is the most popular one, though some quick Googling turns up very positive reviews for
Kivy. I haven't used Python extensively, but it's generally easy to use, and common wisdom is that it makes a good learning language. It can also target all the major platforms.
Pitch is a more seasoned Python user and may be able to offer more guidance here, if he's around.
-
C# with
MonoGame, if you're feeling ambitious. This isn't the simplest thing out there. However, it's also far from the most complex, is very powerful, has good tooling (I am convinced Visual Studio can make any programmer better), and can target every major platform (and some less major ones). These are not tools that are going to hold you back as you get more advanced. In particular, I think this may be the way to go if your ambition is to eventually make a more graphically-intensive 3D game; C# is both very capable on its own, and is usable as a scripting language in
Unity (
which is a big deal in the industry and has been/is being used for a couple of projects around here, the most prominent of which is
Tuttle's Legendary Travels), so learning it gives you a leg up if you decide to go in that direction.
There are countless online tutorials available for these tools. Once you've put together a couple of small programs for yourself and have a grasp of the basics, you might then consider looking into a textbook. Those are good for deepening your knowledge of the language beyond the basics and will cover some of the underlying theory that is likely to be glossed over in most online quick-start guides. Naturally, you could also just start with a textbook, which is perfectly reasonable. But the reason I suggest playing around with a language first is:
1. You might just decide you hate the whole thing once you try it. In that case, you don't need to bother with a textbook.
2. It's more fun to be able to create a program that does things first and then learn all the dry details later.
3. I find it can be difficult to read about theory without first having some experience. Theory should inform practice, but it can all seem very abstract unless you've encountered the problems that the theory is trying to address. Your mileage may vary, of course.
As for other tools, whatever language you decide on, find a good
IDE. Most people will start off writing code in a basic text editor since there can be a learning curve to working in an IDE. There's nothing wrong with that, but at least be aware that IDEs exist and that they can make you significantly more productive if you're proficient with them. As your projects grow in size, also consider familiarizing yourself with
git, the standard
version control tool these days. It works at the file system level (and so is language-neutral), and will let you do things like "branch" your project, creating multiple parallel versions of it. You can track changes to your branches at a granular level, and revert changes if desired. This allows you to experiment with major code modifications in a low-risk manner and makes it easier to collaborate with other programmers. This is another tool that can have
a bit of a learning curve, and isn't hugely useful until you hit a certain project size or begin collaborative coding, but is worth being aware of.
Hope you find this helpful.
