Where do you start with a project?

[silverpower]

I'm working on a semi-realistic FPS/RPG hybrid at the moment, and at the moment, I have no assets. I've prototyped this on a few other engines (mostly Valve's Source engine and GSC's X-Ray), and there I not only had pre-existing assets, AI packages, and suchlike, but I could easily drop in more from various sources of mods (and in the case of Source, CSS skin sites).

I have a rough idea of what feature set I want, but even with UTGame, I get the impression that I will be starting from scratch, because none of the packaged weapons are really suitable for this sort of mod (all three have a gratuitously sci-fi look, two are energy weapons and one is a fully-portable multi-rocket launcher).

So what's first priority? I'm not sure anybody's going to sign on on the strength of a half-complete design doc and a coder who's never worked with UnrealScript before (but has *some* programming experience). Where can I get assets to drop in? *Is* there anything to drop in for my prototype?

[UnspoiledWalnut]

Prototype it more using basic models until you have what you want. Assets are relatively easy to change out, just use low poly models (I've been using boxes a lot recently) to represent weapons and characters and vehicles and buildings.

GDD's are useless, they change all the time and I doubt anyone that is on the team is going to bother reading through all of it every time it changes. I don't see why you need to have final weapons for the prototype, unless you require a visualization to see what it's going to look like for some reason, instead of being able to figure it mentally based on the scripting and testing of non-final assets. If you can't model or buy new assets, you're kinda screwed in that respect unless you find someone else for the team.

[Orang3boy]

Prototype it more using basic models until you have what you want. Assets are relatively easy to change out, just use low poly models (I've been using boxes a lot recently) to represent weapons and characters and vehicles and buildings.

GDD's are useless, they change all the time and I doubt anyone that is on the team is going to bother reading through all of it every time it changes. I don't see why you need to have final weapons for the prototype, unless you require a visualization to see what it's going to look like for some reason, instead of being able to figure it mentally based on the scripting and testing of non-final assets. If you can't model or buy new assets, you're kinda screwed in that respect unless you find someone else for the team.

Totally agree.

Start with the simple, write a few lines about what is going on, few sketches to have a idea of the environment and weapons or look for it in internet.

Made a rough bsp prototype of the first level with some cubes and basic shapes representing the stuff (I normally take few screnshots and add annotations on it when the ideas emerge), add the enemies with simple skeletal meshes, kismet for the doors, etc,...

You only need to make it functional, after that, if all works well and you're happy with the result, you can start the real work.

[UnspoiledWalnut]

I have blocks about the size that the final buildings will be (the one I'm working on is a bit easier because I can use some real world data, although right now I need to guess a bit since there's no maps from the 1700's that are of great detail) and everything like that.

If it works with the blocks it's gonna work with the final models. Everything I can, I've been using Kismet for because I might hate it. I actually think the blocks look kinda neat, personally. Then keep a little diary, write down what doesn't work or annotate screenshots like Orangeboy (I keep a wall of post it notes; Yellow is US History, Green is the MMO, Blue is the unannounced project that I no longer like, and White is Empire City. Pink is whatever I think of that I feel needs to be pink. If I write in red pen that means not very important, blue means more important but not so much, black is normal, a gel pen is above normal [although they appear to be looking more and more like normal ink, which was an unexpected turn of events], and a glitter pen is really important. If it's above that I take the time to find a real piece of paper or a sharpie and I earned myself a cigarette from my gratuitous, albeit unknowing, roommate [he found out somewhere that sells clove cigarettes still and won't tell me]. Or mom if I happen to be at my parents house.)

DO NOT annotate pages of a book you're reading because you'll never find them again, especially if you do it routinely.

Also, keep in mind that if you happen to get good ideas in the shower, keep a mirror handy and pop a picture of that mirror after you draw your concept on it. For instance, Truman Burbank drew a very good alien in the mirror which possibly inspired many scifi writers. Way to go, Truman. Or you can use paint, which I don't know how to use, but I understand that people happen to figure it out every day.

[elmuerte]

You don't create mods with the UDK. It's a game engine, it's expected that you create all the stuff yourself or license stuff created by others which they offer for licensing (either free or paid).

[MonsOlympus]

I recommend a design document, as UnspoiledWalnut says they change but I find the best method is to revist your design document peridoically during prototyping to add adjustments. Ofcoarse things can move at such a pace things get overlooked, the design document in full is more of a guide to keep everyone on the same page, it'll include not only technical supplements (along with technical brief) but tasklists. Some people might not call this part of the design document but I believe designing a design in itself is design (if that makes any sense, Im referring to concept and flow). Keep in mind however this is the way I work.

As an example of where I started, I'll reference my wiki page for project silky. This is the most current iterations and if you browse the file history you will see where I started to where I am now, this is by no means a priority project more of an incubator since its a one man show part time.

I always start, with the idea, from there its gameplay before all else, conceptualizing happens during prototyping. From there its onto all the real grunt work to get it looking like an actual game with all the purty assets, effects and whatnot.

Edit: Oh one thing keeping a ruff game design document will help you do is write up a nice pretty brief to give to the suits if you need to

[UnspoiledWalnut]

And it's still useless.

[MonsOlympus]

Actually no, without it I couldnt have demonstrated where I start and answered this thread

[UnspoiledWalnut]

And without one I demonstrated that it's not necessary in answering this thread.

[Phopojijo]

Yeah... Mons knows quite a bit about game and mod development.

Though I think that "game design document" these days really should be more like "game design wiki".

Don't toss your heart and soul into the documentation and neglect the work, of course not, but it's at least good for a room-full-of-whiteboards compliment/replacement.

[Makaze]

Writing up a full fledged game design document before doing any prototyping is ridiculous. Not doing any planning or recording any ideas before starting is equally ridiculous. Sure both of them can and have worked but generally the best approach is somewhere in the middle.

[UnspoiledWalnut]

You just need an outline of ideas, not a GDD.

[MonsOlympus]

All Im saying right is dont give the misconception you can jump in and start with a prototype without having a solid foundation for what youre trying to make. The original idea should be like putty, you should be able to bend and mold it but the idea is not to break it. Once you start doing that you'll go through design hell and get stuck adding features your game doesnt really need. Its for this reason I always start with more then an outline, ofcoarse you dont need to list weapon damage = such and such because simply that information is just duplicated, you do however need some kind of relational idea before you prototype, rockets will do more damage then grenades as an example.

Just think if you have a larger team, you cant hand them all scans of your notebook and say this is what we are doing today. You'll need to hand them updates pages for a game design document since that is the designers (and their assistants) job no one elses. Most of the time with mod projects (which I have most experience with) people will fill multiple rolls like lead programmer/designer which allows you to side step some of the formality.

I agree with Makaze you need some kind of plan of attack, outline of ideas (which can be expanded) I consider this to be the birth of a game design document. There isnt standard for game design documents, they are how you make them and you'll discover what works best for you as you work on them more and more (which is why there arnt many "writing a game design document" more templates). Basically, start with a pen, move onto the keyboard, mix in some pencil at either of these stages or both, move onto the mouse.

[Solid Snake]

Looks like blanket statements are being thrown around a lot.

A game design document is a form of communication. Communication becomes increasingly harder when more people are added to help develop a game. Remember that it doesn't increase linearly, it increases exponentially (2 people have 1 communication pipeline, 3 people need 3 communication pipelines, 4 people need 6 communication pipelines, 5 people need 10 communication pipelines). So if you're in a large team as is most commercial companies, then a singular design document is important as everyone references this document to know what they need to do.

Secondly, a game design document can help with finances and production. It helps with finances because you know how much time (on a rough estimate) needs to be invested into the game, you know how much assets is required and you know what skills you need to hire to fill in the skill gaps you or your team has. In terms of production, it helps because you know what you are making overall, and what things need to be made to achieve playable milestones.

However, if the scale of your operations change then a game design document may or may not be needed.

If you don't have to manage a large team, or you don't need to control finances then having this very broad over arching document isn't necessary.

I feel the best thing to do, to start any project is to simply research. Not necessarily research what you need to get things done, but research to understand what already exists out there. Most people get stuck with starting projects because they don't know enough to begin with.

If you wanted to write a book in a foreign language that you don't know, you don't begin by coming up with the story. You begin by learning the language.

[Blade[UG]]

You may be able to get your ideas out into an outline, and you'll know what you're doing, but everyone else will be all "wtf?" .. i mean, if you are putting together a prototype yourself, great, but you really should have a detailed design, at least in the works, if you're trying to attract other people.