How can I make a game? How can I make an mmorpg?

We get more and more threads like these, so perhaps it would be best to answer in the general case.


First off, let me start with a warning: the MMORPGs you play with thousands of other people are developed by professional programming and graphic design teams and have budgets of hundreds of thousands of dollars (usually millions - especially for advertising). The same goes for those games you buy at your local game store for $50 or whatever. If your dream is to make a game like this, either have a lot of money or become a game programmer and get hired as one of many people working on a game. You cannot make a game like this in your spare time. It may be possible to make a small game and have it expand over the years but this is unlikely.




Now, moving on to making games.

The first thing to do is to learn to program. This is much more than just learning a language: You have to understand design and programming strategies. You have to be able to create algorithms to do what needs to be done. Basically, you need to develop a logical mindset. Oh, and you probably want to learn OOP since these days procedural-style programming works for very few large projects, most of which are legacy.

By the time you can program well, you're probably familiar with quite a few languages, technologies, and frameworks, and you're probably proficient in more than one language. So, pick what you want for a game - language(s), libraries, technologies, frameworks, whatever. Whatever you're most comfortable with using and gives you good results is fine. It isn't recommended to ask questions about which language is better than which, but asking about specifics is, of course, encourages (as long as you've searched first). Popular languages used to create client-based games are C/++, java, etc, though it can be done with others (even assembler, if you so want). Web-based games are somewhat more limited - most people choose PHP, though there are good ones built with JSP and I'm sure someone, somewhere, has used ASP as well. Complementary technologies are things like databases (required for multiplayer games, really). Learning to use those will help you as well.

Okay, now that you have a language, you've mastered its basic aspects, you've created smaller projects not related to gaming, what you want to do is build up your proficiency with tackling smaller projects. For example, if you want to make a client-based game, why not makes tic-tac-toe first? That's a very simple one. Tetris clone? Sure! (Just don't call it *tris - it's a trademark.) Alien invaders? Asteroids? Or maybe a side-scroller (similar to mario)? Or a top-down shooter. Those are simple games. They have limited interaction, and are straightforward to code. They're classics for a reason. Making simple games like these will help you develop your logical mentality, especially in application to games. They will help you to better understand and use OOP as well as multithreading (which is extremely useful and required in almost any large graphical project). Now, if you're making a web-based game, I would recommend making things that allow user interaction (such as a simple forum) to let you deal with user interaction. You'll learn how to use a database better and you'll learn how to "clean" user input (so as to protect yourself against SQL injections and the like). If you don't know what SQL injections are by this point, you must read up on handling user input and website security.

Of course, none of this is necessary if you already have experience with large projects in whatever language you're working in, or even a similar language, but for the beginner these are almost mandatory.

After working on smaller projects and having a better understanding of how everything works, you're ready to move on to your major project. To succeed, the most important thing to keep in mind is that this is for fun.





Now, some advice for those wanting to go the extra step and making their games multiplayer.

For web-based games, making things multiplayer is easier than for client-based ones. Basically, just learn how to safely handle user input and use a database and do what's needed. If you have a host that supports a programming language such as PHP, chances are (99%) that it also gives you databases to use (usually MySQL).

Now, for those making client-based programs, the first thing you need to do is figure out how you're going to make the game multiplayer. Read up on the appropriate technologies and protocols (for example, you might want to go with learning socket programming and having a central server).

Once you understand how everything works, once again, create a small project to use your new-found abilities. One of the easiest things to do is to create a simple instant messenger (chat) program - once you install clients on different computers, and turn on the server, you can talk to other people (or yourself on someone else's computer, whatever). This way, you will practice networking as well as OOP design and, if you're creating a server, multithreading (for servers this is almost always required).

And from there, you can move on to the big things.





Possible questions that may arise:

Q: Do I have to take classes to learn all this?
A: Nope, google can help you.

Q: Are there free technologies or will everything cost me money?
A: It depends on the language, but most languages are free to use, and there are many free libraries and the like.

Q: Are there any free graphical libraries?
A: Yes: look at OpenGL and its offshoots, for example.

Q: Is it really so much work just to make a game?
A: It's a lot harder than you think until you start programming.




If anyone has any questions/comments/suggestions/corrections/etc please feel free to post here.

I get the feeling you kinda rushed through this, just to get it out there. Overall not bad, rather rough, but I would give it a [3.5 / 5]. I would stress more that you do not want to start with an MMORPG, its hell. Also, you left out flash for web-based games; Adventure Quest comes immediately to mind. You also might consider adding a "security" section covering SSL and point out that the designer should have a firm grasp of security and a well-planned design for his/her game.

I like the way you talk about a "logical mindset". If you don't have if I don't think anyone can explain it to you, but I often find myself applying it to all aspects of my life, almost like a vulcan xD (seriously, you will find illogical people bug the crap out of you, they seem to add dots where they don't need to be, and seem to act on emotion rather than facts)
It also makes you a much better chess player, which I find interesting. Anyway, nice work ;-)

I'm not going to cover every single type of game there is. A flash multiplayer game is essentially a client-based game, except you access the client off the web. Same deal with learning networking in the language, same deal with using a database.

Once again, the main form of security comes from sanitizing user input and protecting information. How you do that depends on the language, really.

Gimp, one paragraph into your post and my eyes started glazing over. It's not that your post is wrong or anything. It's a jargon mess that someone new to programming won't understand.Let me pick out words that are jargon: OOP, procedural-style, frameworks, libraries, client-based, assembler, JSP, ASP, databases. A new person is not going to see your point, and will just skip your post. Don't flame me. Ask your (non-techie) neighbor to read that post and see how many seconds before his eyes glaze over as well.

Distill your points:

1. Making a game is nothing like playing a game. Playing a game is having fun. You can enjoy making a game, but it's hard work.
2. You can learn everything you need for free. But you need to learn yourself. No one will teach anything to you for free.
3. Don't try to start programming a game from day one. Focus on picking up a programming language, so you have enough experience and knowledge to understand something like the above jargon filled post.

Hmm, you're right. Let me see what I can do about that.

I've learnt VB6 for a year, done done 1st yr uni java course, and have at least the basics of OOP down.

Now I want to go learn C/C++. Shouldn't be tooo difficult once I learn syntax? So then say I wanted to go make a simple game like so advised in the first post.
I'd assume I'd start with command line programs to learn syntax. Then GUI?
A) How hard is it to then GUI with windows and C? Any traps/pitfalls to fall into here?
B) My main question, when would you recommend I try my first 'game project'? Right after GUI? Anything else I need to know? What sort of knowledge would you think I would need to know to make a graphical tic-tac-toe?

Ivo, this response is so horribly late, sorry.

A) Depends really. Playing with Windows APIs having never done so before is difficult but there are other alternatives... frameworks, libraries, etc. I'm sure OpenGL can help you.
B) Sure, tic-tac-toe is a fine first game. What sort of knowledge? Just knowing how to play with graphics, since everything else is so simple. Or if you want to do something slightly more complex make tetris.

Is there not prgram's out there that make the programming easier. Surely you could get off a "first" project without have to competely do line by line C/C++?

There are programs out there for making games with little or no programming skill, which you can find by googling "Game Maker". However, to truly be able to customize your game, you've really got to program it yourself.

you can start with a good engine though right?

Absolutely. Depending on the language, there are plenty of useful engines out there. You don't have to completely re-invent the wheel. The majority of engines are probably written for C++. But if you are just starting out, I would recommend writing something in JAVA using an IDE like NetBeans, just because it is a lot easier to debug.

or get to grips with the game maker it might just do lots of dirty work for you. and then you just sit back and get 10 million people sending money straight over to you account each month