First of all, hello to everyone here. I've been lurking around this forum for several weeks now, and I figured I might as well get in on the conversation. I love taking part in active communities like this.
As for my topic, I've noticed that you have several game building compos on the board, so it seems some of you have got tile based game design down to a pretty efficient science. I'd realy like to get in on the action here, but I'm having trouble figuring out where to start. I taught myself QBasic years ago from the help files, I studied c++ and java in college, and I picked up some windows programming while trying futiley to teach myself Direct3D from a book.
What I'd like to see is a step by step tutorial for building something like a tile based RPG - i.e. Phantasy Star. Something that covers everything from conception to final build. I'm sure I have the technical ability to figure out any one of the steps for myself, but my weakness is in the planning. I have dozens of projects where I created a couple of functions and types, then got stuck and moved on to something else. If I could build an RPG in 30 days, I would do it all the time. I just need to know the process.
If something out there already covers this, could you point me in the right direction? Otherwise, maybe this could be a project for some of the forum members to collaborate on, to help out desparate n00bs like myself.
Thanks!
Game Development: Square One
-
E.K.Virtanen
- Posts: 785
- Joined: May 28, 2005 9:19
- Location: Finland
Personally i dont like those "Create game in 30 days" tutorials. You just follow tutorial, but do you learn anything actually?
Creating a rpg is a huge task, even with smaller story lines. It is easy to figure out some neat functions, create even more neat functions yourself, but putting these peaces in places to get a runnable and playable game is something totally else.
Maybe someone who has cerated more games could do a rpg tutorial for new game programmers (or those who wants to advance as game programmer) but even then, it would be more like a "hints and tips" article than a game making tutorial.
There is billion different things that will affect how the source of game lives. No one cant write a tutorial wich covers them all. And different things used in different projects.
Though, this is my personal opinion and most likely there is peoples who disagrees totally.
Creating a rpg is a huge task, even with smaller story lines. It is easy to figure out some neat functions, create even more neat functions yourself, but putting these peaces in places to get a runnable and playable game is something totally else.
Maybe someone who has cerated more games could do a rpg tutorial for new game programmers (or those who wants to advance as game programmer) but even then, it would be more like a "hints and tips" article than a game making tutorial.
There is billion different things that will affect how the source of game lives. No one cant write a tutorial wich covers them all. And different things used in different projects.
Though, this is my personal opinion and most likely there is peoples who disagrees totally.
Good point and well made. Thanks.
I guess the problem I'm having getting started is that my code quickly takes on a cluttered feel. Now I can </'REM'/> with the best of them, I can compartmentalize oft-used procedures into functions and subroutines, and I have a great feel for the general flow of programming, both procedural and object oriented.
Generaly, when I'm trying to learn some new code wizardy, I'll copy/paste like a bandit, play with all the parameters I can, and eventually rewrite it for my own diabolical uses. When it comes to planning a game though, I find that the structure of the code is so far abstracted from the feel of the game that the only recognition I get from looking at it is subjugated down to being vaguely familiar with some function or other, but having no idea why it's used here and now.
Where is square one? Let's say I wanted to create a simple RPG. The story: Once upon a time, by and by, the end. Two towns, half a dozen NPCs, two random badies, a treasure chest, and a sword. It would have animated sprites from a tileset, a sound track, SFX, a menu based fighting system, an options screen, and a catchy title. I should think there would be some standard, or at least a generaly accepted theory as to how these elements should be organized to make a playable game. Some way to ensure continuous music playback, allow asychronous sprite animations and all that. I guess I don't want someone to try to tell me how to do it exactly, but what's the first thing I have to figure out?
I guess the problem I'm having getting started is that my code quickly takes on a cluttered feel. Now I can </'REM'/> with the best of them, I can compartmentalize oft-used procedures into functions and subroutines, and I have a great feel for the general flow of programming, both procedural and object oriented.
Generaly, when I'm trying to learn some new code wizardy, I'll copy/paste like a bandit, play with all the parameters I can, and eventually rewrite it for my own diabolical uses. When it comes to planning a game though, I find that the structure of the code is so far abstracted from the feel of the game that the only recognition I get from looking at it is subjugated down to being vaguely familiar with some function or other, but having no idea why it's used here and now.
Where is square one? Let's say I wanted to create a simple RPG. The story: Once upon a time, by and by, the end. Two towns, half a dozen NPCs, two random badies, a treasure chest, and a sword. It would have animated sprites from a tileset, a sound track, SFX, a menu based fighting system, an options screen, and a catchy title. I should think there would be some standard, or at least a generaly accepted theory as to how these elements should be organized to make a playable game. Some way to ensure continuous music playback, allow asychronous sprite animations and all that. I guess I don't want someone to try to tell me how to do it exactly, but what's the first thing I have to figure out?
-
E.K.Virtanen
- Posts: 785
- Joined: May 28, 2005 9:19
- Location: Finland
I know what you mean. Been there, done that, just like thousands of other new programmers.
"How to make an rpg" for beginners would be bad also, since programming is hard work, even for hobby programmers. If someone would give them a 50% finished source and simple details how to finish the game, it would give way wrong image of what programming is.
For a beginner, even simple games like snake games, puzzles etc. are pretty hard ones. It is amazing how long code gets when you create a game, even a simple one. And putting all the peaces in places and making them work as game is more than many programmer can imagine.
For this same reason, high % of "Coolest game ever" announcements at projects forums will not ever get finished.
In my opinion, tutorials and detailed documents for newbies how to make a rpg in 30 days are not worth of it. Its better to start with "hang man", "snake clone" and related projects. When skills are enough, you enter to next level wich is in this case, rpg's and so on.
Programming languages like FreeBASIC are pretty easy to learn, but using programming language to reach your goal is different thing.
There is game maker softwares wich gives beginners possibility to create games by "click and go" method, but in my opinion, they dont have anything to do with programming and they are gummy codes and buggy ones too.
But hopefully we see some rpg made by you in future :)
"How to make an rpg" for beginners would be bad also, since programming is hard work, even for hobby programmers. If someone would give them a 50% finished source and simple details how to finish the game, it would give way wrong image of what programming is.
For a beginner, even simple games like snake games, puzzles etc. are pretty hard ones. It is amazing how long code gets when you create a game, even a simple one. And putting all the peaces in places and making them work as game is more than many programmer can imagine.
For this same reason, high % of "Coolest game ever" announcements at projects forums will not ever get finished.
In my opinion, tutorials and detailed documents for newbies how to make a rpg in 30 days are not worth of it. Its better to start with "hang man", "snake clone" and related projects. When skills are enough, you enter to next level wich is in this case, rpg's and so on.
Programming languages like FreeBASIC are pretty easy to learn, but using programming language to reach your goal is different thing.
There is game maker softwares wich gives beginners possibility to create games by "click and go" method, but in my opinion, they dont have anything to do with programming and they are gummy codes and buggy ones too.
But hopefully we see some rpg made by you in future :)
-
anonymous1337
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
Games are Games are Games. I've recently read up on Game Theory, which believe it or not, was actually definitely worth the read! It's a lot harder to make a good game than I thought. At least a big game.
Games are made up of other games, which are also made up of other games. Think of any game you've ever played and break it down into all of the games that you can play with it.
Boring games consist of only a few games in a large feature set (Ex: You just wasted development time). Fun games get straight to the point. If your game is only going to consist of a few smaller gameplay elements, don't overdo it! D:
I think a large challenge you'll find in Game Development is that you waste development time on features that aren't even related to your gameplay elements. Those features can generally be completely removed and developed in a faster and more fun manner!
Here at the forum we tend to tell beginners that trying to code a big RPG adventure will be a waste of at least a year of their programming career. That usually shows to be right, because I have done the same, and I've seen others do the same. Look at how many elements are contained in the average RPGs, or other larger genres. The fact is that a lot of programmers (me included) think of features to add into their game, without that feature actually being fun or contributive to gameplay.
Games are made up of other games, which are also made up of other games. Think of any game you've ever played and break it down into all of the games that you can play with it.
Boring games consist of only a few games in a large feature set (Ex: You just wasted development time). Fun games get straight to the point. If your game is only going to consist of a few smaller gameplay elements, don't overdo it! D:
I think a large challenge you'll find in Game Development is that you waste development time on features that aren't even related to your gameplay elements. Those features can generally be completely removed and developed in a faster and more fun manner!
Here at the forum we tend to tell beginners that trying to code a big RPG adventure will be a waste of at least a year of their programming career. That usually shows to be right, because I have done the same, and I've seen others do the same. Look at how many elements are contained in the average RPGs, or other larger genres. The fact is that a lot of programmers (me included) think of features to add into their game, without that feature actually being fun or contributive to gameplay.
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
I know I'm probably going on liver to many with spamming this tutorial of mine, but I can't help myself not recommending it in this sort of situations.
Download it here (download this file; don't look for other versions on the net - they are outdated): http://lachie.phatcode.net/Downloads/Ho ... Game_1.zip
I don't now on which stage you are, but it should get you started with FBGfx basics like screen initiation, screen swapping, graphics loading, keyboard control, etc.
There is a second edition of this tutorial, but I still haven't converted it to the latest version of FB. After comprehending this first tutorial, you could check it ONLY as a reference on some coding methods I teach, but like I said, the code in the second tutorial won't compile in the current version of FB: http://lachie.phatcode.net/Downloads/ho ... n_FB_2.zip
I do agree with others that "Do a RPG in 30 days" tutorial wouldn’t be a good idea. More tutorials covering several aspects of game design are a much better idea, which I’m doing with my tutorials (QBE #23,QBE #24). I really think you should code few simple games first, and then a RPG should come by itself, with possible help of a scrolling engine of some sort. I might recode my own one which is now outdated. I personally don't consider RPGs that fancy. So many others game design concepts that are much more appealing to me.
Anyway, go slowly. You will regret skipping steps sooner or later.
Download it here (download this file; don't look for other versions on the net - they are outdated): http://lachie.phatcode.net/Downloads/Ho ... Game_1.zip
I don't now on which stage you are, but it should get you started with FBGfx basics like screen initiation, screen swapping, graphics loading, keyboard control, etc.
There is a second edition of this tutorial, but I still haven't converted it to the latest version of FB. After comprehending this first tutorial, you could check it ONLY as a reference on some coding methods I teach, but like I said, the code in the second tutorial won't compile in the current version of FB: http://lachie.phatcode.net/Downloads/ho ... n_FB_2.zip
I do agree with others that "Do a RPG in 30 days" tutorial wouldn’t be a good idea. More tutorials covering several aspects of game design are a much better idea, which I’m doing with my tutorials (QBE #23,QBE #24). I really think you should code few simple games first, and then a RPG should come by itself, with possible help of a scrolling engine of some sort. I might recode my own one which is now outdated. I personally don't consider RPGs that fancy. So many others game design concepts that are much more appealing to me.
Anyway, go slowly. You will regret skipping steps sooner or later.
Last edited by Lachie Dazdarian on Oct 19, 2007 20:30, edited 1 time in total.
-
notthecheatr
- Posts: 1759
- Joined: May 23, 2007 21:52
- Location: Cut Bank, MT
- Contact:
Start with the basics, then progress. Start writing programs of only medium complexity before you try to write something truly great.
There is "learn to write a game in 30 days" - they'll make the game for you, but they won't teach you how, really. As Norvig says, you should focus on learning how to program in 10 years... that will make you worth far more than if you learn in "21 days" or "30 days."
There is "learn to write a game in 30 days" - they'll make the game for you, but they won't teach you how, really. As Norvig says, you should focus on learning how to program in 10 years... that will make you worth far more than if you learn in "21 days" or "30 days."
All right, first of all, thanks for all the advice people. I love seeing a community this involved and active! The attached file is a program I recently threw together, in case anyone is wondering where my skill level is. It's a sort of celular automata thingy, but based on average local color rather than a boolean state. The bitwise artifacts it creates (due to treating the color value as a single integer, not RGB) are pretty cool. I know some of you like some random eye candy once in a while!
I'm a big proponent for procedural algorithmic content (see demoscene, spore) over rescource dependency.
http://files-upload.com/files/569136/average.rar
Source and exe are included. No commenting, poor structure, no optimization - like I said, I threw this together. (~1 hr)
As for the advice, I said it was good so I'll start working on some simple games for now. <grumble, moan, etc...> I just hope I can keep my scope under control!
Thanks again!
edit: I guess I should mention that the program runs fullscreen, and that any mouseclick will terminate the program. I know most people use the "while INKEY$ = "" ..." yada yada yada. I usually don't. Just thought it was fair play to let you know how to exit the app.
I'm a big proponent for procedural algorithmic content (see demoscene, spore) over rescource dependency.
http://files-upload.com/files/569136/average.rar
Source and exe are included. No commenting, poor structure, no optimization - like I said, I threw this together. (~1 hr)
As for the advice, I said it was good so I'll start working on some simple games for now. <grumble, moan, etc...> I just hope I can keep my scope under control!
Thanks again!
edit: I guess I should mention that the program runs fullscreen, and that any mouseclick will terminate the program. I know most people use the "while INKEY$ = "" ..." yada yada yada. I usually don't. Just thought it was fair play to let you know how to exit the app.
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Hmm, an RPG ought to be no different from any other "simpler" game, except in terms of scale. You can get away with bad practice easier on a simpler game, though, and it often takes people a few goes to figure out what good practice is, when it comes to making a game.
For instance, I've written the same puzzle game three times in three very different languages (Java, Assembly and FreeBasic), and only in the last (FB) version (here: http://www.reanimation.co.uk/blog/?p=18) have I managed to get the scrolling working how I like. It was really just a matter of adding a camera structure, which had just not really occurred to me before.
I also remember that with my first Game Maker game, the front end was a bit of an afterthought, and it was quite difficult to fit it in and get it working properly. It takes a few games to arrive at a framework you can reuse.
But should it? Does everyone have to work this stuff out for themselves?
It might not be unreasonable to try to put together some tutorials which explain how to structure a game so that any level of complexity can be attempted. It's too easy, for instance, to concentrate on how to do the graphics, and overlook the data, which is ultimately more important. (It should usually be possible to change the graphical style completely without seriously affecting the gameplay.) I'm thinking finite state machines, data types, data-driven game engines, that kind of thing.
For instance, I've written the same puzzle game three times in three very different languages (Java, Assembly and FreeBasic), and only in the last (FB) version (here: http://www.reanimation.co.uk/blog/?p=18) have I managed to get the scrolling working how I like. It was really just a matter of adding a camera structure, which had just not really occurred to me before.
I also remember that with my first Game Maker game, the front end was a bit of an afterthought, and it was quite difficult to fit it in and get it working properly. It takes a few games to arrive at a framework you can reuse.
But should it? Does everyone have to work this stuff out for themselves?
It might not be unreasonable to try to put together some tutorials which explain how to structure a game so that any level of complexity can be attempted. It's too easy, for instance, to concentrate on how to do the graphics, and overlook the data, which is ultimately more important. (It should usually be possible to change the graphical style completely without seriously affecting the gameplay.) I'm thinking finite state machines, data types, data-driven game engines, that kind of thing.
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Now PlayerOne, why the community wasn't informed about this lovely game of your? Love the graphics! Can I add it to my FreeBASIC Games Directory (http://games.freebasic.net)?
And yes, those are nice suggestions, but you do realize that such tutorials would result with some pretty neat game design tools, which I'm sure some people would already code if they had the energy and ability, if not for others then for themselves. The point is - that thing ain't so simple.
And yes, those are nice suggestions, but you do realize that such tutorials would result with some pretty neat game design tools, which I'm sure some people would already code if they had the energy and ability, if not for others then for themselves. The point is - that thing ain't so simple.
That sound like a positive to me. I'd much rather design my own game engine then use someone elses. I think Player One got the gist of what I was asking about. I'm just taking one step at a time for now. I'm working on a walking biped right now, using an artists' animation reference I found online as a template.
-
Lachie Dazdarian
- Posts: 2338
- Joined: May 31, 2005 9:59
- Location: Croatia
- Contact:
Sure. I meant to add it myself, but I'm pretty disorganised and lazy most of the time. It doesn't even have a proper home page, yet, and I was planning to make the source available too.Lachie Dazdarian wrote:Now PlayerOne, why the community wasn't informed about this lovely game of your? Love the graphics! Can I add it to my FreeBASIC Games Directory (http://games.freebasic.net)?
I didn't really see it as a community thing, to be honest. It's just a game. I wasn't really visiting any community sites at the time (including this one).
I was just kind of thinking aloud regarding the game structure tutorials. It's something I might have to have a go at myself.