Writing my own video game

[almosthere]

Hi,


As you can tell, I'm new to the OpenPandora community. As a matter of fact, I just ordered mine last week. I was a lurker until today and I especially liked reading about upcoming games for the Pandora, among other platforms. One such game that comes to mind is Rainy Day and after seeings its preview this morning, I was really amazed of its quality considering Rainy Day was made by two people during their spare time. This inspired me to make something of my own, but I'm noob when it comes to programming and game art. I'm not a complete stranger to coding, I did some C, C++, Java and Assembly when I was in college, but just basics really. I know someone who's good with GIMP, so I got the graphics department covered. What I'm really looking for is any useful documentation when it comes to game design and coding. I could also use a refresher for C or whichever language you suggest I use for my first application. In the last three years, I've only used my laptop to check my emails. Also, please bear in mind that I never programmed for Linux or ARM architecture. Thank you for any suggestions.

 

[darfgarf]

start learning sdl, opengl(es for the pandora) if you want 3d


other than that a good head for logic would go a long way

 

[Pickle]

I could also use a refresher for C or whichever language you suggest I use for my first application. In the last three years, I've only used my laptop to check my emails. Also, please bear in mind that I never programmed for Linux or ARM architecture. Thank you for any suggestions.

Start with SDL or Fenix (basic). LazyFoo tutorials are a good primer on basic SDL and game design.


I personally use SDL, which is a basic library that allows the developer to design an application that can work with all the major OS's using the same API (set of functions).


I suggest you start learning using a PC development setup.


I would recommend using a linux distro as a development platform as you will begin to learn things that will make it easier to cross-compile later. (If you dont want to switch your real OS, then get virtual box and use a virtual machine for dev)


But you could stay with windows and SDL just to learn and refresh until your ready for linux.


Dont worry about ARM, in no real cases should this ever be a problem for the level of programming you will be doing.


Start simple and slowly add and learn new things.

 

[foxblock]

Okay, because everybody else will suggest good SDL/OGL and programming language related tutorials anyway, here is something different from me:


I found these links highly interesting in terms of game design (something I am very interested in, you will see many indy game influences in my games, Braid probably as the most prominent one):


Some videos of talks by Jonathan Blow (creator of Braid), these are each over an hour long, but well worth the time in my eyes:

https://www.youtube.com/embed/gwsi7TEQxKc?feature=oembed

If you are interested in Mario-style platformer development this is a good starting point:


Programming M.C. Kids « games.greggman.com


Some general tips by Edmund McMillen (of Super Meat Boy, Time Fcuk, Gish, and many more)


Indie Game Development: 16 Do's and Don'ts, Feature Story from GamePro


Spriting guide:


Derek Yu


Some good ideas for games (if you lack your own, or just want to get some inspiration):


Three Hundred :: Three Hundred Mechanics


Some wise words by Chris Hecker (I have more by him, but I somehow misplaced the links, just keep an eye out for his name):


Please Finish Your Game - Chris Hecker's Website


I have many, many more, but this should suffice for a start


I am also always interested in (controversial) general dev talk (about game development, game mechanics and that sort of stuff), so feel free to message me or whatever.


Good luck, looking forward to your first game

 

[Timstertoo]

Lots of great links..


I have many, many more, but this should suffice for a start


I am also always interested in (controversial) general dev talk (about game development, game mechanics and that sort of stuff), so feel free to message me or whatever.


Good luck, looking forward to your first game

Wow! Thanks for that ^^ Sent you whole post to Evernote for future consumption. Some great stuff there.

 

[Jourdy288]

Lots of great links..


I have many, many more, but this should suffice for a start


I am also always interested in (controversial) general dev talk (about game development, game mechanics and that sort of stuff), so feel free to message me or whatever.


Good luck, looking forward to your first game

Wow! Thanks for that ^^ Sent you whole post to Evernote for future consumption. Some great stuff there.

AWESOME POST! Thanks dude!


Also, if you're looking for somebody to put together a story, I'm your man http://thestuffiread.blogspot.com


As for graphics, well, I'm not (nearly!) the best, but give me something specific to go on and I'll try

 

[foxblock]

Glad I am of help.


Oh and I totally forgot, check this out... all of it!


http://www.escapistmagazine.com/videos/view/extra-credits

 

[bzar]

When you're done with the basics of SDL (assuming you'll start with it), also consider checking the first few chapters (2D stuff for now) of "Linear algebra for game developers".


You'll probably have more specific questions once you start mucking around. Don't hesitate to ask

 

[WizardStan]

Whenever I talk to someone who wants to write a video game, I always tell them "start small".


Write tic-tac-toe: the basics of starting a game, the main loop, user input and "AI" input. It may seem small and simple, but screwing up your flow on a small game because you didn't know any better is going to feel a lot better than screwing up your flow on what you had hoped would be a grand masterpiece that you now have to trash and start over.


Progress to a lot of other simple games: rock-paper-scissors; yahtzee; maybe start working towards more complex but still straightforward games like connect 4 or checkers.


Do not under any circumstances try to do any sort of major work of art. I have seen enough people struggle, become frustrated, and give up on their idea to highly recommend against it. Take it slow, make all your mistakes on little projects. You'll feel a lot less guilty about throwing them away if they don't work. This also has the benefit of helping you identify things that you do a lot and building libraries around them: things like menu systems; sound and graphics wrappers; input handlers; bunch of other stuff I'm not thinking of right now.

 

[bzar]

^ +1. The Edmund McMillen article linked above said it well: "Think small. Then think smaller.". You want to have all the basics nailed down before trying anything that's not trivial in your head. Keep the amount of new things per project small and take your time to get comfortable with them. It'll pay off sooner than you might think. If you mess up a big project you lose a lot of work, so you're inclined to try to hack it together until you get frustrated and drop the whole thing. If you have a small project you have a lot less to lose by switching to something else. It's also easier for other people to guide you when there's less code to examine.


EDIT: Aaaand now I see WizardStan already said some of this stuff. I really should read peoples' posts to the end before replying

 

[foxblock]

Yep, starting too big probably is the number one mistake (I also made).


Don't underestimate how much work a "simple" Mario-clone is (it probably is one of the most complicated type of 2D games).


If you have an unique idea you want to try out under any circumstances it's also important to prototype a lot. Meaning to finish the core gameplay before anything else using only placeholder art and if necessary placeholder sounds, mabye even use a different language or engine to write your prototype than you would use for your final game if you can work faster with that.


The reason for that is, that one usually can't see whether a new concept is fun in practice so you got to test it and you got to test it on the most basic level, because if the core gameplay isn't fun, the final game with all extras added certainly won't be either (and by using only placeholder work you don't loose too much in case the project fails).


So get a prototype done quickly and test whether it's fun, send it around to people and gather feedback.


But of course better start with some existing and simple concept like Tik-Tak-Toe or Pong anyway.

 

[almosthere]

Thank you very much for your answers, I'm definitely going to save this thread as it contains a lot of pertinent information for beginners like me. The next question might sound weird to some of you, but I feel obligated to ask. As you already know, my main interest is game development, but this could, of course, change over time. I can't recall where I read this, but apparently C++ is considered a standard in the gaming industry. Which brings me to my question, are there any reasons for me to learn C before I delve into C++? Thank you for your patience.


Have a nice day.

 

[Kaepora Gaebora]

are there any reasons for me to learn C before I delve into C++?

I don't have any good reasons. I learned C++ before learning C, but a good base of programming and logic is very useful before learning syntax.

 

[Blue Protoman]

I would just start with C++. Afterwards, SDL would be a good library to learn. LazyFoo has some good tutorials for SDL, and two books I recommend for C++ are C++ Without Fear: A Beginner's Guide That Makes You Feel Smart 2nd Edition (has coverage on C++0x, which has new features, but is not completely reworked, so don't panic) and C++ Primer Plus 5th Edition. I would also get some logic down; Project Euler is a good site for general programming challenges.

 

[Tam Toucan]

Go with C++. You can use it as "a better C" e.g. classes to restrict access to your data and functions, constructors/destructors to simplify memory management. You can do this without having to go for a full blown OO solution (yes you can do it in C as well, but it's easier to be "sloppy" in C). Don't worry about all the power stuff of C++, but if you need any dynamic containers use the STL, even if it's just vector and list.