Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
The ideas behind a game are half of the work to making the game; the problem with your ideas is that
Quizzical
Member LegendaryPosts: 25,545
Lots of people have ideas for games, including nearly all gamers and a lot of people who aren't gamers. Lots of gamers have ideas that they'd like to see made into a game. Those in the industry typically ignore those ideas as worthless, and rightly so.
But the situation isn't as bad as you think. If you've got the complete set of ideas to make a game, you're halfway there. The problem is that even if you've written a 50 page document detailing what your game will be like, you're probably not 1% of the way to having a complete set of ideas to make a game.
Making a game means you have to fill in the details. Suppose that you want your character to attack. Okay, how does he attack? If the player pressed a button to attack x milliseconds ago, then exactly where should every single vertex in the model be? We need a function of x, and we need it for every single vertex in the model. Oh, you did specify exactly which vertices were in your character model, didn't you? And what data a "vertex" consists of (position, texture coordinates, normal vectors, etc.)? And what color every single pixel in every single texture that your character uses should be. And what happens to the normal vectors as your character moves around.
Exactly how far away can a mob be and get hit? And exactly when do you check? How much damage does your attack do, as a function of your character's stats and gear, the mob's stats and gear, and whatever else you think damage ought to depend on? Speaking of which, what do you think that damage ought to depend on. And how do you determine server-side when the character decided to attack, anyway? We need explicit formulas for everything here. Just saying that the character should be able to attack is so vague as to be completely meaningless.
Every single dialogue line in the game is game ideas. Every single line of quest text is game ideas. Every single formula is game ideas. The geometry of every single model is game ideas. Every single texture is game ideas. You can't just wave your hands and say, there should be a bunch of textures along these lines. You have to fill in all of the details of exactly which color every pixel should be, in which resolution, and how to determine where in which texture you'll check for every single spot in every single model.
But all of that is only half of the work? Yes. The other half includes debugging, so that the game actually works the way your intended. It also includes optimizing performance, so that your game runs at 60 frames per second rather than 60 frames per hour. Sometimes the latter means realizing that you just can't make some of your ideas work acceptably, so you'll have to discard them and come up with new ways to fill in all of the details.
If you have all of the details, then making a computer program out of them isn't really that hard. You might think that you can't do it because you're not a programmer. If you genuinely can't do it, then the problem is almost surely that you can't fill in all of the details. Everyone wants to do the high level ideas, such as whether the game will be a theme park or a sandbox. Few want to fill in the minute details, which is the bulk of the work.
Comments
currently playing: DDO, AOC, WoT, P101
But it is. The indie scene is riddled with games made by solo "hero coders". Some of them are pretty good.
I skate to where the puck is going to be, not where it has been -Wayne Gretzky
+1 Quiz.
The broadstrokes are pretty much worthless. Thats why I've been working my pet projects from the details up. I'm only researching the tech until I get atleast most of the details right. Perhaps get a prototype running (even a paper prototype will do if possible).
I hear they require you to develop board games in schools where they teach game design. Which is great practice imo: They're quick and inexpensive to make.
I skate to where the puck is going to be, not where it has been -Wayne Gretzky
Out of curiousity : Wouldn't the formula's be part of the programming as opposed to an idea?
I understand the premise of your thread, I just think the definition of "idea" is loose. Certainly the position of " So you want your character to attack? How? How often? In what patterns/style? What determines the damage? etc etc are well within grounds for expanded ideas. I'm just not sure the forumla's ( vertices, etc as you spoke of) are more idea's or the way those idea's are realized.
Yes and no.
I'm not interesting in the IP or the polish or all those thousands of man-hours it takes to colour in the details. To me, a game lives or dies based on the database it's built on. Although I'll happily discuss any layer of a game, it's that grain of sand at the core of the ever-growing crystal that interests me the most.
This basically boils down to "Filling in the details is the hard part". I would hope that most people already understand this concept.
Back when I was in college I worked a job making pizza's for seven dollars an hour. There were no details to fill in. The ticket told us exactly what pizza to make, a chart told the pizza cutter exactly how many slices to cut into a large pizza. That's why I only got paid seven dollars an hour. There were no details to fill in, you just do what the ticket tells you to do.
Now I work as a systems administrator for my company. I have dozens of servers and untold hundreds of clients spread across the world that fall partially under my responsiblity to maintain. Now I have to fill in details for a living. If one of my servers goes down, I can't just call someone up and say "Hey, tell me what to type to make this thing work again". I have to troubleshoot it myself and get it back to operational. Now my salary is commensurate with filling in the details for a living.
Anyone can make a pizza with a list of toppings, and containers of toppings in front of them. Not anyone can sit down at a syscontroller and figure out why several Dell R610's running Vsphere 5.1 and fibere'd in to a FA S2040 suddenly stopped populating database entries.
Details are king.
Well to be clear it's more like the act of describing the ideas (designing) is ~20% of the work, and there's the beauracratic layer of management, and there's the marketing budget, and then about 50/50 of what's left afterwards is Art vs. Development.
But certainly many of the ideas presented in forums don't fit within any sane business model. The most common mistake being creating games that only a super tiny niche are interested in, yet expecting them to be expensive-to-make MMORPGs and not tiny little indie projects (projects the same size as the idea's appeal.)
"What is truly revealing is his implication that believing something to be true is the same as it being true. [continue]" -John Oliver
Sysadmins aren't kings, they're captains of the guard.
I don't know... I find getting into the detailed inner workings of a game is the best part.
Some people just are not ready to think at that level but that's ok. They aren't designers.
I think this is a great take-home: Know your target market/demograhic/niche for whatever game idea you have.
http://www.gdcvault.com/play/1014633/Classic-Game-Postmortem
Starting with a target demographic is going to result in an excellent marketting campaign. If a game accidentally ends up getting designed somewhere in there, it's a bonus.
That's still the easy part. Implementing it is the hard part.
There isn't a "right" or "wrong" way to play, if you want to use a screwdriver to put nails into wood, have at it, simply don't complain when the guy next to you with the hammer is doing it much better and easier. - Allein
"Graphics are often supplied by Engines that (some) MMORPG's are built in" - Spuffyre
I have a opposite view of Quiz.
I countless times I have predicted what major problems major hyped up MMOs would have, based on design decisions alone.
my opinion the success of a MMO comes more from design.
You can make the most bug free MMO ever imagined. But if the game design is poor, it's also a poor game. No matter how well it was coded.
Philosophy of MMO Game Design
You mean, you're against Lokto and with Quiz, right?
I skate to where the puck is going to be, not where it has been -Wayne Gretzky
That's debating semantics, really. Though I suppose the title of this thread is in part my view of it.
If you have a formula in mind, then implementing it in a computer program probably isn't that hard unless your formula is something pathological that computers just aren't good at. The hard part is coming up with a good formula--which is the essence of deciding how you want the game to work.
Which is harder depends on what you're trying to do and what you're good at.
There is a big difference between making a game that works and making a game that works and is actually good. This thread doesn't really address the latter.
In many cases, there are trade-offs in game design. There isn't one magic solution that makes everything work perfectly. You can have this problem or that one, but you can't simultaneously avoid both.
To some degree, yes.
Some ideas could be readily grafted into a lot of different games, though, without requiring the entire game to be built around that one idea.
Obviously you have never ever written anything in an OOP Language. You never worked with the sourcecode of a real game engine like UDK, CryEngine or Torque3D. You have no clue how netcode is written and latency compensation is managed in huge multiplayer servers.
This has nothing to do with ideas. It's purely technical and mathematical issues that need to be solved. Tools need to be developed from scratch, asset pipelines need to be created, plugins need to be programmed for the tools you use. Bugtracking, revision control, automatic builds need to be in place.
You are living in a dream world buddy.
Actually, no. When I say implementing it is harder it is not about the coding prowess needed but about how every theory has its holes once real life steps in, and it isn't really until the ideas are executed and being used by players in these persistent worlds that one can usually tell the true impact or even value of them.
It's one thing to write all sorts of scribble about deep and immersive and social and whatever other horseshit may look good on paper. It's another thing to put together the details on it.
Far beyond those steps is implementing it so that it
There isn't a "right" or "wrong" way to play, if you want to use a screwdriver to put nails into wood, have at it, simply don't complain when the guy next to you with the hammer is doing it much better and easier. - Allein
"Graphics are often supplied by Engines that (some) MMORPG's are built in" - Spuffyre
For many, many cases, you're correct, for precisely the reasons you state.
But if you're trying to make something really simple that only has one system, it doesn't need to integrate with a bunch of other systems.
I once made a simple tic-tac-toe game. The hardest part was figuring out exactly how the AI ought to behave in every possible circumstance.
MMOs are not really simple.
But if we're going to talk at all, if we're going to have any fun as armchair designers, we have to make a few conceits.
To me, the most interesting question is where to start. What is a person's one-page starting point for a game? Do they start with the IP and work down? Do they start with an existing engine and work up? Do they start with a database model then leave the engine and IP as details to be filled in later?
It would be interesting to me to know, for established games out there, what was the real starting point from which the game grew (or was there even a single starting point - or did each person in the initial team actually already have some partially developered ideas in their area of expertese that were then combined to form a single project?).Talk is cheap, in other words.
Self-pity imprisons us in the walls of our own self-absorption. The whole world shrinks down to the size of our problem, and the more we dwell on it, the smaller we are and the larger the problem seems to grow.
I see this problem in a variety of industries. People love to consolidate roles to save time and money. But that is actually a large part of the problem. Once in a while, you will find someone who has a technically oriented mind AND is creative and abstract. That's just a really difficult combination of thought process to find in a single person.
Very creative people don't necessarily have the technical skills, nor do they have the capacity to gain those technical skills. But they are rarely invited to the table when it comes to things like game design. Look at almost any job description involving some type of lead world or character design and you'll see that they always want people who also understand the technical side.
Of course, we (the players) see the result of this limitation . . . meaning, look around at what's being done. We often credit those decisions with investor influence, but there's a clear fear of waste in hiring someone who isn't also doing the tech work. And we get lots of stagnation, lots of mimicry, and very slow design changes.
OP's post demonstrates this, he wants someone to not only come up with the idea, but also to think about every technical detail.
Some companies have hired psychologists and economists to help them figure out certain aspects, unfortunately psychologists have been used to determine how to keep people grinding rather than how to improve fun.