A idea for a Tactical FPS Thread

That is a story idea, not a game idea. Why not just write a book?

Edited by: ANumberSquared

Squared55 wrote: That is a story idea, not a game idea. Why not just write a book?

Cause I figured a game would be more rewarding, and ever game has a story to it.

Zeinbrad wrote: Cause I figured a game would be more rewarding, and ever game has a story to it.

Mario Kart's story is amazing, right?

OK, dead serious now:

You're (almost certainly) not going to get anyone to help you. You're what we call an "ideas guy" - someone with nothing but ideas. No money, no skills, etc. We ALL have ideas. We like our ideas, and frankly, we want to work on our ideas much more than yours. You need to make yourself worthwhile to have on a team which means either you fund the game, or you learn to program or make art.

So, if you still want to get this game made, and you don't have any thousands to spend on it, I suggest downloading an engine (say, Unity or UDK), and looking up some beginner programming tutorials. Here's a good set for a Unity FPS: Youtube.com

Or, download Blender and GIMP and learn to make 3D models.

Or both.

Once you've gotten some skills under your belt, then you can join a team, or look for people to help fill in your skill gaps (For example, if you're a programmer you might want to find a composer and an artist.)

Edited by: ANumberSquared

*Dreams shattered*

I guess I'll get to getting Gimp and Blender I guess.I really want the Gaiaverse to get known. It's my dream for others to enjoy it like I do.

First to downloading Gimp.

Zeinbrad wrote: *Dreams shattered*

I guess I'll get to getting Gimp and Blender I guess.I really want the Gaiaverse to get known. It's my dream for others to enjoy it like I do.

First to downloading Gimp.

Gaiaverse. Break it down into two chunks and you get Gaia, and verse. In my langauge "Gaia" means Sh*t. I don't mean any made up langauge by the way, it's Samoan.

Edited by: thatotherdude1

Squared55 wrote:

Zeinbrad wrote: Cause I figured a game would be more rewarding, and ever game has a story to it.

Mario Kart's story is amazing, right?

OK, dead serious now:

You're (almost certainly) not going to get anyone to help you. You're what we call an "ideas guy" - someone with nothing but ideas. No money, no skills, etc. We ALL have ideas. We like our ideas, and frankly, we want to work on our ideas much more than yours. You need to make yourself worthwhile to have on a team which means either you fund the game, or you learn to program or make art.

So, if you still want to get this game made, and you don't have any thousands to spend on it, I suggest downloading an engine (say, Unity or UDK), and looking up some beginner programming tutorials. Here's a good set for a Unity FPS: Youtube.com

Or, download Blender and GIMP and learn to make 3D models.

Or both.

Once you've gotten some skills under your belt, then you can join a team, or look for people to help fill in your skill gaps (For example, if you're a programmer you might want to find a composer and an artist.)

Way to hit the nail on the head haha!

On behalf of the thread:

This "story" idea however does not seem original nor interesting.

Your lacking ideas for an idea guy you simply have an unoriginal idea with unoriginal gameplay concepts you cannot even conceive of how they are implemented.

If you want to write narrative do so! However if you want to make things like this interactive in a game space it would be wise to research more.

Edited by: ENP

This is a good example for what I was saying in another thread. We are so used to ecclecticism and the repetition of unoriginal story elements that we start thinking they are original. And we start using them ourselves.

This story sounds like Halo mixed with Natural Selection 2 gameplay. It's almost like people are afraid to have original ideas. For, if you continue down this track, what kind of game could this lead to? Designwise a Halo Clone, gameplay wise a generic space shooter with generic enemies; unless you want to spend a decade implementing unique features (Like NS2 did). Designwise they may even stand out, but the motivation for most alien species to attack others is often a bit... unclear. That's where a good story could begin, instead of "you are stranded on an alien asteroid and forgot your name".

Someone should make a (voluntary) parody of all those games instead. The tropes we see used in those types of Sci-Fi games are repeating and far, far from being original.

Anyway, have fun learning Blender, see you in some years ^^

Edited by: SinKing

Thanks for shattering my dreams further guys.

Yeah, I got the halo vibe when I made the Specters, and was thinking of this game. I was thinking of ways to set it apart. Thus I got the idea of a RTS/FPS mix. I also decided to make the Specters chosen from the best of the best in the human military, and they where founded in the middle of war not before.

Maybe it could be a RTS. I don't know.

Through, I mainly want to get to the big plot point. The Humans learning they are psychic . Basically Psionics but you gain it from accessing the Aether (Heaven) Nether (Hell) or Rending (Chaos hell hole that Hrova the god of sarcasm and chaos lives).

Also, I just got on blender....yeah, this will take me ages to learn.

I have a tip for you, research "risk mitigation." I'd like to elaborate, but I'm on my way home. I can give you some more details on why you'll need this alongside the 'eight filters' of game design, to better understand what it is you actually want and how to achieve it. For now though, I'll put it like this:

This is an idea. But ideas are not constrained by the the same factors that limit production. This in itself, makes it a huge risk to produce an idea, if you don't put down the production and technical details first. I suggest you read the book "The Art of Game Design" by Jesse Schell to understand all these fundamentals at a much closer level. Believe me when I'm saying that you're going to need them, if you want to turn ideas into actual games.

Regardless, I'll explain it all further and give you a better stepping stone for where you need to begin, when I get home. For now though, I hope this helps.
~ Dave

thatotherdude1 wrote:
Gaiaverse. Break it down into two chunks and you get Gaia, and verse. In my langauge "Gaia" means Sh*t. I don't mean any made up langauge by the way, it's Samoan.

Your insult bites back at you. Gaia is Latin for Earth and everybody is supposed to know that.

OP: If you want to see that game happen you had best learn how to make games yourself. And no, you can't just go and make your dream project, you need years and years of experience in game development to actually be able to pull off something like an original FPS game that isn't just weapon/map replacement for HL2.

Someone wrote: Your insult bites back at you. Gaia is Latin for Earth and everybody is supposed to know that.

Not sure why you think this is an insult. He was letting the OP know that he may be misinterpreted in some areas.

thatotherdude1 wrote:
Gaiaverse. Break it down into two chunks and you get Gaia, and verse. In my langauge "Gaia" means Sh*t. I don't mean any made up langauge by the way, it's Samoan.

That brings a whole new meaning to greek myths...

Even if your idea isn't original, Bioshock's original story was nothing original. As the game was being developed it changed in to what it is now. Infact, the most original thing about the finished product Is the story. The gameplay, weapon system, etc. are all "stolen" from System Shock. What makes that game so popular is the combination of story, gameplay, setting, weapons & the like. Almost every shooter, when stripped of it's top coat of frosting, is similar to Doom or Quake. What makes it unique is how it's all put together.

You just won't find anyone to help unless you promise the world or have a popular reputation. But that's life. There's nothing stopping you from doing this all as a Doom/Quake mod, if you wanted. That would eliminate most of the programming hurdles and you'd just need lots of assets and some coding tweaks. Hey, gotta learn sometime! :p

Oh great, I completely forgot to do a follow-up here, sorry. Anyway, let's take this from the bottom so you'll understand why you need to refine your concept, if you want any support for it.

When making a game, it always starts with the idea. Ideas are awesome. In many other branches of work, it is even said quite often that ideas are 90% of the work. That is not true in game development. As you are probably already aware of, making a game is an iterative process. Most people with even a remote interest in game development, know this phrase. But few of those - from the segment of people who are new to the process - know what is actually meant by that.

Let's first examine what 'iterative' means in itself. This will probably be quite obvious to you, but getting it down to black on white doesn't harm anyone. I quote wikipedia on this one:

"Iteration is the act of repeating a process with the aim of approaching a desired goal, target or result. Each repetition of the process is also called an "iteration", and the results of one iteration are used as the starting point for the next iteration"
- source here

It's an act of polishing, through the realization that specific parts need to be worked over. But wait a second, why am I even talking about this, when you are merely presenting an idea? Because, as I mentioned in my last post, iterations in game development are forced by the developers themselves. This is the process I call 'risk mitigation' and it is facing the hard facts of the constraints of production. This is the reason you almost never see a book being turned into a game, unless it's already been cooked down to a movie format.

So let's cut to the case. Fact is, most ideas get heavily bashed up during the risk mitigation process. Again, as I mentioned before, this is because ideas in themselves are not limited by the same constraints as the games that are in production. This means that an idea, if going unchecked in the idea-phase for too long, will cross some technical limitation borders that might very well end up making the game impossible to produce, were we to envision it as a real product.

To make sure this does not happen, we are forced to ask some very important questions, so that we stay real about what we can actually create, past just writing a story. But even before doing risk mitigation, your game also has to pass through 'the eight filters' to ensure that it is designed properly. Now, this is not actually an official method (because NOTHING in this branch of work is official, EVERYTHING is experimental). I can't overstate the fact that the game industry is still in its infant state and that there are most certainly other ways to go about doing this, but this is - in my opinion - one of the best ways to be sure.

What are 'the eight filters' exactly? They are essentially eight questions that you have to ask yourself, to make sure that your game is properly designed. It's like tests you need to pass, if you don't want to take huge risks in production. The eight filters method was invented by Jesse Schell, and are described in his book "The Art of Game Design." This means that I - for copyright reasons - can only post you the very short-form versions of these questions, but here's the list:

- Filter #1: Artistic Impulse: "Does this game feel right?"
- Filter #2: Demographics: "Will the intended audience like this game enough?"
- Filter #3: Experience Design: "Is this a well-designed game?"
- Filter #4: Innovation: "Is this game novel enough?"
- Filter #5: Business and Marketing: "Will this game sell?"
- Filter #6: Engineering: "Is it technically possible to build this game?"
- Filter #7: Social/Community: "Does this game meet our social and community goals?"
- Filter #8: Playtesting: "Do the playtesters enjoy this game enough?"

Now, these are all VERY cooked down (each one of these questions are individually described with some ten pages of text or so), so do NOT try to use them as actual guidelines. The reason I am posting them, is to give you a small idea of all the different constraints you will have to consider, when you need to figure out the viability of your idea as a product. The third and sixth questions are, in my opinion, the most defining questions, as well as considering budget constrains. This is due to the fact that they are both the most limiting and liberating factors simultaneously. Also note that this is a looping process. It is not a waterfall method where you take one step at a time, especially considering the design step - third filter - in contrast to the risk mitigation phase which I will now explain.

So wooh, finally, here's the one process that gets shit done. Risk mitigation is something that is extremely defining to your product, yet strangely enough, it is something that almost all designers who are new in the field, have never even heard of. This could be coincidental, but it may also be caused by the fact, that it is something many designers absolutely hate doing to their own design: Question the heck out of it.

You heard me right: Question your work constantly.

This is the process where you have to ask yourself, in detail, about every little detail that could go wrong. Then after you've outlined these questions, you ask yourself how you could possibly find a solution to them. The answer is simpler than it lets on. The keyword here, is prototyping. Yes, this is where prototyping stems from; answering questions asked through the risk mitigation process. A prototype is not just an early stage of an idea, it is an attempt to answer a question asked by the process of risk mitigation. To better understand what is meant by this, it is very helpful to look at a few examples. I can show you a couple from my own work, with suggested prototyping solutions. These questions all stem from some portfolio material that I am currently busy building:

- Will people like the characters?
To answer this question, there is no need to create a digital prototype. Instead, we will do portrait sketches and character summaries, which we will showcase to segments of our target audience to gauge reactions. These summaries will include interaction samples and background samples, which are also planned to be exposed to the players in the game. Remember, do not include anything that will not be accessible in the game, we are trying to find out how they'll react within the confines of our product after all.

- Will people feel immersed by our reactive audiovisual system?
To find out, we will need to create a prototype that is purely about going through a few set-piece environments with descriptive texts, to figure out how people react to the system's dynamics.

- Will the textures scale properly across resolutions?
To answer this question, we will need to create a prototype that dynamically alters texture properties, based on resolution input.

These are just a few (there are a lot more) of the most basic questions that have been asked. As you keep going, your questions will become more and more specific. But the point here is, that you can answer all these questions with 'quick and dirty' prototypes. This requires some mental practice - any person with a bit of self respect, will most likely begin polishing his or her work on their assigned prototypes - everyone from programmers to concept artists have this tendency. But it is a huge no-no at this stage. Prototypes are keys to locks to doors to rooms with answers with more locked doors. You don't bring your keys with you, they are one-time use to access your answers. Answers that collectively help clarify on where you are going, eventually making for a much more coherent experience.

To round things off, I want to add one last thing. This is something that a lot of people are struggling with, even up at the triple-A's:

Work is never finished, only abandoned.

What I mean by this, is that you can always do more work, when using these methods. There will always be more questions to ask. However, no one has an infinite budget, so you will instead be working to a certain satisfactory level. It is a very touchy-feely way to go about doing things, which is an odd contrast to how methodical I've told you to be up until now.

I hope this clarifies a bit more on the reality of what it is like to make games, rather than just writing stories and going "it will probably be this genre." And once again, sorry about the delayed reply, but I completely dozed off when I got home yesterday. But keep your head up high, we all have to start somewhere. I swear to you, nothing is more god damn satisfying than grasping these principles and applying them to your work. It gives you such an extreme level of control while simultaneously acting as a safety net, that beginning to use it is often the turning point for a lot of people, determining what kind of work they want to do for the rest of their lives *hint-hint*gamedesigners*hint*

Cheers,
~Dave

Edit: I completely forgot to round things off properly. The whole reason I started this gigantic post, was to say that doing risk mitigation and prototyping through it, is one of the best ways to learn and improve yourself. A lot of people feel lost when they need to go from just having ideas, to creating real content. But if you become good at asking questions like this, you will never run out of goals to work towards. "Find your mountain," as they say. Second point was, there are some designers out there who just do design. You're not going to start there unless you're very lucky, but it's something you can end up with eventually. However, you will have to master butt-loads of theory like this, if you want people to take you seriously. So the easiest way is - contrary to popular belief - to start out by supplementing your design-learning-journey with artwork and/or programming skills.

Edit Edit: Also, your game already exists. It's called X-com.

Edited by: Genero