Jump to content

  • Log In with Google      Sign In   
  • Create Account

Almost NO experience at all. How to start?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 awesomeAMP   Members   -  Reputation: 107

Like
0Likes
Like

Posted 08 June 2012 - 04:09 PM

I've always wanted to learn how to write on different platforms for various purposes, but I'm very lazy; but since summer it's starting I decided to finally put myself together and dedicate myself to actually learn. I have almost no experience or knowledge whatsoever, I think I did the "Hello, World!" code on Java Eclipse and programmed a robotic arm with Arduino, but nothing more.
I would like to know what is a good way to start, like what platform to use, what language to learn, good websites with resources and examples, etc.
I would like to start with a simple word-adventure game or whatever that type of games are called. But you tell me, I am the one who don't know anything of this. =D

Sponsor:

#2 incertia   Crossbones+   -  Reputation: 779

Like
2Likes
Like

Posted 08 June 2012 - 11:53 PM

Serapth wrote a nice little guide for choosing what to do for game development on his site over here. I would also highly recommend buying a book for the language you decide to learn and stick with it for a while. You'll learn to love it and use it as a go to resource when you need some help.

Personally, I learned C++ first and then Java, Python, Visual Basic, etc. I don't really recommend going to C++ first route unless you are very confident in your learning skills. I started C++ 5 years ago in 5th grade and kind of regret not choosing something like Java first. I got into DirectX/OpenGL after becoming quite immersed in the gaming industry during 6th grade. The best resources will always be books/tutorials written by professionals, and games. Just playing games will slowly implant how game mechanics are supposed to work inside your head, and it makes actually writing games a lot easier.

Edited by incertia, 08 June 2012 - 11:53 PM.

what

#3 Bacterius   Crossbones+   -  Reputation: 8880

Like
2Likes
Like

Posted 09 June 2012 - 01:13 AM

In my experience, the best way is by far to jump into it. Just download some IDE for the language you picked (see this as recommended above), look up some tutorials, grab a soda, and get coding!

As for games, don't think about "doing games" just yet. You want to learn to walk before you learn to run, so you need to learn how to write a program before knowing how to write a game. Because that's all a video game is - it's just a computer program designed for the user to have fun. Text adventure games aren't actually the easiest thing to start with. I personally recommend this path (but then again, I followed it so I am probably biased):

- choose a language (this isn't the be-all-end-all choice, you will have to learn more than one later on anyway)
- get comfortable with whatever developing tools are available (e.g. visual studio, codeblocks, eclipse, ...), do not worry about cross-platform compatibility yet. learn to love the debugging tools and the F1 key, they will be your best friends
- learn how to do simple things such as implementing pure logic in text mode, such as minigames like "guess a number between 1 and 100", that kind of stuff
- try and implement some more complicated algorithms, to get better at writing them (you'll need them), my favorite is implementing three types of sorting methods, bubble sort, heap sort, and quicksort but there are other choices
- this is your next milestone: try to design a very simple text adventure game (do not make it too complicated), like a simple "find the artifact" type game which gives you an inventory, different rooms to explore, with hints, etc... and a basic input parser so that you can tell the game "go left", "take item", etc... if this is too hard, make a console-based hangman instead
- the previous step will probably take you a long time, but if you make it, then you should try and move on to graphical interfaces, so try and figure out how to make it work with the language you picked
- at this point, make a tetris/bomberman/other clone to put all your knowledge into a concrete, finished product you can show to people
- this is where you should look into artificial intelligence which is very important: implement a connect-four AI (if this is too hard, do a tic-tac-toe AI instead)

After that you should be sufficiently advanced to be able to decide what you want to do next: perhaps you will want to remake your first text-based game, improving the story and the interface? Or you might want to start from scratch, or just learn another language for a break. I don't know Posted Image

Personally, I learned Pascal when I was 10, and taught myself mostly from the internet (my father got me interested in programming in the first place, but he didn't really help me much beyond that), and I just stuck with that for a few years, because I loved it (learning some other languages along the way, for fun and out of curiosity, like Python, C/C++, some Java and basic ASM). I made a few games, but then I kind of suck when it comes to gameplay so they weren't fun unless they were clones like tetris. Then two years ago, when I was 17, I had to take a programming course in high school, which used XNA and C# (for 3D games). I obviously had a huge headstart, as many concepts carry over from one language to the other, but there were many new concepts I had to learn as well as the C# syntax itself. I liked it, and eventually purchased a real graphics card and got interested in 3D game development - I never really went very far with it, as I eventually came to realize I didn't like it that much, but it had me looking into GPGPU stuff, which better suited my taste.

I obviously wouldn't recommend following the path I chose, especially if you want to go into game development - it is very personal to me and most people on this board would find it a terribly bad approach, but it worked for me. I mostly added it to illustrate an important point: once you get into programming, you start to learn really fast because you love it (as in most disciplines, but especially true in programming because most of what you need is free and readily accessible from the internet). And that the path you take doesn't weigh much in how well or how fast you will learn to make good games. Almost all roads lead to Rome, right? So don't spend weeks trying out different things, just pick one that isn't an utterly bad choice and go with it!

As for "best" language, this is easily one of the most discussed questions here. The concensus is that there is no "best" language to start out with, although some are certainly better than others (because of extra documentation and online presence, overall user-friendliness and simplicity). I like to recommend Python as a starting language as it's really easy to get up and running and start having fun with, and it's also in general easy to accomplish things without the language getting in your way. But it is largely a matter of personal taste.

And Incertia has a good point - playing lots of games will also open your mind on what makes a game fun and engaging (but of course, you will still need to learn how to make games to integrate this knowledge in your own games).

Remember - you can always change your choices later. Programming languages and frameworks come and go, but your knowledge will always stay with you. So don't spend forever agonizing over a decision, just choose. and learn, and if it doesn't work out, go back and try the other Posted Image

Edited by Bacterius, 09 June 2012 - 01:14 AM.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS