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
CloseI think I may have caused some confusion accidentally. I should have been clearer initially, but I'm writing this from the ground up in C/C++ with SDL. This is how I've done the games like Pong and Breakout before, and one of my driving factors is keeping my OOP skills up to par since I don't use them for work often. I wouldn't worry too much about how to drive images or sounds or how to work collision detection; it's all stuff I've done before so I'm pretty well acquainted with my tools.
Since it's my first go at an RPG, the big reason I asked was organizational advice and stuff above mechanics. Though I will definitely be taking the idea of a test enemy and test battle. I need to have a test one if I plan on making a dungeon full of them after all. A lot of the advice directed towards how to use the RPG Maker engines is still quite applicable. For example, SpellcraftQuill mentions common events like the on touch encounters, which I could extrapolate to modular functions of some kind or functions contained in a class.
Another fast question. I don't think the gameplay will go far beyond 40 minutes, maybe an hour. Do you think having a Save feature is needed, or for something that short is it permissible to skip? It will definitely be something that I develop at some point for a longer game, but I don't see longer games nearby, so is saving something I could, for the present only, forego?
Since it's my first go at an RPG, the big reason I asked was organizational advice and stuff above mechanics. Though I will definitely be taking the idea of a test enemy and test battle. I need to have a test one if I plan on making a dungeon full of them after all. A lot of the advice directed towards how to use the RPG Maker engines is still quite applicable. For example, SpellcraftQuill mentions common events like the on touch encounters, which I could extrapolate to modular functions of some kind or functions contained in a class.
Another fast question. I don't think the gameplay will go far beyond 40 minutes, maybe an hour. Do you think having a Save feature is needed, or for something that short is it permissible to skip? It will definitely be something that I develop at some point for a longer game, but I don't see longer games nearby, so is saving something I could, for the present only, forego?
icecheetah
45
I personally would try and include a save system. I tend to play games in two ways:
10 minute burst
three hour marathon.
I would certainly want to be able to save for a 40 min game.
Edit: Even if it wasn't a game where, say, I could fail at the last minute and then have to start all over again.
10 minute burst
three hour marathon.
I would certainly want to be able to save for a 40 min game.
Edit: Even if it wasn't a game where, say, I could fail at the last minute and then have to start all over again.
author=icecheetah
I personally would try and include a save system. I tend to play games in two ways:
10 minute burst
three hour marathon.
I would certainly want to be able to save for a 40 min game.
Edit: Even if it wasn't a game where, say, I could fail at the last minute and then have to start all over again.
Are you tempting me to implement torture? I might have to now!
icecheetah
45
author=DrOctopus
Are you tempting me to implement torture? I might have to now!
RyaReisender
200
Oh, I also do RPGs with pure programming but they are graphic-free (except for ASCII maps and interfaces made with ASCII characters).
I've been doing these RPGs for years and what I've learned from them is:
1. Always document everything: monsters stats, how the character development growth works, draw down the whole dungeon maps on paper or in a grid file (spreadsheet works), document every single variable and what each value means, especially all the "bitsets" for quests. If you just leave one thing undocumented you will regret it later.
2. Put hero/party/map/etc. all in objects and give them an appropriate save function each. Design all the variables these structures need before you even start developing. Try to get them 100% at the start because changing them later will mean you can't use old saves you kept for balance and bug testing which means having to play from scratch or not being able to really estimate the stats of the party at a certain point anymore.
Keep enough room for array variables. At least double as much as you expect. Like if you think you just need 50 quest bitsets, make that 100.
3. Instead of putting all RPG object definitions (like dialogues!) right in your code, try to write functions that instead reads in external files of a format that's very easy to work with and adjust. Adjusting even just dialogues directly written into code later is a horrible mess. If you automatize as much as you can (like adding newline in appropriate places or showing the name of who is talking or text colour depending on the code type or choice inputs), you can save yourself more than 50% worktime.
I've been doing these RPGs for years and what I've learned from them is:
1. Always document everything: monsters stats, how the character development growth works, draw down the whole dungeon maps on paper or in a grid file (spreadsheet works), document every single variable and what each value means, especially all the "bitsets" for quests. If you just leave one thing undocumented you will regret it later.
2. Put hero/party/map/etc. all in objects and give them an appropriate save function each. Design all the variables these structures need before you even start developing. Try to get them 100% at the start because changing them later will mean you can't use old saves you kept for balance and bug testing which means having to play from scratch or not being able to really estimate the stats of the party at a certain point anymore.
Keep enough room for array variables. At least double as much as you expect. Like if you think you just need 50 quest bitsets, make that 100.
3. Instead of putting all RPG object definitions (like dialogues!) right in your code, try to write functions that instead reads in external files of a format that's very easy to work with and adjust. Adjusting even just dialogues directly written into code later is a horrible mess. If you automatize as much as you can (like adding newline in appropriate places or showing the name of who is talking or text colour depending on the code type or choice inputs), you can save yourself more than 50% worktime.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
In a typical RPG, however short, if you don't have a save system, you probably don't want game overs either. If the player loses, just put them back right before the battle.
In a longer game this can actually end up being more work than making a save system (due to having a lot of battles that occur during cut scenes or under other abnormal circumstances, which have to each be handled individually), but for your purposes I think it should work out fine.
Most of the people here have only ever used RPG Maker so forgive our limited insight into starting from scratch with nothing but the C++ code libraries.
Are you planning to have graphics? If not you'll obviously have a much simpler time. Creating the ability to walk around and explore a town and dungeon in a graphical environment might be too much for your first attempt. You could present the exploration/movement like a text-based adventure, with text descriptions of each room, giving the player a choice of which exit to take. Put a monster in each room, make it block a certain exit until you kill it.
Input could be text-based, but it would be easier to show a list of options on the screen and let the player use the arrow keys to choose between them. Your typical RPG menu-based combat is done like that already, but you could do movement and other actions like talking to NPCs the same way.
In a longer game this can actually end up being more work than making a save system (due to having a lot of battles that occur during cut scenes or under other abnormal circumstances, which have to each be handled individually), but for your purposes I think it should work out fine.
Most of the people here have only ever used RPG Maker so forgive our limited insight into starting from scratch with nothing but the C++ code libraries.
Are you planning to have graphics? If not you'll obviously have a much simpler time. Creating the ability to walk around and explore a town and dungeon in a graphical environment might be too much for your first attempt. You could present the exploration/movement like a text-based adventure, with text descriptions of each room, giving the player a choice of which exit to take. Put a monster in each room, make it block a certain exit until you kill it.
Input could be text-based, but it would be easier to show a list of options on the screen and let the player use the arrow keys to choose between them. Your typical RPG menu-based combat is done like that already, but you could do movement and other actions like talking to NPCs the same way.
Yes, I plan on putting graphics into it. I don't consider it a serious obstacle since I've done that end before. I probably wont go too ambitious with the maps by implementing a tiling system or something like that. Just a decent sized background with things placed on it and rampant abuse of rectangles to block motion.
I'm enjoying the thinking around the save mechanic. I could see placing them back at the entrance as another viable option over the game over with stats in tact. This way the next run would be quicker and easier, and when they arrive at the death point again, they will probably be able to overcome that since they should be stronger. That said, doing a simple save seems well worth the effort and it would be one of the easier things for me to do.
I could always do a stupid text based game with a no frills graphics end like Don't Shit Your Pants, but I think I might try to be a wee bit more ambitious:
http://www.kongregate.com/games/rete/dont-shit-your-pants
I'm enjoying the thinking around the save mechanic. I could see placing them back at the entrance as another viable option over the game over with stats in tact. This way the next run would be quicker and easier, and when they arrive at the death point again, they will probably be able to overcome that since they should be stronger. That said, doing a simple save seems well worth the effort and it would be one of the easier things for me to do.
I could always do a stupid text based game with a no frills graphics end like Don't Shit Your Pants, but I think I might try to be a wee bit more ambitious:
http://www.kongregate.com/games/rete/dont-shit-your-pants
SnowOwl
5188
Finish it. Even if it turns out shitty finish it and release it. Having one finished game teaches you alot more than 3 unfinished ones.
Anyone that tells you otherwise is a lazy nonfinisher.
It's like sex. Maybe it feels good without that last bit, but that last bit is what you're aiming for.
Anyone that tells you otherwise is a lazy nonfinisher.
It's like sex. Maybe it feels good without that last bit, but that last bit is what you're aiming for.
