First, to clarify, when I say “noob” I don’t mean that I’m new or uninformed when it comes to the elements that go into making a game. I’ve been programming/scripting/coding (whatever you want to call it) since the age of 11 and I currently work as a 3D Modeler for DAZ3D >_>. Even compose soundtrack music when I have the free time… Still, I am new to game design and development, at least when it comes to actually doing those things. Grew up gaming, loved it, thought video games would be an awesome thing to get into since it’s a combination of several things that I love, but I’ve always been too scared to try it.
Anyway, getting to the point…
Finally decided to take the leap and just go for it. And now that I’m here, I’m curious if anyone has any advice on the matter. Like, is there anything you’d recommend I do starting out? What’s the best way to stay organized through the process, how do you keep yourself motivated, etc.
I realize that most of those things are subjective, of course; everyone has a different way of doing things. But I just thought it might be helpful to me to get a general idea of how things are done since I’ve never actually worked on something as large scale as a video game.
Also, sorry if this kind of post isn’t welcome here. Just thought I’d try.
Start small. Making classic clones like Pong and space invaders is a good start.
Finish a project. No matter how small.
Don’t be afraid to experiment.
Make backups.
Starting with a clone sounds like a good idea. Kind of like, if you make a clone and it works the way it should, you know you’ve done well.
Backups are part of my everyday life already. I have an HDD that I use for backups and I also backup to 3 different cloud services (a bit paranoid :P).
Chances are you won’t win the lottery on the first ticket. There is no real roads to success and no short cuts. The only way you can win is to keep buying more lottery tickets.
Use version control. This has a side effect of providing a backup, but don’t get mixed up between the two.
Know that starting projects is not important. Finishing them is.
Don’t get too hung up on originality. You can make an overall unique experience without having to purge your game of any idea inspired by games before it. In fact, I’ll go one further and recommend taking advantage of player expectations.
@Birdin - So basically you’re saying, try, and if I fail, just keep trying?
@angrypenguin - I used version control (Beanstalk) when I was writing apps. Haven’t used it since because I sort of do my own by backing up different versions of my file each time I quit working for the day. Basically, Day 1: Save as Project, upload to cloud. Day 2: Save as Project_2, upload to cloud. Day 3: Save as Project_3, upload to cloud. Etc.
The importance of finishing is definitely something I’m going to have to keep in mind. When I’m working, I won’t ever start a new project while I have another going. But since games are something I’m doing as a hobby (for now), I may have trouble with it if I don’t check myself; I have a bad habit of getting an idea, and wanting to jump on it immediately.
Recently, I don’t think I’ve seen a single game, book, movie, or just anything else in that area that hasn’t in some way been inspired by something else. That’s not particularly bad though. At least, I don’t think so, anyway. Liking something and taking inspiration from it isn’t the same as stealing, I’d more call it learning. As for taking advantage of expectations, I do that all the time with my current work. It’s kind of a must if I want to “win”. Spending hours on something only to find that no one is interested in buying definitely isn’t winning.
Thanks for the replies, guys. This is really starting to sound a lot like what I already do. Not as scared anymore.
Don’t do that to yourself. Using a good VCS is less work and gives you plenty of additional benefits. Pushing once per day isn’t really a good habit to be in, pushing once per task is where it’s at, because then you can navigate back and forward between changes rather than days. Also, if you’re leaving meaningful commit logs (which… you should) then you’ve got some pretty solid documentation about the entire life of your project.
Finishing a project doesn’t have to mean releasing a game. You could give yourself a project of “prototype idea X”. Being a project it should have an end point and some form of schedule (at least a target completion date). The intended outcome is then that at your finish date you want to have some kind of playable thing that answers questions about your game concept. That could be the basis for another project (“make a demo of X” or “prototype this variation/other aspect of X”), or you could start something else, but the key is that you’re making explicit decisions about starting things and about when you’re going to call them “finished” and move on. Without those things people tend to flip flop around and not really achieve anything.
@angrypenguin - I like your idea because it’s really structured. Without structure things are pretty much sure to fail at some point. I don’t think I’m going to start off with the intention of releasing any of it. I want to just kind of get the hang of it before I commit to a really serious project.
@Birdin - It’s sounds like as good advice as any. Simple, yet meaningful and effective.
What else is there to add? Except to say, I <3 this community!
@JimiThePanda - Kudos for asking such an open-ended, insightful question! Here’s a path I’ve used. I build a series of prototypes - 2 days each. Then, I pick one and turn it into a product. I always give myself a timeline - from 2 weeks to 16 weeks. Though honestly, anything beyond 12 weeks is too much of an investment - my ego becomes overly invested in the outcome.
Try; Fail; Improve - deliberately practice things ALMOST beyond your ability. Look forward to seeing your first game on January 23, 2015.
Dont except to make a million dollars or any money off your first game. I think if you have the idea it could make some money off it will help you finish it and maybe create a better product.
Using a good VCS is less work and gives you plenty of additional benefits. Pushing once per day isn’t really a good habit to be in, pushing once per task is where it’s at, because then you can navigate back and forward between changes rather than days. Also, if you’re leaving meaningful commit logs (which… you should) then you’ve got some pretty solid documentation about the entire life of your project.