Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
ADVICE ON MAKING A FIRST GAME
Posts
DrOctopus
View playlists
CloseSo, hi again,
I was here something like a year ago talking about a game project I was doing for school. Towards the end, I noticed it wouldn't really be feasible to share it since it required some not so typical tools. (Anyone doing work with FPGAs that may be interested, feel free to contact me since I have it and it's well documented, albeit, a little messy).
Well, now I want to make a game that is actually portable; it's more fun. As I was organizing myself, I noticed that I've pickled myself a little bit. Namely, I need some perspective on how to organize a simple game. I've made some small ones like Pong and Break Out before, but, organizing for an RPG is definitely a new ball game for me.
I'm going to keep my goals small for trying a first RPG. I'm thinking of the following, and hoping this is a good starting point:
- Two heroes, otherwise I might as well go Zelda style
- One Town with the heroes' home, One Forge for battle Items, One Vendor for other Items, and an entrance to
- One Dungeon, probably 5 floors
- Three Weapon & Armor types
- Three or so other Items
- Five or Six basic enemies
- One Boss
- One Ending
I plan to keep the stats simple, probably just Life, Attack, Defense, Speed, and Luck. I don't feel like doing any magic/PSI/whatever.
The reason I like this is because I should be able to easily extrapolate from this point into more elaborate games since the basics will be laid and created here.
If this seems like I'm missing something, let me know, or if I'm going too strong, again let me know please. Since I don't plan on being overly creative, more of an exercize here, I'll probably steal your usernames for use in the game. If you'd rather not, don't worry about offending; it's your name after all. Also, I'm looking for resources aside from MS paint to make simple graphics and music, etc, so anything there.
Sorry if this repeats a bunch of older thing, I'm just looking here to make sure my skeleton has all its bones.
I was here something like a year ago talking about a game project I was doing for school. Towards the end, I noticed it wouldn't really be feasible to share it since it required some not so typical tools. (Anyone doing work with FPGAs that may be interested, feel free to contact me since I have it and it's well documented, albeit, a little messy).
Well, now I want to make a game that is actually portable; it's more fun. As I was organizing myself, I noticed that I've pickled myself a little bit. Namely, I need some perspective on how to organize a simple game. I've made some small ones like Pong and Break Out before, but, organizing for an RPG is definitely a new ball game for me.
I'm going to keep my goals small for trying a first RPG. I'm thinking of the following, and hoping this is a good starting point:
- Two heroes, otherwise I might as well go Zelda style
- One Town with the heroes' home, One Forge for battle Items, One Vendor for other Items, and an entrance to
- One Dungeon, probably 5 floors
- Three Weapon & Armor types
- Three or so other Items
- Five or Six basic enemies
- One Boss
- One Ending
I plan to keep the stats simple, probably just Life, Attack, Defense, Speed, and Luck. I don't feel like doing any magic/PSI/whatever.
The reason I like this is because I should be able to easily extrapolate from this point into more elaborate games since the basics will be laid and created here.
If this seems like I'm missing something, let me know, or if I'm going too strong, again let me know please. Since I don't plan on being overly creative, more of an exercize here, I'll probably steal your usernames for use in the game. If you'd rather not, don't worry about offending; it's your name after all. Also, I'm looking for resources aside from MS paint to make simple graphics and music, etc, so anything there.
Sorry if this repeats a bunch of older thing, I'm just looking here to make sure my skeleton has all its bones.
RyaReisender
200
I would generally agree that it's best to make a real small-scale RPG as your first project. I don't necessarily agree to your game design plans as that's basically "I make a super generic average JRPG that's really short", because that will interest no one. If you are just doing it for yourself, then sure, go ahead, but if you want to make a small scale project that others actually enjoy playing, then you need to add a lot more unique things to it.
Since if you plan to make the game small scale, just one town and one dungeon, you can work a lot with the details instead. Don't just keep stats simple. Make the game have only a few battles, but make every battle unique, interesting and require a different tactic to win. Make more than just 3 parts of equip, don't make one particularly better than the other but make them matter for the battles (e.g. give the player some indication that a fire battle might approach and make him need to equip the fire shield to be able to win the next battle). Better use 4 characters for increased tactical/strategical aspects, ignore their background stories, just a group of heroes. Unless the unique part of your game shouldn't be the gameplay but rather the story. Then you can probably ignore the above and just think of a clever twist on what your game is even about.
Generally the idea is to plan small so you can actually flesh out every detail. Learning how to get the details perfect is what's important. Making a generic, simple and short RPG won't really teach you much other than learning to work with the tool.
Since if you plan to make the game small scale, just one town and one dungeon, you can work a lot with the details instead. Don't just keep stats simple. Make the game have only a few battles, but make every battle unique, interesting and require a different tactic to win. Make more than just 3 parts of equip, don't make one particularly better than the other but make them matter for the battles (e.g. give the player some indication that a fire battle might approach and make him need to equip the fire shield to be able to win the next battle). Better use 4 characters for increased tactical/strategical aspects, ignore their background stories, just a group of heroes. Unless the unique part of your game shouldn't be the gameplay but rather the story. Then you can probably ignore the above and just think of a clever twist on what your game is even about.
Generally the idea is to plan small so you can actually flesh out every detail. Learning how to get the details perfect is what's important. Making a generic, simple and short RPG won't really teach you much other than learning to work with the tool.
Jeroen_Sol
Nothing reveals Humanity so well as the games it plays. A game of betrayal, where the most suspicious person is brutally murdered? How savage.
3885
I'd say what's missing mostly is story. A game is not merely it's technical aspects but also it's narrative ones. So if you want to make a small game to practice, I'd say you should also give it a small short story, in order to practice writing.
I don't think it's so bad to have a generic one. Making it short actually makes it more appealing for those who do want a little bit of JRPG.
It would make it really appealing if you added an underlying theme, nice little interactions with townfolks or stuff like that (go play Sunken Spire for the latter)
Which goes to the storypoint Jeroen made.
I'd say the scope is pretty reasonable, and setting a base is a very good idea (also to practice balancing and such)
Good luck!
It would make it really appealing if you added an underlying theme, nice little interactions with townfolks or stuff like that (go play Sunken Spire for the latter)
Which goes to the storypoint Jeroen made.
I'd say the scope is pretty reasonable, and setting a base is a very good idea (also to practice balancing and such)
Good luck!
Thanks guys,
I knew I was forgetting something, and putting something into the dialogues and storyline was that, even if the game is short. I especially like the idea of one theme to tie it all together. That will give me a good deal of focus.
I knew I was forgetting something, and putting something into the dialogues and storyline was that, even if the game is short. I especially like the idea of one theme to tie it all together. That will give me a good deal of focus.
Actually, yes, starting small is a safe option. But it's actually good to make a massive overblown game, with a huge map, too many towns, and alot of enemies.
One, you'll get experience really quick on the perils and pitfalls of the process (versus starting small and being out of your depth for an epic game), but later, you'll know how to make a smaller game, plus have a better better grasp on what to do when you are ready to try again for an epic game. You take this risk, in essence, because the reward is knowing everything not to do, and how to do it right.
Two, it'll teach you not to take yourself too seriously. With any luck, this game will be trashed again, and again, and again. People will tell you actual feedback vs "I hated it" and you'll realize how to make a game that is simple and to the point, but tightly coded with no major errors.
Three, as you realize that ten years on a game doesn't necessarily make for a better game you'll try to streamline the game you have and/or work on a new one. This will prevent the notion that small games are perfect as well (many small games are simply unambitious, and bore the people playing them).
So, let's review. Big game, normal game, then whatever you want. You can do it whichever way you choose, but everyone needs some experience in both to be a decent developer. Also, your first game should try some convoluted special system (weather, day/night, or custom battle/custom menu are good candidates). When you have to test and retest the glitches, it gives you practice figuring out problems and solving them.
One, you'll get experience really quick on the perils and pitfalls of the process (versus starting small and being out of your depth for an epic game), but later, you'll know how to make a smaller game, plus have a better better grasp on what to do when you are ready to try again for an epic game. You take this risk, in essence, because the reward is knowing everything not to do, and how to do it right.
Two, it'll teach you not to take yourself too seriously. With any luck, this game will be trashed again, and again, and again. People will tell you actual feedback vs "I hated it" and you'll realize how to make a game that is simple and to the point, but tightly coded with no major errors.
Three, as you realize that ten years on a game doesn't necessarily make for a better game you'll try to streamline the game you have and/or work on a new one. This will prevent the notion that small games are perfect as well (many small games are simply unambitious, and bore the people playing them).
So, let's review. Big game, normal game, then whatever you want. You can do it whichever way you choose, but everyone needs some experience in both to be a decent developer. Also, your first game should try some convoluted special system (weather, day/night, or custom battle/custom menu are good candidates). When you have to test and retest the glitches, it gives you practice figuring out problems and solving them.
My advise is to not make a game at all. Fiddle around with the engine, and the various options. Become familiar with it so that you understand what it is that you have to do to make that game in your head that is totally also written down in, like, five different places!
So, ummm, you never actually make a game?
At some point, I would assume that you use what you've tested out for a purpose.
At some point, I would assume that you use what you've tested out for a purpose.
Hrm. Maybe I misspoke. I mean that if you have no clue what the heck you're doing, don't try to make anything, and experiment like crazy so that you have a better idea of what all you can do, so that you can make something!
I suppose that works too.
Also, I'm not sure you necessarily need to make a game, anyway. You can make a non-game program. Like a simulation or tutorial.
Also, I'm not sure you necessarily need to make a game, anyway. You can make a non-game program. Like a simulation or tutorial.
I agree with Bulma on this. A big sandbox that you'll never share with anyone as a testing ground gives you ample opportunity and incentive to play with various mechanics and just play around. Limiting scope limits your game and what you're going to do, which limits what you learn.
Sooz
They told me I was mad when I said I was going to create a spidertable. Who’s laughing now!!!
5354
author=Jeroen_Sol
I'd say what's missing mostly is story. A game is not merely it's technical aspects but also it's narrative ones. So if you want to make a small game to practice, I'd say you should also give it a small short story, in order to practice writing.
With beginner games, I don't know that you need anything more than most NES games had: YOU HERO. THERE BAD GUY. SIC 'EM!
My first game was a one-room drama involving lobsters, their king, and his missing crown. Also a subplot with an aspiring lobster queen. By this I mean there were 3 lobsters to talk to and their dialog changed when you picked up the crown and gave it to the king. It was truly a dramatic tour de force.
author=Sooz
My first game was a one-room drama involving lobsters, their king, and his missing crown. Also a subplot with an aspiring lobster queen. By this I mean there were 3 lobsters to talk to and their dialog changed when you picked up the crown and gave it to the king. It was truly a dramatic tour de force.
Why do I find this an interesting concept?
Sooz
They told me I was mad when I said I was going to create a spidertable. Who’s laughing now!!!
5354
Because lobsters own?
It's all good. My sister's first game surrounded her hero hero in tiles so that no matter which direction he went, he was murdered by a cat.
Sooz
They told me I was mad when I said I was going to create a spidertable. Who’s laughing now!!!
5354
That game also owns.
icecheetah
45
Extra Credits recently did a series on making your first game, the link leads to the first ep (and they do a lot of interesting stuff on making games in general).
The gist of it was:
1: Have a goal to finish it in about 3 months. Even if it's buggy at the end of it, it is yours. Share it with your friends!
2: Have a basic idea of a schedule for completing this game.
3: in that time try out different things, and if you spend more than an hour trying to do one thing, look for a tutorial.
4: Cut, cut, cut and cut some more. At this point you want a minimum viable product, something that shows the core of the idea more than anything.
This may not be perfect for you, but it still could be helpful.
The gist of it was:
1: Have a goal to finish it in about 3 months. Even if it's buggy at the end of it, it is yours. Share it with your friends!
2: Have a basic idea of a schedule for completing this game.
3: in that time try out different things, and if you spend more than an hour trying to do one thing, look for a tutorial.
4: Cut, cut, cut and cut some more. At this point you want a minimum viable product, something that shows the core of the idea more than anything.
This may not be perfect for you, but it still could be helpful.
author=icecheetah
Extra Creditsrecently did a series on making your first game, the link leads to the first ep (and they do a lot of interesting stuff on making games in general).
The gist of it was:
1: Have a goal to finish it in about 3 months. Even if it's buggy at the end of it, it is yours. Share it with your friends!
2: Have a basic idea of a schedule for completing this game.
3: in that time try out different things, and if you spend more than an hour trying to do one thing, look for a tutorial.
4: Cut, cut, cut and cut some more. At this point you want a minimum viable product, something that shows the core of the idea more than anything.
This may not be perfect for you, but it still could be helpful.
I really liked this series, thanks a bunch.
Everyone, also, thanks for the strong response. I've got some basic things going and I have all the tools I need installed. By the end of this week my # 1 goal is going to have sprites displaying. I feel this isn't too hard.
Take whatever sample maps you can if you're using a specific tileset or other maps using that tileset. Consider them debug rooms. I'd suggest deleting them once you create the game proper.
Create a test enemy and just one group.
Add "common events" that is events that will be reoccuring at not necessarily in the common event tab such as on-touch encounters.
Do as little as you can so you can test evented features out.
Create a test enemy and just one group.
Add "common events" that is events that will be reoccuring at not necessarily in the common event tab such as on-touch encounters.
Do as little as you can so you can test evented features out.
RyaReisender
200
author=Soozauthor=Jeroen_SolWith beginner games, I don't know that you need anything more than most NES games had: YOU HERO. THERE BAD GUY. SIC 'EM!
I'd say what's missing mostly is story. A game is not merely it's technical aspects but also it's narrative ones. So if you want to make a small game to practice, I'd say you should also give it a small short story, in order to practice writing.
My first game was a one-room drama involving lobsters, their king, and his missing crown. Also a subplot with an aspiring lobster queen. By this I mean there were 3 lobsters to talk to and their dialog changed when you picked up the crown and gave it to the king. It was truly a dramatic tour de force.
I think for a small-scale RPG a philosophical story is best.
Y'know like: YOU HERO. THERE BAD GUY. YOU KILL BAD GUY. FIND OUT BAD GUY IS ACTUALLY YOUR BRAIN. YOU DIE.
