Okay so I was in the shower thinking about game development (weird huh?) and how I should probably start practicing it and working on building a set of skills to use in the near future. Instantly, I was thinking about a ton of ideas on how to make a decent text based RPG, but quickly I became overwhelmed with the amount of information that was running through my mind. I thought of storylines, features, how to implement those feature, what features would be too much of a nuisance to actually put in the game, etc. And so I wanted to get someone's opinion on how the process should go.
Should I create a general idea for the story first and then work on making the game part work, or should the actual game functionality come first, with the idea for story molding to fit it?
Txt based (dos) game
Moderator: PC Supremacists
- ultimatedragoon69
- Chaos Rift Regular
- Posts: 122
- Joined: Tue Oct 28, 2008 1:57 pm
- Current Project: Pangea's quest (text ~tile~ based rpg)
- Favorite Gaming Platforms: Dreamcast, PC, playstation 1, Virtual Boy, Snes
- Programming Language of Choice: c++
- Contact:
Re: Txt based (dos) game
It really determines how much you plan to put into it and how much you know. RPG's in general is a massive can of worms that when are opened will blow your mind. Of course like i said before it really determines what you want to do with it. When you say text based rpg there are numerous kinds that i think of. Some being incredibly complex and some being really simple. So...
As a starting point i would suggest putting your ideas on paper think of how you want it to work.(the best plans are the well designed plans). Once you got how you want it all to be put together then i would start with the game. I've always firmly believed that the better the engine the better the game. Thus my game is taken forever to finish. I wish you luck, i will watch your progress if you decided to post it.
As a starting point i would suggest putting your ideas on paper think of how you want it to work.(the best plans are the well designed plans). Once you got how you want it all to be put together then i would start with the game. I've always firmly believed that the better the engine the better the game. Thus my game is taken forever to finish. I wish you luck, i will watch your progress if you decided to post it.
-
- Chaos Rift Newbie
- Posts: 34
- Joined: Sun Aug 31, 2008 8:44 pm
Re: Txt based (dos) game
I think I will try to post up progress here, since I need to get in the habit of documenting my work. ( I love organization but hate taking the time to organize).
By text based RPG, I mean I mean trying a old school phantasy star style game except with text replacing the graphics. I figure that way I don't have to deal with all the input stuff, and can expand it later once I have some practice under my belt.
By text based RPG, I mean I mean trying a old school phantasy star style game except with text replacing the graphics. I figure that way I don't have to deal with all the input stuff, and can expand it later once I have some practice under my belt.
- Van-B
- Chaos Rift Regular
- Posts: 125
- Joined: Tue Aug 10, 2010 7:17 am
- Current Project: iPhone puzzle game
- Favorite Gaming Platforms: All - Except Amiga
- Programming Language of Choice: DBPro, ObjC++
- Location: Scotland
Re: Txt based (dos) game
When you do away with visuals (well mostly), your game has to have a lot of depth to it, I mean look at that text based Dwarf Fortress game - it's insanely complex, with lots of possibilities and a strong sand box gameplay - it's kinda like Dungeon Keeper for haxxors. But at the same time, you can concentrate on that, wheras usually a lot of time would be required to program the graphics handling, media creation etc.
I like to use Excel, or any spreadsheet system really when developing games - if you build the basic framework in excel, data, combat etc, then you can fine tune things as you program them. A lot of the challenge will be in keeping track of all the data, all the character properties, inventory, and AI. It's always a good idea to know these requirements before starting work. One thing that I would always do with an RPG though, is make a basic scripting system for items, magic etc - as that way you can really cut down on the amount of custom coding you have to do. Maybe there is 1 item in your game that does something special, maybe a character has a bad knee, and it slows them down but only if it's cold. That sort of depth can be easy to add if you prepare the engine well enough. Every time I think about making an RPG, I always envisage an item having it's own little script, maybe even a single text string that is parsed when the object is used. It does take time to impliment command parsing, but once it's in place the world quickly becomes your oyster. Maybe using an established system like LUA would speed up development.
I like to use Excel, or any spreadsheet system really when developing games - if you build the basic framework in excel, data, combat etc, then you can fine tune things as you program them. A lot of the challenge will be in keeping track of all the data, all the character properties, inventory, and AI. It's always a good idea to know these requirements before starting work. One thing that I would always do with an RPG though, is make a basic scripting system for items, magic etc - as that way you can really cut down on the amount of custom coding you have to do. Maybe there is 1 item in your game that does something special, maybe a character has a bad knee, and it slows them down but only if it's cold. That sort of depth can be easy to add if you prepare the engine well enough. Every time I think about making an RPG, I always envisage an item having it's own little script, maybe even a single text string that is parsed when the object is used. It does take time to impliment command parsing, but once it's in place the world quickly becomes your oyster. Maybe using an established system like LUA would speed up development.
Health, ammo.... and bacon and eggs.
- dandymcgee
- ES Beta Backer
- Posts: 4709
- Joined: Tue Apr 29, 2008 3:24 pm
- Current Project: https://github.com/dbechrd/RicoTech
- Favorite Gaming Platforms: NES, Sega Genesis, PS2, PC
- Programming Language of Choice: C
- Location: San Francisco
- Contact:
Re: Txt based (dos) game
Not sure why you had "determines" in there, maybe you were tired, maybe you always make typos that are other words like me (most annoying thing ever).ultimatedragoon69 wrote:It really depends upon how much you plan to put into it and how much you know. RPG's in general is a massive can of worms that when are opened will blow your mind. Of course like i said before it really depends on what you want to do with it.
I lol'd.Van-B wrote:Maybe there is 1 item in your game that does something special, maybe a character has a bad knee, and it slows them down but only if it's cold.
Falco Girgis wrote:It is imperative that I can broadcast my narcissistic commit strings to the Twitter! Tweet Tweet, bitches!
-
- Chaos Rift Junior
- Posts: 209
- Joined: Thu Feb 12, 2009 8:46 pm
Re: Txt based (dos) game
Sounds like the age-old question: should I make a game, or a game engine?villeballa89 wrote:Should I create a general idea for the story first and then work on making the game part work, or should the actual game functionality come first, with the idea for story molding to fit it?
If you're just starting to make games, and you're trying to learn, rather than attempting to develop multiple games for publication, then I recommend that you remove the engine aspect, and start with a general idea for the story, and possibly some "wow" features that you may end up spending most of your time developing, and finally, concentrate on the implementation of those ideas. If, in the future, you wish to make a game engine, then you can look towards your older games for guidance, and commonly used functionality; and develop your engine based on a strict, but flexible-enough design plan. If you spend time designing and developing certain aspects that you're not sure you'll use for those games, then that may be taking away from the time that could have been spent designing them.