What's the workflow for creating a game?

[XXWeaponXX7]

Right now, I'm working on a basic multiplayer game, but I want to know where to start from a blank project.

It can't be as easy as "put a level together, done". There has to be a script of sorts that can select levels, or set up Multiplayer, in a "Main Menu" of sorts, if I remember correctly.

Essentially, how does one begin a game? Where do I start?

[reevezy]

Everyone has different methods, for me I just find something I'm interested in and work on it,
I end up branching off onto stuff without even having to think about it.

Maybe you want to start just by making a few weapons or something to get you motivated and then move onto some core components such as gamemode/s.

[reevezy]

-snip- Sorry double post.

[XilenceX]

Well I start a blank project with research & a game design document. However I guess this wasn't the answer you were looking for so just make yourself a list of everything the game would need. Then start creating things and crossing them off the list. Creating your own main menue and a level select screen in it would probably be quite far on top of that list for a multiplayer game.

[XXWeaponXX7]

Honestly? There's no specific workflow?

Thanks, all!

[nabiul]

The same as any other kind of project, you sit down and come up with a prototype plan/design and set project milestones and goals. The design is iterated in cycles until you reach the project goals. In between each iteration you have the different parts of your team doing their job.

You need the following people:
Project lead/manager
Concept artist
Writer
3D modeler
3D rigger and animator
texture artist
Level designer
Programmer
Materials and effects artist
UI designer
Sound engineer
Composer
voice actors
marketing and PR person

The workflow is not linear, you have several different branches working simultaneously, starting with the writer and concept artist. Once you have a story and concept that is chosen, the modeler begins making useable characters for play, the level designer starts blocking out the levels and the programmer starts implementing gameplay elements. The levels are tested for basic core gameplay, when that is set, the art team starts creating models, sounds and effects to decorate the level with.The UI designer can start working alongside on the various menus and flash/scaleform related stuff. When the art passes are completed on the levels and the game is playable, it has reached alpha stage and the composer can begin writing the music to fit the gameplay. Everything is put together and tweaked in more art/programming/level design passes through the beta stage until you are ready to ship the game and it becomes gold. Somewhere in the middle, after the alpha stage, your marketing and PR people start creating public interest for the game and work on securing distribution channels.

[Mougli]

The same as any other kind of project, you sit down and come up with a prototype plan/design and set project milestones and goals. The design is iterated in cycles until you reach the project goals. In between each iteration you have the different parts of your team doing their job.

You need the following people:
Project lead/manager
Concept artist
Writer
3D modeler
3D rigger and animator
texture artist
Level designer
Programmer
Materials and effects artist
UI designer
Sound engineer
Composer
voice actors
marketing and PR person

The workflow is not linear, you have several different branches working simultaneously, starting with the writer and concept artist. Once you have a story and concept that is chosen, the modeler begins making useable characters for play, the level designer starts blocking out the levels and the programmer starts implementing gameplay elements. The levels are tested for basic core gameplay, when that is set, the art team starts creating models, sounds and effects to decorate the level with.The UI designer can start working alongside on the various menus and flash/scaleform related stuff. When the art passes are completed on the levels and the game is playable, it has reached alpha stage and the composer can begin writing the music to fit the gameplay. Everything is put together and tweaked in more art/programming/level design passes through the beta stage until you are ready to ship the game and it becomes gold. Somewhere in the middle, after the alpha stage, your marketing and PR people start creating public interest for the game and work on securing distribution channels.

No, you don't NEED all these people. Or to be more accurate, you don't need a different person fulfilling each and every one of these roles. Also, your list is kind missing an important role: the game designer. I think the OP is talking about making a game on his own.

My advice is that you first get an idea of what you want the players to experience in your game. Then you'll have to decide what are the game mechanics (how the player can move, how each of the player's abilities work, etc.).

Then, you'll have to prototype each mechanic. Keeping it focussed and self contained to keep the motivation up. Before you've made sure your mechanics are fun, there's little point in spending time modelling, animating or writing a story.

[Archerx]

As a solo dev my process is this.

- Get multiple ideas
- "Crunch" or visualize them in my head and choose the best one
- Do a simple gameplay prototype to see if it is feasable
- Design on paper, I guess I make an evolving game doc, plan the features, what the game is supposed to accomplish, the rules, the levels, etc
- Start building the visual assets
- Build the game as I build the assets
- Rinse and repeat untill you think you're done
- Sounds and Music
- Polish
- Beta test
- Use feedback to make changes and do a final bug squash
- Submit to App Store

[FragWeapon]

I work in a team of just two, one programmer, and one kind of do it all. I think what is important is keeping each other, or yourself motivated. You need to find ways of motivating, because everyone is different. Perhaps making a multiplayer level that you can't even play in will motivate you to want to create the game to play in it, perhaps the opposite. There are some sort of "standard" work flows that I'd say most follow, you're going to want to have some sort of written and visual representation of what you want your game to actually be, of course you can cut corners on this if you're working entirely on your own, if you're working in a team you need to make sure you're all on the same page.

Another tip is looking at what is given to you all ready with UDK, can you use elements of the UT demo (code wise)? For example, lets say you're creating a first person shooter, well...you've already got a huge head start, perhaps you should focus more on art at first. Maybe you're going to be making a top down space shooter, well believe it or not it's still very similar to the UT demo, creating a new camera class will pretty much completely change the gameplay, but still use a lot of the code.


This is what my team of two has done so far in order AND THEN REPEAT to REVISE until we get what we want (and it's working so far, we're in-house alpha now):

- We worked out a quick written document of what we want our game to be

- We began creating the mechanics, and quickly made a prototype map to test them in. For this stage, I think it's very important you always have the mindset of "I will need to modify this section later". So make sure you always start off doing "barebones" for your game first, and then you can expand off it in little places here and there. For example, we made a weapon that does everything we'll ever need our weapons to do. The weapon could fire instantHit (a sniper, for example), it could also fire projectiles. It could also zoom in and out, and we control this by setting a variable called "hasZoom" for example. So when we create another weapon and we want it to have a zoom feature, we just set that variable to true, and of course we also had zoom speed and zoom amount. We also made it so we could fire multiple projectiles or instantHits at once, we have a variable that turns that on/off, a variable that says how many shots are fired at once. So you can see the power of this method, we can have a Shotgun, we can have a sniper, we can have a shotgun/sniper (LOL!), we could have a rocket launcher that shoots multiple projectiles like a shotgun, but also has zoom. We also have a class system, which basically spawns you as a different pawn depending which class you choose, this pawn expands off our "master" pawn, and we change up variables like their speed and health, and the default weapon(s) they spawn with.

- Started making more weapons, using basic place holder models, this kept us motivated, we were actually at a stage all ready where we could go "wow, this is actually going to work".

- We started testing multiplayer early, making sure we're replicating all our variables. Always test multiplayer as you go, otherwise you might have to re-code half your stuff, you can test multiplayer by loading multiple clients on the same machine.

- Create a new model, sound and particle effect here and there (weapons, characters, not many map related assets... just pure gameplay stuff).



Well I hope that helps, creating a game isn't necessarily difficult if you are able to keep at it. It just takes a long long time, and yes you might lose sleep off it.

[tegleg]

i usually start with the game mechanics (script) and some placeholder art to get it working.
that way you can quickly find out if the game is fun to play or not and needs to be scrapped or not.
if its all seeming like a worthwhile idea to persue start tightening up the code, work out what technically needs to be done to make it into a game.
write down the main steps that need to be completed and work through them.
and at the same time try and improve/replace the models (if needed) and build the level (if its not generated at runtime)
the menu is usually the last thing i make unless its an integeral part of the game mechanics.

in other words, just mess about and see what comes out, and have fun with it.
good luck

[Neongho]

True , if the game play it's not finished yet , the meshes , anims you need are pretty uncertain, maybe only the sound.

[XXWeaponXX7]

"I work in a team of just two, one programmer, and one kind of do it all. I think what is important is keeping each other, or yourself motivated. You need to find ways of motivating, because everyone is different. Perhaps making a multiplayer level that you can't even play in will motivate you to want to create the game to play in it, perhaps the opposite. There are some sort of "standard" work flows that I'd say most follow, you're going to want to have some sort of written and visual representation of what you want your game to actually be, of course you can cut corners on this if you're working entirely on your own, if you're working in a team you need to make sure you're all on the same page.

Another tip is looking at what is given to you all ready with UDK, can you use elements of the UT demo (code wise)? For example, lets say you're creating a first person shooter, well...you've already got a huge head start, perhaps you should focus more on art at first. Maybe you're going to be making a top down space shooter, well believe it or not it's still very similar to the UT demo, creating a new camera class will pretty much completely change the gameplay, but still use a lot of the code.


This is what my team of two has done so far in order AND THEN REPEAT to REVISE until we get what we want (and it's working so far, we're in-house alpha now):

- We worked out a quick written document of what we want our game to be

- We began creating the mechanics, and quickly made a prototype map to test them in. For this stage, I think it's very important you always have the mindset of "I will need to modify this section later". So make sure you always start off doing "barebones" for your game first, and then you can expand off it in little places here and there. For example, we made a weapon that does everything we'll ever need our weapons to do. The weapon could fire instantHit (a sniper, for example), it could also fire projectiles. It could also zoom in and out, and we control this by setting a variable called "hasZoom" for example. So when we create another weapon and we want it to have a zoom feature, we just set that variable to true, and of course we also had zoom speed and zoom amount. We also made it so we could fire multiple projectiles or instantHits at once, we have a variable that turns that on/off, a variable that says how many shots are fired at once. So you can see the power of this method, we can have a Shotgun, we can have a sniper, we can have a shotgun/sniper (LOL!), we could have a rocket launcher that shoots multiple projectiles like a shotgun, but also has zoom. We also have a class system, which basically spawns you as a different pawn depending which class you choose, this pawn expands off our "master" pawn, and we change up variables like their speed and health, and the default weapon(s) they spawn with.

- Started making more weapons, using basic place holder models, this kept us motivated, we were actually at a stage all ready where we could go "wow, this is actually going to work".

- We started testing multiplayer early, making sure we're replicating all our variables. Always test multiplayer as you go, otherwise you might have to re-code half your stuff, you can test multiplayer by loading multiple clients on the same machine.

- Create a new model, sound and particle effect here and there (weapons, characters, not many map related assets... just pure gameplay stuff).



Well I hope that helps, creating a game isn't necessarily difficult if you are able to keep at it. It just takes a long long time, and yes you might lose sleep off it."

(I want to start off by saying that Mougli's right -- No team would take the time to ask a question on a public forum for their project.)

Well.

I'm extremely grateful you all taking the time to write out detailed responses to my question. I thought this was going to be as easy as linking me to a page I've been blind to all this time.

I want to start by saying, "Okay. I need to document exactly what I want, so that I have a reference for what I want to do as time goes on and as I search for what I want in the UDN Docs." That seems like something that I can do, and something that could greatly speed up what I want in my project. It's become apparent to me that when I code or look for things, that I don't always apply them to my ideas. Writing down my ideas in a document would greatly speed up whatever work I do. That's a wonderful suggestion and first step, and one that I'm surprised that I didn't see earlier.

Motivation was never a concern to me, until I opened up my first blank Visual Studio document, and stared into the white abyss. I never realized how hard making something was, and thought that it just wasn't something that I could do. Motivation is extremely important, and you've showed me that again. Continually showing yourself progress on your game, or testing it as you did with your "Master Weapon", was extremely interesting, and something I'm VERY interested in doing, if you're okay with that.

Your workflow makes sense. I's a good thing I did my research, since I, too, need to make sure variables replicate correctly. But what you do in the way of your game... is a wonderful thing. And it's easily going to be my model, even if you're a team of 2, and I'm just one person.

(Sniper-Shotgun. I imagine you played around with that while you were testing your weapon balances.)

--

"No, you don't NEED all these people. Or to be more accurate, you don't need a different person fulfilling each and every one of these roles. Also, your list is kind missing an important role: the game designer. I think the OP is talking about making a game on his own.

My advice is that you first get an idea of what you want the players to experience in your game. Then you'll have to decide what are the game mechanics (how the player can move, how each of the player's abilities work, etc.).

Then, you'll have to prototype each mechanic. Keeping it focused and self contained to keep the motivation up. Before you've made sure your mechanics are fun, there's little point in spending time modelling, animating or writing a story."

I didn't think that you needed a separate person or group of people for every single role, especially for a small game. Your idea of writing down everything that I 'd like to put into my game is exactly what I plan on doing.

Focused and Self-contained. Got it. Motivation isn't going to be a problem, as I imagine, since you both are giving me wonderful advice to make me realize that I'm not going down an endless road. Game mechanics won't be too long, and coding them shouldn't be the biggest challenge in the world. I understand what you're saying there.

"Make sure your mechanics are fun, or there's little point in modelling, animating, or writing a story."

Understood. Mechanics shouldn't ever be just fun to the user, but fun to the audience, too.

--

As of right now, I'm going to create a document detailing everything I'd like to put into my project.

Next, I will try and make a working demonstration of every aspect of what I want in the game's mechanics and concepts.

I will then perfect and continually, fix those mechanics, and make them look better as time passes and as I work on the project.

And, finally, I will fix the project, cook the data, and that will be that. This will be done in time, of course, and I don't at all expect this to take a short amount of time. But I enjoy game dev, and it's going to be a wild ride.

--

On another note, I've been thinking of creating a main menu within a UDK level, and to have scripts edit the gametype settings and to load levels, change settings, and exit the application. How feasible is this? Is this common?

EDIT -- Post by lcizzle states --

"-Open the UDK Editor
-In the Content Browser -> bottm left is a window that says "Packages".
-Click New
-Fill in the page and name sections
-Change factory to UIScene
-Click OK

Now you are in the UI Editor.
Design your UI, hook it up to code save the UI and the level.
Change your INI to load the .udk file when your game starts."


"You have it a bit backwards there, first you make a custom UI class in UnrealScript (it can be empty to start), then when you're creating your custom UIScene in the editor you select the class in the UIScene creation dialogue box."

[tegleg]

EDIT -- Post by lcizzle states --

"-Open the UDK Editor
-In the Content Browser -> bottm left is a window that says "Packages".
-Click New
-Fill in the page and name sections
-Change factory to UIScene
-Click OK

Now you are in the UI Editor.
Design your UI, hook it up to code save the UI and the level.
Change your INI to load the .udk file when your game starts."


"You have it a bit backwards there, first you make a custom UI class in UnrealScript (it can be empty to start), then when you're creating your custom UIScene in the editor you select the class in the UIScene creation dialogue box."

before the rude and costly introduction of scaleform we use to have a ui editor right there in the editor, sure it wasnt the most easy system to use but at least it was free and got the job done, and without the need for cross language communication (twice the work with scaleform)

[gegebel]

I still miss my UIScene man.
Anyway
Creating a design document is something you want to do first, even though it will evolve and change. Some things will be great, others not that much and some stuff will just be impossible (or too time consuming for you to do alone).
I've been working for 3 weeks on a gun 2 years ago and it was really frustrating, some day I got it to work though. Now I don't need it anymore, found something better. I lost a lot of time doing stuff which might be fun but turned out to be useless in the end.
I think motivation is the biggest issue sometimes. I create something new, or try to, doesn't work, search for hours and days, and finally get it to work to see it ain't working like you imagined in your game, just to delete everything or just do a backup for some other game, some day, maybe
prototyping and testing is important. Don't play your tests alone, let other people test your stuff and try to get as much feedback as possible. what's fun for you ain't always fun for others.

[Lexluthor1]

The same as any other kind of project, you sit down and come up with a prototype plan/design and set project milestones and goals. The design is iterated in cycles until you reach the project goals. In between each iteration you have the different parts of your team doing their job.

You need the following people:
Project lead/manager
Concept artist
Writer
3D modeler
3D rigger and animator
texture artist
Level designer
Programmer
Materials and effects artist
UI designer
Sound engineer
Composer
voice actors
marketing and PR person

The workflow is not linear, you have several different branches working simultaneously, starting with the writer and concept artist. Once you have a story and concept that is chosen, the modeler begins making useable characters for play, the level designer starts blocking out the levels and the programmer starts implementing gameplay elements. The levels are tested for basic core gameplay, when that is set, the art team starts creating models, sounds and effects to decorate the level with.The UI designer can start working alongside on the various menus and flash/scaleform related stuff. When the art passes are completed on the levels and the game is playable, it has reached alpha stage and the composer can begin writing the music to fit the gameplay. Everything is put together and tweaked in more art/programming/level design passes through the beta stage until you are ready to ship the game and it becomes gold. Somewhere in the middle, after the alpha stage, your marketing and PR people start creating public interest for the game and work on securing distribution channels.

WTF

You've been reading too many comics!