GP2X You Want Make Games For Gp2x?

[Digital Awakening]

Can anyone get this thread pinned?

Introduction
Since there are some who want to develop games for GP2X but have no clue on how to do it or are looking at some simple solutions I would like to help them get started with SDL. I'm very new to this myself and I just heard about GP2X a few weeks ago. But I got some link recommendations from people on this board and found out that this wasn't as hard as I first thought.

So what is this SDL all about then? SDL stands for Simple DirectMedia Layer. Basically it makes 2D programming in C and C++ quite simple and it's supproted by GP2X. SDL also makes OpenGL easier but since GP2X is a 2D console we should stick to the 2D stuff. If you have any basic knowledge about programming then you shouldn't have much trouble with SDL once you get started. My precious coding experience is mainly Dark Basic Pro and PHP, not very advanced or low level like C/C++. You can check out my website if you want to see what I've done before.

Game development
For those who have never developed a complete game I would like to mention a few things before we start. It is quite easy to make a good game with some basic programming and art skills if you have a good idea and know how to make what skills you have work together. Game developing is mostly about structuring and composing. Structuring because there's a lot of things that needs to work together, you really should plan before you start. Composing because even simple things can look and work amazingly when you combine them, if one thing is great but the rest sucks then the whole game will suck or if you have only a few great things then it's barely a game.

It's quite easy to get a prototype up and running and that's usually the funniest part. But most people can't complete a game because a game is so much more then what you see when you are playing it. Menus, options, savefiles, maps, databases etc. There are many aspects of the game that requires a lot of thinking and planning before you even start coding. If you start with a prototype and try to make a game from it you will usually end up with so called spaghetti code because you make quick solutions to every problem you run into. The code gets hard to follow and development time increases and fixing bugs and adding new features becomes harder and harder. Been there done that and not going back.

So the best thing to do is to start with small games to build experience. And make sure that you focus on 1 game, complete it and have it properly and fully tested before you go on to the next game. With more experience you can make bigger and more advanced games. Halfmade games rarely get you anywhere and it's likely that you keep on developing halfmade games. As a lot of people have commented on in this thread there are mainly 2 different views on this stick with 1 project thing. If you want to be regarded as a games developer I think it's important that you finish what you set out to do, that will also convince others that you are capable of doing so.

Note that I mention GAMES developer, a lot of people can do a lot of cool things but not solid games that are appreciated by gamers. The best of ideas rarly get much attention if the gamers don't like to play your creation. Interest fades quickly with a prototype. It is however important that you can abort a project that is either more then you can handle or if you have completly lost your interest in. If you have enough experience you should make code that can be reused in future projects so that you can cut down on development time. Don't forget that complete games builds a fan base and are good reference for larger team projects, higher educations or getting a job. Employers look for people that can complete projects even if they don't develop software.

It is important that you have not just a spark but a burning fire because game developing is hard work and you need to figure out many things and look for a lot of information on your own if you want to learn and if you want to make your games. It's easy to give up or constantly rely on others but that will never make you a good games developer.

I would like to add another tip for all who want to be game developers: Play a lot of games and figure out what is good and what is bad with every game. If you think that everything is good in every game you play then you will hardly be a good developer. Even the best of games usually have some parts that could have been better, but there are some exeptions that are just perfect in every way.

Also remeber that programming isn't everything. Learn a 2D and a 3D package. 3D is good because prerendered stuff can easily look a lot better then 2D if you aren't a great 2D artist. Even something as simple as an icon for a GUI can look amazing when it gets propperly shaded. You don't need to be an amazing artist to make a game look good as long as you know how to make simple things look solid. It's all about composing again. And also remember that code and art is not all. You will need sounds and often music before your game becomes a really solid product that gamers will appreciate and continue to play.

Getting started
Actually the best thing to start with is to learn many things about the tools you are working with and then how you combine them to more advanced things. Before you can learn anything you need to get everything up and running. Dev-C++ is a freeware development software that you can use when developing with SDL. To get this and SDL installed you should head over to Sol's SDL tutorial where you will find step by step instructions.

Sol's SDL tutorial

Sol's tutorial teaches you not only to install everything you need but also how to do some basic SDL programming and a step by step guide to make a simple game. If you don't want to do the whole tutorial, although it's good experience if you have little or no programming experience. There are more tutorials on SDL out there. Over at Cone3D Programming there are 6 tutorials on SDL programming, all of them are for 2D. They cover a lot of basic 2D stuff that you probably will find useful. I have never used these myself as I'm not gonna start developing for GP2X until in Dec or Jan as I have other things to do.

Cone3D tutorials

Once you have done the tutorials that you like it's always a good idea to get better knowledge. Dev-C++ comes with an introduction to C programming that you might find useful if you have any questions about programming in general. But you should also check out the SDL manual so that you know every command that is available for you to use. The more commands you know about the easier it will be to plan your games. If you have an idea but not a clue on how to code it then you need to learn your tools and then figure out how to solve the problem with what you got. The SDL

SDL website

The SDL website also have links to more tutorials on various subjects and other stuff you might find useful.


Books
lucoxade have recomended the book: "Programming Linux Games by John R. Hall, ISBN: 1886411492" as a great start for SDL and C++ programming including how to develop games. Sounds to me like a great book to pick up. He mentiones that it's a bit old but still a relevant and useful, can't see why it would not be as this is hardly anything that will change a lot.

I would like to recomend another book: "Game Design - Theory & Practice by Richard Rouse III, ISBN:1-55622-735-3". It got nothing to do with games programming but a whole lot to do with games designing. If you want to improve your design skills this is a great book and I agree with 99.9% of what he writes. The book is quite some years old but games design principles still aplies and it's getting more and more important today. As you may agree game design is not always as great today as it was before. The book also have a bunch of analysis on successfull games, that are even older then the book, like Tetris. There are also a few intervies with people like Sid Meier. Great layout and illustrations contribute to make this book a fun read.



Good luck with your game development!



If anyone would like to add or change anything in this little guide then feel free to make a post about it.

 

[no_skill]

stuff to be corrected:

SDL is plain C, thus it starts easing at C level. Eases C++ though
There's no SDL for OpenGL, SDL *gives* you OpenGL (more precisely: SDL initializes everything needed for opengl for you (window, graphics card etc etc))

and: this would be perfect for the gp2x dev wiki:

http://wiki.gp2x.org

 

[Digital Awakening]

Fixed the stuff you mentioned, thanks

 

[woogal]

And make sure that you focus on 1 game, complete it and have it properly and fully tested before you go on to the next game. With more experience you can make bigger and more advanced games. Halfmade games rarely get you anywhere and it's likely that you keep on developing halfmade games.

​

No, no, no, no, no.

No.

Only work on a game for as long as you are enjoying it. If that means you won't be satisified until the game is complete, then by all means complete it. But if you get bored after a while, put it to one side and move onto something else. Maybe you'll come back to it in a few weeks/months/years, maybe you'll never touch it again, but forcing yourself to work on something that you've lost interest in is the quickest way to put you off coding for life.

 

[no_skill]

woogal is right.

 

[Digital Awakening]

If you cant stick with your projects then you probably won't ever complete them and that doesn't make you a good game developer. Actually I would not call anyone without complete games a game developer. Completing your games is the hardest part about game developing, that's why there are often a lot of programmers around but very few completed games. I have completed 2 games and a forum (currently down) and I know what it takes.

 

[TreeFrog]

I'd say both woogal and Digital awakening both have valid points - personally I must have given up on dozens of half-baked games I've started over the years, and I've probably only really ever finished a couple (of the ones I've written as a hobbyist)
I'd suggest the most important first step is to not set your sights too high, and be realistic with yourself - do you really want to spend 2 years making an epic? Even if it seems like a great idea today, will it still seem like a great idea in a month? (let alone in a year). This is particularly valid if you've never written a game before - there's lots to learn with even a simple game before you're ready to tackle a complex project.

As with all things though, it really comes down to balance - don't give up on a game the instant something else catches your fancy, but don't force yourself to continue writing something that's boring you to tears.
(Of course, the above assumes you want to finish a game - if you're happy just playing about with whatever takes your fancy, that's fine too )

At the end of the day, we're just doing this as a hobby, so (to some extent) you'll just have to find what methodology works best for you.

Try and remember to enjoy it

 

[Quiest]

I stick to Woogals point, it makes no sense to force yourself into finishing a homebrew that you give away for free...

I mean, you make free homebrew games for fun, and if it`s no fun anymore, quit it.
If you want to earn money with your games, that`s another point...

 

[Recipio]

I totally agree TreeFrog. I've done alot of stuff but I've never released anything since I always get bored before I finish it and I think that the game engines are the most enjoyable part of the game to code.
I also think it's all about choosing a project that's within reach and won't take to much time so that you can finish it before you get bored.

 

[woogal]

If you cant stick with your projects then you probably won't ever complete them and that doesn't make you a good game developer. Actually I would not call anyone without complete games a game developer. Completing your games is the hardest part about game developing, that's why there are often a lot of programmers around but very few completed games. I have completed 2 games and a forum (currently down) and I know what it takes.

​

I'm not saying that people should never finish a game, but once you've written a menu where is the challenge in doing it again? Coding should be about learning new things and pushing yourself, not doing the same thing over and over again. Completing games is only the hardest part because most people get bored, it's not hard because it's difficult.

Just think about if you were working for a games company - would you like to be the person creating the game concept, or the person adding the menu to someone else's game? The person tidying up the game and adding the little fancy bits is the person who completes the game. Does that make them a better or worse coder than the guy who designed the game engine?

In my job I spend most of my time prototyping various systems (in fact the whole department spends most of it's time prototyping), and that's a position we've worked up to over the last few years. No-one bothers asking us to do the boring bits anymore because they know that we've got more important ideas to be developing.

Completing a game doesn't make you a good game developer, creating a great prototype does.

 

[TreeFrog]

Completing a game doesn't make you a good game developer, creating a great prototype does.

​

I've got to disagree with you on this, woogal. The polish and attention to detail that go in at the end of a project often make a huge difference to how a game plays and 'feels'.
Obviously, there's not much point doing this if the underlying game is rubbish, but even the best prototype will generally benefit from (simple example) a user friendly front-end, and (especially) being bug-free.

The point of prototypes (usually) is to try out an idea/feature/whatever, with (implicitly) the aim of doing something with the idea if it seems worthwhile, without the overheads of making a finished product. Games however, should be fun to play and the rough edges inherent in the prototype way of thinking will often detract from that.
As a gamer, I'd far rather (to generalise) play a good game than a great prototype - I've played too many games where I was left thinking, "there's some great ideas in this game - if only they were combined properly and polished"

In fact I'd argue that making a good prototype shows you're a good prototype developer, and making a (finished) good game shows you're a good game developer. These two skills share common elements, but are nonetheless distinct.

Just my thoughts

 

[lucoxade]

Also check out Programming Linux Games by John R. Hall ISBN: 1886411492

It's a realy great book for starting out with SDL and general C++ techniques and game structures, i bought it a couple of years back but it is still relevant and useful

 

[Shaking Your Fist Productions]

Great job Digital Awakening, and this will surely help me better understand coding for the GP2X. But the rest of them are right, you shouldn't keep making a game that you will get tired of. Saved on my hard drive right now are about 20 incomplete games made with MMF and about 4 finished ones. Its all about what you want to do.

 

[yaustar]

C++ Books: http://mindview.net/Books/TICPP/ThinkingInCPP2e.html
These are very good at teaching the C++ language if you have programmed before. Those new to programming will find some difficulty with these though as it assumes you know C.

As on the topic of finishing games or not, I find it doesn't really matter as long as you program code that is reusable. For example, writing an AI engine that is tightly woven to only work with the current game is going to be useless whether you finish it or not. If it was kept seperate from the main game engine, it can be used in a new game shortening development time and also avoids the daunting prospect of starting from scratch. It also means that a developers time hasn't been wasted on an unfinished/unreleased game.

I think Woogal's trying to say that anyone can finish a game using the base techniques, but a good developer would always be able to do thing faster, better and more advanced. For example, a 3d engine (eg Yeti). It isn't a finished game but has provided the ground to where a game can be made from it. Does it make the author a good game developer?

To be honest, at the moment I am getting confused between the various meanings of Game Developer, Games Programmer and Games Designer.

 

[Digital Awakening]

Like TreeFrog is saying gamers won't be happy with anything but a solid final product. I wrote the guide for game developers and not for prototype developers. It is always important in a game development that there is a good idea, esp the gameplay is very important. Thus those that are good with that should do that in a team. But if in the end you can't deliver a solid game then nobody will play your game. That's why things like quality assurance exists.

Even if you are doing it all freeware nobody will remember what you have done unless it's either a game they like to play or you do somthing so amazing that nobody else comes close. Also remeber that completed projects are a great when you are applying for work or want to get into some creative university programs like a game developers program. Also don't forget that many freeware games can lead to donations, building up a fan base for future commerical games or a good reference when trying to gather or join any development team even in a community.

But I will modify my post to better reflect your points since they are not completly wrong because sometimes you actually should abort a project if you either have taken on too big a project or you are really sick and tired of it.

 

[Digital Awakening]

To clearify what definitions I use:

Games Developer: A person that takes a game from idea to to finished project. May be a lonewolf or in some form of team, maybe he got an artist to help him out etc. But he has to be part of all/most of the development process.

Games Programmer: A person that primary/only involved in the programming aspect of a game. He usually work for someone or he just codes prototypes, functions, engines etc. He doesn't make a game on his own.

Games Designer: Similar to a programmer he works mainly on design. Game design have nothing to do with actually making the game but is very important in the development proccess because his designs are what all the producive members of the team are trying to recreate. He may be able to do some art and basic programming but he doesn't do development on his own but will rather try to gather others to do that work.

 

[mechanori]

How might one (one being me) set up SDL for the GP32? What are the extra, or modified steps? Is it a viable solution in terms of speed and ease of use? Should I just stick to the SDK?

 

[Digital Awakening]

I don't know if you can use SDL for GP32 so that's for somebody else to answer.

 

[yaustar]

There is an SDL runtime by Chui I believe, there were two or three games that used it. Beyond that I have non clue.

Games Developer: A person that takes a game from idea to to finished project. May be a lonewolf or in some form of team, maybe he got an artist to help him out etc. But he has to be part of all/most of the development process.

Games Programmer: A person that primary/only involved in the programming aspect of a game. He usually work for someone or he just codes prototypes, functions, engines etc. He doesn't make a game on his own.

hmmm.... Doesn't a Game Programmer also take an idea to a finished product as well though? After all, he/she has coded the main engine, developed an AI system and coded etc.. The idea may not neccasary be his/hers but fits the Developers profile from taking that idea and turning that into a game/finished product.

edit: Scratch that, the idea would be just the concept, the Designer would turn that idea into a game design for the programmer to develop off.

 

[judge0]

And make sure that you focus on 1 game, complete it and have it properly and fully tested before you go on to the next game. With more experience you can make bigger and more advanced games. Halfmade games rarely get you anywhere and it's likely that you keep on developing halfmade games.

​

No, no, no, no, no.

No.

Only work on a game for as long as you are enjoying it. If that means you won't be satisified until the game is complete, then by all means complete it. But if you get bored after a while, put it to one side and move onto something else. Maybe you'll come back to it in a few weeks/months/years, maybe you'll never touch it again, but forcing yourself to work on something that you've lost interest in is the quickest way to put you off coding for life.

​

I've got to agree with woogal there, nothing is worse than coding something you've lost all interest in.
Did a stint programming simulators of some DOS based tools to train some technicians for a call centre. I did a simulator for FDISK that just about drove me up the wall. Put it aside, came back to it a week later, rewrote it (from Dev-C++, in C, console mode), in PERL, put it aside. A week later rewrote it in Assembler(32-bit windows - praise be to Hutch), put it aside. A week later took the original C source and finished it. Felt like I was using WordPerfect 5 again, nothing but text routines.
There were typo's from hell in there, ran it through a spell checker - - - bad move.
the spell checker ate my source code . . . finally reverted to older source and finished it.
Submitted it to my boss - - - he REVIEWED it.
Said it needed some graphics to spice it up.
Took a trip to a lab unit to show him that it was correct in every screen (evidently his first view of DOS), finally got released 5 weeks after start.
Did I mention I got reamed for not using M$ Visual Studio?
Anyone want to see some truly boring source code????

Anyways, woogal is right, take a break from it, get a fresh perspective and try again.