Now, I have no experience whatsoever with game development. But someday I would like a job in the industry. Problem is, I don't know where to start...
I could make a 2d game, but is there even SDKs for them? Or do you just gotta code them yourself?
I've got some ideas for one, think Metal Slug sidescroller, with an overworld screen. Visit seedy bars around the area to get new missions, or hire some mercenaries to help you with your 2d conquests. I think it would be cool to have a boasting system (Think Fable.) where you could get extra money for beating a level with your fists, haha. Cash nets you new weapons and protective gear. Maybe you could get a mech upgrades for your body. (Leg Upgrades: Jump Higher, duh. Arm Upgrades: Dual wield ridiculously heavy guns. You get the idea.)
Hm, I seemed to have gone into my own dream world there, kinda ambitious for a 1st game. :P
So things I should get/learn to make a game? Thanks in advance guys.
Posts
You can also just use a simple game making tool like GameMaker or Multimedia Fusion. Although you can make a game from start to finish without having to learn much, you are very limited and it's not something that's going to help you get into the games industry.
Aside from languages, start small. I'm talking Pong, or something even simpler like a maze game. Most people don't realize how complicated programming is, especially in a complex language like C++ (in which case you'll be programming clocks and calenders first).
Was there even a Visual C?
But yeah, you probably want to start with C++
[edit] I may be confusing C# with D. I haven't used either of those. Who fucking came up with these names?
#include <stdio.h>
void main(void)
{
printf("hello world!");
}
http://www.gamedev.net
and http://nehe.gamedev.net
Might also look into doing some Mod development.
Once you've gotten the basic principles of programming down, then you can move up the food chain to bigger languages.
Personally, I've learned bits and pieces of many different languages, slowly gathering knowledge. I've finally settled on Flash Actionscript, and I currently make games with it, and make money from them. The Flash game scene can easily, easily be a very lucrative platform to develop games for.
Which, funnily enough, contradicts the ANSI standard. main() should always return an int. Some compilers let you pretend it's a void, but behind the scenes it still really returns an int.
I don't know why. C++ is complicated but it's also widely used and one of the more powerful languages. Why learn one just to discard it and learn the next?
I'm building a basic two-player game where the goal is to shoot lasers at each other in C++
It (along with the allegro library) has performed well in this task so far, so I can vouch for it
Wii: 5024 6786 2934 2806 | Steam/XBL: Arcibi | FFXI: Arcibi / Bahamut
You're not learning one for the syntax, you're learning one for the programming principles. Nearly all languages follow the same principles. I think it's best to start out with an easy language. But, that's just me.
Well, there's a general drift towards higher-level languages, especially in game programming. RAM and processing power become cheaper and cheaper, and compilers / interpreters become smarter and smarter, it becomes worth it to have programmer time saved by working with higher-level languages.
Serves me right for using a shitty C++ compiler. Goddam Borland is crap.
The best advice is to start with whatever you can get for free.
After this step you can see what you like and what you don't. Java is great for being free, but still really complicated. I can only give my personal opinion, and that is to start with Python.
Python is free and the ability to use it without compiling for every change means you can try things really fast and save a lot of time learning how this specific syntax works out (all languages are different in this regard). It's not a huge leap from this to other languages beacause the ideas used by all the major languages are the same, it's only in how you write it that's different. Just breaking your teeth on how programs fit together is enough to start with.
The only problem with Python is the online tutorials are a bit lacking (in that its sometimes hard to find one that will help), though plenty of examples exist with open code like at Pygames.
Hope this helps
It's not really the compiler's fault - Visual Studio lets you do it too. It's just an incorrect practice that has somehow spread its way into textbooks and teachers' minds.
It's like slang.
For programming languages.
I just think it's kind of a waste, because you're still going to spend a lot of time learning Python and you can learn programming principles in C++. I dunno, I think jumping into the deep end is worth it, but if C++ or any other high-level language is too daunting try something easier.
Actually, I think this is pretty funny/cool. This guy is making a Dungeon Master clone using VB.NET and Managed Direct X. Looks pretty snazzy, as a matter of fact:
Entombed
I'd post the image, but they're rather big.
I recommend Java or C# for starters, although I don't think C# is particularly suitable for making games outside of a simple turn-based board-game type thing. Once you improve a bit, you might want to look into XNA Game Studio Express. I've never touched it myself, but have heard good things.
I have been to busy/lazy to actually do any of it, but I keep it bookmarked for when I will.
As for beginners languages: Flash games are pretty dang popular and some of them are awesome, and for a bigger "real" language Java is probably the least onerous to start with, plus it works everywhere. C/C++ are more powerful but oh ho ho do segfaults make you want to die.
Meaning, specifically, would I be able to make a stand-alone program that wouldn't require the other person to have a special program to play the game? An .exe for windows, source or binaries for *nix, etc. I'm a fan of text-based games, and so far Inform 7 is pretty much the awesomest thing ever, but it still has the problem of "oh hey you better have an interpreter if you want to play my .z5 lol!"
I guess that's not really Inform's fault. I love inform, it's so easy.
Require no art talent, but teach you the (very) basics of game development. Basic collision detection, user input, drawing sprites, refreshing screen, etc.
Theres some great tutorials out there and XNA handles all the nitty gritty crap that makes C++ a chore sometimes.
XNA is also designed for game creation in mind so things are pretty much setup from the get go.
If your looking to start programming, well thats a different issue but C# is pretty easy as far as learning basic windows programming. (My Bias is so far removed that this last comment is probably not worth much)
When you learn to write programs for a computer (or anything where you are using a computer language to give precise instructions to a computer) you actually have to learn three different subjects:
1) You must learn the "execution environment," so you understand the computer and what it is capable of.
For example, nearly everybody knows that a computer has files and directories, and you can move files around and copy them and delete them, etc. Have you thought about what is required to read from files or write to them? Many beginning programmers have to learn about making a "file handle" and "open for reading" / "open for writing" and various ways to read and write data. The problem gets worse if you're trying to learn how to make a 3D graphics card do cool things, or poll a game controller, or talk to Xbox Live.
There are new concepts to learn, and you have to just about be able to act things out with little index card puppets. "So I make an instance of this GamerServicesComponent class, and I use that to make an instance of this StorageDevice class, and I call this method of StorageDevice which slides open the "pick storage device" blade for the user." This has nothing to do with writing lines of code -- you just need to understand the different parts of the system and the API and what pieces are responsible for what. Many people get frustrated with this and think that "programming is too hard," when instead they should be thinking "this API is retarded, but I can figure it out anyway."
Since you can't really write ANY programs without a basic understanding of how a system works, most newbie C and C++ programmers start by learning to write console programs. Their textbook must teach them a little bit of very simple system stuff (print a line to the screen! Get keyboard input! Open a file! Close a file!) and then around that context you learn to write simple programs. These students are frequently surprised when they jump from console to event-based GUI programming, because they aren't used to having to work really hard to learn how the system expects you to talk to it.
2) You must learn the language. What statements can you use, and what grammar is required for these statements? What language features are available "for free" and what do I need to implement myself?
This is what people traditionally associate with "learning to program." Does my language support something like a 'for loop'? If so, how do I write one? OK, does my language support something like a 'while loop'? If so, how do I write one?
3) You must (eventually) learn some computer science: data structures, common algorithms, common methods for organizing your program so it makes sense to people who read it, etc.
Don't freak out, you don't need a CS degree to write games! People who have gone before you have thought up some really cool ways of solving some common problems, and you'll turn out to be a stronger programmer if you take time to learn these things.
For example, how do you handle pathfinding, so your little command and conquer soldier knows how to walk around the hills and trees and reach the destination the user clicked, without walking in circles or getting stuck? You could try to figure this out on your own, and you'll find it's a LOT of fun to try to dream up a method, code it, and try it out and see how well it works. You'll be more effective, though, if you already know your game landscape is an "undirected graph" and you can use an "undirected graph search algorithm" to do pathfinding, and algorithms called A* and Dijkstra's Algorithm come to mind as being useful in different circumstances.
So in your travels, learning to write games, you will find tips and sample code that seems to expect you already know what some of this stuff means. Try to fake it for now, and if you find you really need to understand something, come ask for help.
Final note: writing games is a technical art, in that you can be creative but you must master some difficult technology to realize your design in a working game. If you wanted to learn to build beautiful metal sculptures, you know you need to learn how to cut and shape and weld metal. You learn these not by starting on an art project for public display, you learn by taking some scrap metal and practicing the bare basics of welding, cutting, grinding, etc.
Similarly, build your two skills in parallel. On the creative side, see if your game could possibly exist as a weird kind of board game, even as a kind of dumb unmarketable board game that requires multiple human referees for even a two person game. Writing rules, creating dry-erase game pieces on laminated index cards, all of this builds skill in designing games.
On the technical side, practice writing derivitave done-to-death things just for practice. May I suggest:
Guess a number from one to ten? 5
Too high! Guess a number from one to ten? 2
Too low! Guess a number from one to ten? 4
Correct!
Press any key to continue.
XBL Michael Spencer || Wii 6007 6812 1605 7315 || PSN MichaelSpencerJr || Steam Michael_Spencer || Ham NOØK
QRZ || My last known GPS coordinates: FindU or APRS.fi (Car antenna feed line busted -- no ham radio for me X__X )
(Note that the following is debatable and slightly controversial. Many people would suggest it's not healthy for a budding game designer to start shackling their ideas to this model of human learning. I feel it's useful to have a set of conceptual metrics you can use to judge a game design. I know these metrics will never teach you how to turn a formulaic boring game into a great game, but hopefully they will alert you if you are trying to implement a dumb game design and will suggest to you why the design is dumb.)
Is "guess a number from one to ten" really a game? Does it count as a game?
Does "guess a number" give the player opportunities to try and fail things? YES! The player can try to guess a number, and can succeed (be correct) or fail (be wrong.)
Does "guess a number" give the player useful feedback about failure, to enable the player to learn how to succeed by watching what didn't work? YES! The player is told that their guess was too high or too low, so they can adjust their next guess to be more likely to succeed. They player doesn't even have to sit through an annoying LOAD screen before they can try again!
Does "guess a number" have a game mechanic the player must seek mastery of? YES! The player must learn to develop a mental picture of a number line, with an abstract sense of regions of the number line which cannot contain the secret number. This game mechanic is mastered when the player learns to estimate the region of the number line which could still contain the secret number and learns to make guesses as near as possible to the middle of that region.
Does "guess a number" have layered game mechanics, such that mastery of one mechanic reveals the beginnings of a new game mechanic? NO! Once you master the art of guessing halfway between the minimum and maximum possible answer, there's nothing left to learn. The player then experiences behavioral extinction, since the "I am learning!" reward goes away, and they soon stop playing.
Is "guess a number" fun? NOT UNLESS YOU ARE IN PRESCHOOL!
Now take some more-complex-yet-still-simple games and try to think about them in this context. What do you think makes Tetris so addictive? What layered game mechanics are present in Super Mario Brothers? (e.g. turtle shells. Learning to stomp --> learning to stomp and kick --> learning to stomp and kick and avoid the rebound)
XBL Michael Spencer || Wii 6007 6812 1605 7315 || PSN MichaelSpencerJr || Steam Michael_Spencer || Ham NOØK
QRZ || My last known GPS coordinates: FindU or APRS.fi (Car antenna feed line busted -- no ham radio for me X__X )
This is some pretty good shit, man. I think I'll have to save some of this too.
I borrow most of my game design wisdom from a site that's been linked from the PA main page at least once. (Then again my home server sitting in my basement has been linked from the PA main page at least once.) http://www.lostgarden.com/ Unfortunately that blog doesn't update very often, with maybe one post a month, but I strongly recommend you go back and read ALL of the archives.
XBL Michael Spencer || Wii 6007 6812 1605 7315 || PSN MichaelSpencerJr || Steam Michael_Spencer || Ham NOØK
QRZ || My last known GPS coordinates: FindU or APRS.fi (Car antenna feed line busted -- no ham radio for me X__X )