Well, I made a thread about making a 3d pokemon game. I didn't get a lot of support for that idea, and the more I think about it, I'd like to work on something of my own.
So, here is my current idea. I like the idea of a creature capturing game, in the spirit of pokemon and similar games. So I want to make a RPG, maybe third person, that indeed center's around the capture and raising of creatures. Note: I'm not going to make a game based on capturing humans. Sorry.
I have some idea's on things I want to do, but my purpose in making this thread is to hear things I either havn't thought of, or aren't occuring to me. Things that really should get put in games, but for some reason, published games don't include, or not yet.
Basically, what do you want to see in such a game?
I cant url good so add me on steam anyways
steamcommunity.com/id/Raslin
3ds friend code: 2981-6032-4118
Posts
(Please note Zombie ninjas not zombies having sex with the ninjas, well unless they were both women, and hot, and the zombie wasn't to gross or anything like that)
Satans..... hints.....
360 Gamertag: Baronskatenbass Steam: BaronVonSnakPak HgL: AnsonLuap
Battle animations I am completely for. The fighting will be real time, or some hybrid of real and turn based, at least thats the plan.
Mini-game? Seems so cliche... besides, who wants to be trying to capture some awesome creature, and you fuck up on some minigame that has nothing to do with actually having a good party, or being good at the actual game?
3ds friend code: 2981-6032-4118
Having the ability to "customise" the creatures that you have captured was my favorite part of the Poke'Mon games. By customise I mean selesct the lineup, and the attacks that they have (assuming you plan on battling them).
Have you given any thought into releasing it on the 360 through XNA?
Steam / Bus Blog / Goozex Referral
I'm guessing the former, but I like the latter a lot more. Maybe because monsters by nature are supposed to look a little evil, or something.
Also, I like the conversations SMT allows: demons have more personality when you can try to talk it out with them instead of killing them outright.
So long story short, I think the more depth it has, the better. Can't go wrong with personality and story.
Well, lets see.
1. I dont own a 360, and probably won't for a good while.
2. I don't know any C, C+, or whatever it was XNA uses.
3. This is a good point though. I'd also like suggestions on what kind of engine, etc I should use. I've thought about sauerbraten, but... I dunno.
Also, the creatures will indeed battle, and you will defidentally get customization. I presume you will be able to have more than one creature at your side at a time, but I'm not quite sure. I also don't know how I'm going to do 'moves'. I might try to be innovative, and phail.
Iwakura, I'm going to make it me-themed, honestly. That will probably fall somewhere between the two you mention, closer to everyone-themed possibly. I have this vision of a brightly light, and brightly colored game though
3ds friend code: 2981-6032-4118
i only suggested it because im growing tired of games these days that are becoming more of "press a button, watch 5 second animation". and something as important as capturing in a creature capturing game should heavily involve the player.
360 Gamertag: Baronskatenbass Steam: BaronVonSnakPak HgL: AnsonLuap
Call it something like Ultra Fighter 2121.
The exclamation mark is part of the title.
Why are the 'creatures' battling? Who is making them battle and why? What do they wish to gain from winning a battle? What do you define as a 'battle'?
Make something simple to start off with. A "game" where you just have to walk through a maze or something.
Then make a simple "battle" game where two enemies duke it out. A turn-based engine would be pretty simple to implement.
Then you could put enemies in the maze, and have the battle come up when you run into them. You can add stats to your player, so that they are damaged as a result of the battle, or level-up after each fight.
Then you can start thinking about expanding these primitive elements into a proper game. Trying to be too ambitious at the start is just asking for disappointment.
If he can figure out exactly what he wants to make by asking himself some simple questions it can help a lot. Personally I only start working on the solid stuff like coding or graphics when I know exactly what I want, thanks to having an in-depth design phase. For example, choosing a coding language that limits you to doing certian things limits your ability to do other things, I think it's worth taking the time to really think about what you want and need, then choose what delevelopment tools you need to use to make it.
EDIT: the real question is, has the origonal poster got an idea they want to do turn into a game or do they want to get enjoyment out of the actual process of coding and have a finished product as soon as possible, even though they are not entirley sure what they they want yet? At this moment I think it is the latter so take Marlor's advice by all means if you want to jump straight into the development side of things
The things I look for in an RPG:
-Open ended mechanics. Basically lots of shit to do in between the story if there is any. Shadowrun, Fallout and Star Ocean 2 are good examples of this.
-Active combat system. I like taking an active role in fighting things instead of selecting "Attack" in a menu. Examples of this are in Tales of Symphonia, Secret of Mana, Star Ocean 2...
I'm not sure how the second would fall into the game you're proposing. If you think combat would be to flimsy, perhaps having a timing mechanism of sorts to keep people on their toes? If there's enough strategy involved with creature combat then I say do what you feel is right.
This is fair enough advice if you are experienced with coding, but if you aren't, then your design phase won't be grounded in reality. The OP said he doesn't know C or C++, so I'm not sure what languages he is proficient in. If he's not interested in learning C, then that will limit his choice of library somewhat, and will in turn restrict the possibilities for the game.
Really, the best thing to do is to find a library that isn't too complex, does the sorts of things he envisages in his overall idea for the game, and is available in a language that he either knows or is willing to learn, and to start experimenting with it.
Part of making a good design plan is knowing what is and isn't realistic. Experimentation is needed to determine this.
Some people enjoy the challenge of outwitting a wiley opponent. How about having to analyise the creature's behavioral patterns, then setting up the appropriate traps for them to be lured/scared into. What traps would be appropriate for catching something such as a (sorry for the pokemon examples, but bear with me here) Rhydon? As we all know, a Rhydon is an angry juggernaut, a creature similar to a Rhydon (I may as well have said a rhino) may easily be lured into attacking the player, but you may need to lead them to an appropriate trap such as a camoflaged pit or something. Maybe you haven't studied this creature enough and didn't realise it is very perceptive? It could take note of things such as camoflage, as indicated by it's ability to spot camoflaged creatures to eat them. It could notice your pit trap and leap over it, causing you to quickly come up with a plan B or just get the hell out of there.
Now, for people saying that is too ambitious, we come uot with a fleshed out idea and simply dumb the details down a little, for example, someone could imagine this as a lucious 3d game with hundreds of species all with their own AI patterns and other could of even pictured it as a simple board game.
Just throwing ideas out there
EDIT
This is also true, but unless the origonal poster only has C++ available to use I'd say that it is best to be imaginative and inventive at first then find a way to get those ideas to work in a game. As to your comment about being 'grounded in reality', since we are all avid games players I think we all know what can and can't work on todays systems so I'm pretty sure the origonal poster knows what he can and can't realistically do.
EDIT2: Anyway, I know near to nothing about coding, so I just got other people to code my games for me. Just find an experienced, enthusiastic coder (what there are a lot of on these forums) and you are all set to get creative, discussing your ideas with your coder as the project moves along.
I've got 15 years of coding experience, but there is no way that I could come close to developing something that matches even a modest commercial game. I just don't have the experience in that type of coding, nor do I have the artistic skills, or the time required.
If I was planning to make a game, I would have to start researching games libraries, then I would have to find one that matches my vision (and technical requirements), and begin learning to use it. In the end, I would expect my first few "games" to be silly-looking, near-unplayable tech demos.
Once the learning phase is out of the way, and I had an idea about what I can realistically achieve with my level of experience, then I could begin planning a real game.
It's like anything else. When you are learning guitar, you don't say: "Jimi Hendrix played Purple Haze, so it must be possible... I'm going to learn that first!". You set that as a goal, then start learning your way around a guitar. The first "songs" you play will be unimpressive and trivial, but they are just steps towards the final goal.
Lofty ambitions can be a good thing, but they will just cause frustration when the plans for an elaborate 3D FPS RPG come undone when you realise that the only library you can manage to use is a simple 2D sprite-based one.
Yeah, sorry, I should of mentioned that I didn't expect the guy to want to put this on an Xbox or something, obviously it is going to be something, that at most should be playable on a GBA if he wants to do it on his own and expects to finish it within reasonable time limits.
I agree with what you are saying and appreciate that you have a lot of experience in this feild, but in my eyes if you have a great, well thought idea you could make it with even the simplest of tools if you thought outside the box a little. Let's say someone has the idea to make a game called 'Oblivion' where the player has a massive area to explore, many people to interact with, lots of quests and equipment to aqquire, etc. This could even be done in a text adventure as many writers have created entire universes with just text. A 'choose your own adventure' book even, the book would be as thick as a manual to working a nuclear reactor if Oblivion was transfered into text but I'd bet it could be done.
I may be completley wrong on this subject and Malor may be 100% correct, but I believe if you have a good enough idea and can get pretty creative you could transfer your game to work with many different coding tools and mediums, just choose the one that suits your game the best. Just to make it clear, I'm not arguing with Malor on this one just expressing my opinions on the design process.
That's actually a very good point, and I think that Raslin should keep on working on his idea. It will be realisable in some form or another... even without heavy-duty coding. For instance, Myst was originally created as nothing more than a Hypercard stack.
But while he is doing this, I would strongly encourage him to start mucking around with the technical side of things.
As do I, it's always handy to have some form of coding knowledge if you want to do a quick test of a game mechanic or see if a line of code will work, and as said before, you may have something you can code the entire game in yourself.
You might want to read some of that first.
Ninjas VS Zombies never work well, even in a game as awesome as Ninja Gaiden
http://www.the-nextlevel.com/reviews/xbox/ninja-gaiden/ninja-gaiden-4.jpg
They were just not fun to fight
I think you ought to lay out, very specifically, what technologies you hope to develop this game with, what positions your dev team will need, who is filling those positions and especially what your responsibilities will be.
I'm a little late to this whole conversation, so if I missed that part, maybe you should edit it into the OP with big, bold letters.
or
Robot Zombies vs Pirate Ninjas?
What?
Now, I want to learn to program. I taught myself to model, and I'm much more of a logical person than an artistic one. I don't know where I should start, with what languages I should begin.
Now, I know my first project isn't going to be omg blockbuster. I will probably try to make a lot of small tech demo's in a way. Trying to get a running gameworld, thats all but barren except for a ground. Then trying to plop down statics. Then a sky, etc. One step at a time, obviously.
I've not been commenting on each suggestion, but I do like some of what I've read, and everything just spawns new ideas in my head, so keep them coming, even if I dont directly respond!
3ds friend code: 2981-6032-4118
Learn C++ and use SDL or IrrLicht. Or learn Python and use PyGame. Seriously, for a first project, go with 2D and learn how to use the engine.
Or just use an existing game engine like Quake 3 (which is open source now) and make the game using that.
I love the SDL and PyGame libraries, and I'm using Irrlicht right now, even though I'm not totally thrilled with it. However, C++ is one of the most difficult programming languages to learn. Python and PyGame are a hell of a lot less work to use, but I'll go one better and suggest C# and XNA. The only problem is that there aren't many free tutorials floating around for XNA.
As for using the Q3 engine, how easy is it to mod into an RPG? I've never peeked into its inner-workings, but I imagine it's not a place suitable for a beginner to learn C (Or did they move up to C++ for Q3? Either way, I wouldn't know how easy it is to mod).
Quake 3 is C and C++. Mostly C++. And converting it to anything other than a FPS will require work, but you could get a basic RPG out of it in less than a months time if you know what you're doing.
3ds friend code: 2981-6032-4118
Actually, it sort of is.
A lot of people just can't grasp the basic concept of coding. If you can understand what all the sections of that "Hello, World!" program do, you are well on your way.
The first big hump is learning the basic concept that you must be exact in your syntax. I see so many beginners just writing something vaguely resembling code, and expecting the compiler/interpreter to understand it. After all, that is how natural language works, and even things like HTML are forgiving. Compilers generally aren't.
Once you learn "Hello, World!", basic control statements, and iteration, then you have all the essential tools you need. You will spend the rest of your life perfecting this skill, but it's amazing how much you can do just by learning the basic syntax, and a handful of functions.
Don't expect to be the next John Carmack any time soon, but you will amaze yourself with how much you can do with a little knowledge. Especially with the help of modern IDEs.
Yeah, I actually feel fairly comfortable with it. I know a tiny bit of html, and scripting for bf1942, and what you do with the language just seems to make sense. As opposed to my regular nature, I'm able to be exact in what I write, etc, in this language.
Its all pretty exciting.
3ds friend code: 2981-6032-4118
Now, before I go into my rant, I want to let you know that I'm not out to demean or crush the spirits of a budding programmer. I don't want to belittle the ideas that he has and wants to put to code.
I hope everyone can understand that I commend anyone for attempting create a game, be it a Tetris clone ore even Daikatana.
I am a manager for a semi-popular open-source game project called Q-gears. A bunch of programmers from all around the world help me in making this creation come true. Here is the thing that you have to understand....
Q-gears, in one form or another, has existed since 2001.
Think about that... For all we have, which is really nothing but a basic scene viewer, has existed in either planning discussion or as a reference document for the last SIX YEARS. The cool thing is as it has gained awareness, the resources to crate the engine system has exponentially grown. It actually hit a kind of "critical mass" about six months ago and the whole project exploded on me.
Now, I'm not a very good programmer. I have actually held a position as an application developer four years ago and burnt out after a half a year. After that, I never even touched a line of code until Q-gears went "critical" six months ago. I know only three languages, C, Ruby, and the special scripting language used in Final Fantasy 7 itself. I also have peripheral knowledge of SQL, but that doesn't help much as it's a database technology.
I have also played with six console development kits. GB, GBA, NES, PS1, PS2, and PSP. Now I never really got much done with them, but it was cool to learn how each system worked. I preface all of this because I want to tell a story.
When I bought the PS2 Linux SDK from Sony, I popped into the local Software Etc, and showed off some of the cool official docs that came with it. When a customer overheard that I could "program a Playstation 2", he immediately inundated me with this "really cool idea" that he had for a video game. I listened for a while, and I realized that this guy had, in effect, absolutely nothing.
When I asked if he had bothered to write any of it down, he admitted that it was all "just an idea"
Well, guess what... Ideas are like assholes; everyone's got them and they all stink.
I had this idea too. I thought it would be cool to make an Final Fantasy 7 engine, However, a few years ago I decided to write this shit down. The reference for Q-gears now stands at 211 pages long. You will notice that ideas become a whole hell of a lot more viable when it actually exists as something.
Here's my advice. Go to Barnes & Noble, and pick up two books.
The first would be a book to teach you C. You need to learn to talk to a computer if you want it to do stuff for you. I pick C because of two reasons. First, because it's older than shit and you can always find a compiler for most computers/consoles/operating systems. Second, it's a perfect balance between machine code and higher abstractions to help you not only understand how to code, but how computers work in general.
The second book is one of those bound diaries. You know, those books with the hard cover and all the blank lines inside for writing. Now, what you do is you take a little time to learn C, and while you are learning, if an idea strikes you, write that shit down in the bound book. Don't be afraid to scribble out whole pages. (I put an X through mine, as sometimes I might want to re-investigate "dumb" ideas I had in the past. You might still want to read what's on the page)
And for the love of God, don't try and learn C#, or Visual Basic first. I actually have a standing rule for my project that once you mention these technologies, your validity as a programmer comes into question. VB is just a scripting language. (I know, it's not, but it sure as hell behaves like one), and C# is really just VB's idiot brother that does the same thing. You need to learn a *real* language. One that talks with different systems. You need to understand how computers work if you want to rally learn how to code.
One of the things I run into all the time, especially as Q-gears gains visibility, is I have a huge influx of newbies who ask to help. When I ask if they know any languages, they tell me that they don't really know how to program.
That person would be worthless to me.
What's worse are the ones who tell me they hate programming. That's great, you loathe a discipline that I not only enjoy, but want to give to the world. Can you tell me what's wrong with that?
That's my rant. Take it as you will.