Hey guys,
I have a question for all you experience game developers. If you aren’t an actual game dev but would like to post, go for it.
Without further ado.
Me and about 6 other people have gotten together go ahead and make a game. We have all the necessary people for the job. We’ve discussed what makes a game good and what doesn’t. What really grabs us by the balls and makes us squirm, so we have a general idea of the direction we want to go.
The goal is to make a point and click mystery horror/psychological thriller. Kind of like Scratches; If you haven’t played Scratches, then shame on you!
So as we’re all so newbish and have no formal education for when it comes to designing a game, how would we start?
Here’s what we’re going to try and do: Discuss story ideas. Block out a single room so we can test out several game mechanics. Such as picking up items, opening and closing doors, journal entries etc. This will help us get used to the engine we will be using (Dagon).
Once we’ve got an idea of how to code it all and design, we’d go ahead with all the modelling. After the modelling, music and sfx will be created.
This is as far as we’ve got with ideas. Are we on the right track? Are we missing something very important?
I’m happy to discuss many different methods when it comes to games design. Cheers.
Replies
It won't matter what you work on, it's just about sticking to it and pushing through all the years of shit, no matter what.
Anyway, for a theme or what game to start on, I'd say poke around the team and find what really gets everyone going. I wouldn't set what you are doing hard in stone yet, just find out everyones personal interests and merge it all into something that the team will love to apply to individually.
Check out this series.
http://penny-arcade.com/patv/show/extra-credits
Also, lastly, why would I want to buy your game?
That's the most important thing of all.
Why would I go out of my way and put down several of my work hours' pay down on it?
How is it ambitious, or intriguing?
General LD pipelines? or full on "how do we organize anything? ('Idea --> Game') Team management, milestone planning, entire dev pipeline & workflows... etc blah blah" lol.
Getting a working prototype test room straight up is a good idea, you'l get a good knowledge of what you can n can't do, obstacles to overcome etc from the outset instead of half way down the line running into a shit storm haha.
If you elaborate & specify abit more and or even make your project open development I'm sure you'l receive an extreme wealth of useful info from us polycount peeps.
Point n Click FTW!
For adventure games it's kind of hard, because it's difficult to pinpoint what makes adventure games "fun". Story? Humour? Art? Puzzles? What is the gameplay really? Is an adventure game an example of a genre that actually doesn't have much in terms of gameplay, but whose other elements are strong enough to mask that? I've heard claims that one of the reasons adventure games as a genre kind of died out after being super popular decades ago was because people couldn't answer that question satisfactorily... but it'd still be wise to make something really basic, and show some people, get some feedback, and see if it's worth doing.
It'd be a terrible thing to work on a game for months with several people in your team (and thus be spending a few man-years on it), only to find later on that it just wasn't fun to start with anyway. And that the only thing it would've been good for was a learning experience... which is nice and all, but a bit of a shame if you could have used that time to make a handful of good games.
If you're set on the adventure thing, here's something relevant, from Mr. Ron Gilbert:
http://grumpygamer.com/2152210
--
edit:
Also, it's generally recommended (among smaller indie/student teams anyway) not to do a hardcore game design doc (if any), and not to do a lot of that kind of planning until you've got basic prototypes that are successful.
So basically, you take your programming team, and split them up, and they each make a *super basic* version of a game mechanic on their own, and just see if it's fun. After a week or so, you get back together and compare results. That way, you're kind of "shotgunning" ideas out there, and trying a few different things, and can pick the best one, or a combination of the successful things.
Meanwhile, the art team can be gathering reference images, doing sketches, creating mood and colour boards, painting concept art, etc. Again, lots of "cheap" attempts at stuff so you can try a lot of different looks and discuss and discard as you wish, gradually refining things until your team's happy with the style/world/etc.
Ditto writers, audio, etc. Lots of early, fast iteration, with low time-commitment, so you can discard the stuff that doesn't work, and keep the gems.
After a couple of weeks of this, your team will have a much better feel of what you're going for, and a much better idea of the scope of the game, the aesthetic, whether it's fun without the art/sound/story/whatever and the gameplay is sound. You're then in a MUCH better position to plan what you'll do with the rest of the game, given your time constraints/budget. And all it cost was a couple of weeks.
Again, this is to prevent wasting a lot of time making something only to find months later it wasn't really so great.
http://www.gamasutra.com/view/feature/2438/how_to_prototype_a_game_in_under_7_.php
work in an iterative process when prototyping, meaning work organically and try out new things/dont have a rigid plan and force that plan to happen. keep yourself and your creative effort on its toes
But one thing does come to mind, who chooses what game plays like, looks like, feels like ect.
I ask because one team i worked with, out of some dudes house took a turn to worse when an overly opinionated (but nice dude) borderline bullied most of us into choosing ideas that he himself thought strongly about, if he didn't like something, he would let you know without hesitation where as it should of been unanimous.
What i probably got out of the experience though, was to sit down with everyone and brain storm, don't move on until everyone is relatively happy with the game on paper so you don't half way into development start copping guff from someone who despises anything that's not his own original thought.