Best practices - Unity game development

Unity Engine
1

Dear Fellows,

after finishing some of the tutorials, especially the 3D platformer, I have learned, game development maybe seems an easy task, but in reality not, especially if you got the idea in you mind for a game, but right now you are sitting before a computer, the Unity screen is blank, as a white sheet of paper before a writer or a poet.

So, I feel exactly the same now. As a newbie I have no real experience but theoretical. Where should I start?

Could we put together an approximate workflow/pipeline for it?

Let’s have an 2D example. I would like to create a hidden object game. I have the idea (main game concept: hidden object. Main character: Robinson Crusoe. Main location: Robinson’s Island. Main task: help Robinson to escape the island). (I brought this example simply becasue BigFishGames recently published a similar game.)

So, if you are in a small team (vision guy/producer, graphic artist, programmer and a sound artist), where and how do you start? (I guess this could be similar to a one man teams as well).

Since I am coming from the video editing, film-making field I know very well how important is the right pipeline, the right work order. For example, first select the clips, and then create a rough cut and do not start with color grading, which is normally the final step, otherwise you loose time, and time is money, especially if you are paying for someone else’s time.)

The 3D platformer gives a quite good example, however I miss some part of the process…

Let’s try to be organized…

  1. Create the game design document.

  2. Share the document with the team members.

So far so good. :slight_smile:

But my questions come now:

a. Should the graphic artist know Unity? Or is it enough if he/she works in Photoshop and uploads the files to our common server the files in psd?

b. In fact, what comes first? Creating the artwork or creating the basic scripts for the gameplay and using only low res, low quality art for this? And we final art comes only when the gameplay has been finished?

I am a bit puzzled. Should we create the skin of our model (the artwork) or should we create the bones and muscles (gameplay and scripts)?

Since in our preliminary team I am the vision guy, teams members ask me first. And since this is a totally newbie team we know that we will loose time until we learn our lessons to be learned, but still, if possible we would like to loose not so much time and working hours…

What are your best practices? I know some people in this community works alone but some of them works in teams. How do you organize your workflow, you pipeline, work order…

What are the major steps/milestones in Unity game development? From Alfa to Omega…

I would deeply appreciate any advice…

Many thanks,
Jules

2

Hey Jules,

First off, I would say that the most important thing is to get the basic basic gameplay prototype up and running as fast as possible. If you’re making an RTS, you need to be able to select and command troops so you need to be able to have selection and clicking to place a marker working before anything else can be done. In the case of a game like super mario galaxy, you need to have a basic character (or even just a box) able to run around a spherical world and jump normal to the surface. Without this, the game cannot proceed. If you are confident in the fact that you can make this happen or have already made it happen, the artist can start concurrently creating assets for the game as per your design. You should have an art asset list and a schedule created at this stage.

Does the artist need to know Unity? No, but it depends on the person. If they are interested and willing, Unity is not hard to get the hang of and they could be put on the task of bringing in art assets, doing lighting, possibly gui work, etc. It’s always good to at least import your 3d models (and 2d assets) into Unity to check for problems, such as flipped faces, softened/hardened normal edges, etc.

‘First playable’ is the most important step of all, because you really don’t have anything (from an on-looker’s perspective) without your assets/scripts implemented. Get to that stage with some preliminary art, and you’ll be well on the road to success.

Take my advice with a grain of salt though, as I’m definitely not as experienced as some other guys on the forums, the seasoned pros and such :stuck_out_tongue:

3

Some good questions…

"Should the graphic artist know Unity?" I don’t think it’s 100% necessary if you’re making a technically simple game, such as the ‘find-the-hidden-object’ game genre you mention; most of these tend to be just static images with the ‘findable’ elements overlaid.
If your game is more complex, such as the in the case of a 3D platformer, an experienced graphics artist will be more likely to want to check that their creations actually look like they should in the game, so they can make any tweaks and adjustments. To be fair, a Unity Indie license will generally suffice for this, but there may be issues if you’re relying on some of the Pro-only rendering features.
The reason such round-tripping becomes a necessity in more complex games is simply because 3D modelling software is usually designed with TV and film output in mind, rather than games. Games need to render graphics on-screen in real-time, so artists have to make compromises on detail and technique to allow for this. Some of these compromise techniques involve shaders – mini-programs written to run on the graphics card itself, not the main processor chip – to ‘cheat’ some of the details. Other techniques – e.g. the simplistic ‘spot’ shadow used in the 3D Platformer tutorial – require input from the scripting itself and cannot be reproduced in the modelling package.
Your development processes, team structure and workflow also have a bearing on the above. For instance, an Art Director might act as the point-man for Unity-specific tweaking of graphical assets. He would know how Unity works and can therefore specify how the assets need to be produced, safe in the knowledge that he can then massage them himself to fit the game’s overall visual style.
So the answer to that question is, predictably, “It depends!” The more complex your game’s visuals, the more likely your artists will need to have some access to Unity. As you move up the scale of complexity, your artists may even have to learn how to use Unity itself to get the best results. For simpler games, your artists might never need to touch Unity at all.
As for your question “b.”…
There are a number of approaches to making games. I prefer to build prototypes first, to get the raw mechanics working. I know how I want my game to play, as well as an idea of how I want it to look and feel. I also have a pretty good idea of which emotional strings I want to pull too. (I have an unusual approach to game design, so please don’t take any of this as gospel. Like writing fiction, everyone has their own styles and routines which works best for them.)
Once I’ve got the skeleton of the game nailed down, I can then focus on fleshing out, looking at the visual style, for example.
Sketching rough mock-ups, characters, sprites and other elements can help you work out the pipeline and determine what assets you will need to produce.
Now, my imagination is aural rather than visual. I tend to think in terms of music, emotions and words. If your brain prefers visuals, my particular art technique might not be all that useful, but here goes: I tend to use my paper sketches as guidelines or aides-memoire, rather than strict templates. My pen-and-paper art style is that of a cartoonist and animator, while my 2D sprite art looks more accomplished as I have far more experience producing it. (Even today, I find I prefer pixel-centric packages like Pixen and Pro Motion over more popular tools like Photoshop.)
Get as much design done up-front as you can. Write big lists of what you need, from a list of music tracks down to a list of samples for button clicks and other GUI elements; from the level designs down to the mouse pointer animations. It all adds up and you need to get all this organised too.
Basically, it boils down to project management, much as in any other industry. The trick is knowing which assets you’ll need, but if your background is in TV and film, you’ll likely find many parallels: Unity even relies on a ‘virtual studio’ metaphor, with cameras, lights, props, set dressing, etc. We just use different names for them and build them using different techniques, but you’ll still need to create them, organise them and marshal them to create your game.
Some things, like your “skin first or bones first” query, tend to fall into place once you understand how all the bits and pieces have to work. In CGI work, the best analogue is probably that of stop-motion “claymation”-type animation, which uses a similar system of armatures with modelling clay wrapped around it. “Sketches → Armature → Clay” becomes “Sketches / Design → Bones → Skin”. Your artist(s) will be able to help you here.
I could go on, but there are books and books of this, so I think I’ll just point you at the ‘classic’ on the subject: “Game Architecture Design”, by Rollings Morris. It’s on Amazon, here.. (NOTE: There’s an older edition with a different cover published by the now-defunct Coriolis Press. Avoid that one as it’s outdated in places.)
At the risk of sounding like a corporate shill, there’s also a series of books from the GameDev.Net crew which covers a lot of this ground too. (Disclaimer: I contributed an article to one of these books, but I’m not sure which one it’s in as there was a reshuffling just before publication.) I think the “Business and Production” book is out now, with the others due to follow over the next few weeks.

4

Thank you very much for the detailed replies!

I am a kind of visual guy, I see in my mind the pictures, the scenes I would like to create with the help of talented artist. The question is how can I tell them what I see :slight_smile: Albert Camus wrote once, that he used to see for a moment the whole novel he would like to write - but this shiny moments flys away, and thousands of working hours are waiting for him to recreate his vision in writing…

As I see both of you prefer some kind of paralell process: with the use of mock-ups one can start to create the gameplay (like the rough, off-line editing) and when it goes well, one can gradually upgrade the artwork with the final versions and then adjust the gameplay.

As for the music: my composer prefers to see pictures, because he is inspired by the pics.

I checked Amazon for the first book, and will look after the Business and production book as well, GameDev.net is a very useful source, I used to read the articles there.

Thanks again,

and I don’t intend to close the thread, if anyone has anyting to add, welcome and thanks!

Jules

5

This is close to being one of those “How long is a piece of string?” questions. The final answer will depend heavily on how you and your artist like to work.

Some artists like a lot of precise guidance and detail from you, usually in the form of an ‘art specification’ of some kind. (The more complex the project and the larger the team, the more likely you will have to go down this route. This is why you get Art Directors and Concept Artists on such projects: they help nail down the look of the game in pre-production, before you commit huge piles of cash on salaries.)

At the other end of the scale – especially on smaller projects – you may find it easier to brainstorm a bunch of suggestions for the artistic style. Throwing ideas into the pot and seeing what comes out is a perfectly valid approach if it’s not costing you much to do.

The only important factor is to know where you’re headed before you pour real money into the project.

The chances are, your talented artist will have a good idea of the level of detail he will need from you and can probably give you examples of art specifications should you need a guideline.

(As an aside, I would strongly advise that your final choice of artist should be based not solely on skill, but on range. An artist who can only do Animé-style art isn’t going to offer much in the way of alternatives.)

There’s a good reason for this: it’s damned hard to convey how a game will feel, both mechanically and aesthetically, using static images and plain words on paper. Writing is a linear medium; games are usually non-linear. If your game is highly non-linear, a linear design document isn’t going to be as useful as a linear design document and a non-linear “and it works like… this!” prototype.

(A caveat here: I have unusual views on game design, among many other things. For instance, the issue of ‘linearity’ in entertainment is not as clear-cut as many like to imply. Take Agatha Christie’s murder-mystery novels, which I see as puzzle games, not simple, linear stories: for most readers, the story produces a non-linear experience as they try to solve the mystery at the centre before the protagonist does. To me, this makes Christie’s novels interactive, non-linear games, albeit presented in a linear medium. It’s all to do with how the human brain builds mental models all the time. All entertainment relies heavily on this mental process, from games through to stand-up comedy.)

I would suggest working on a prototype and some concept art first, then.

A game consists of interaction, vision and sound, all working together. All of these need to be addressed in the pre-production phase. It sounds like you’ve worked this out for yourself, but for the sake of any others reading this…

If your game has strong story elements to it, get a writer involved from the outset too. (It’s a common mistake to bring a writer on-board at the very last minute, after all your expensive graphics and sound elements have already been created.)

Writing may seem less important if the game isn’t a story-heavy one. Nevertheless, it’s always a good idea to ensure all the text and UI elements have been given a good proof-read before release. (I’ve seen professional games with appalling typos and spelling mistakes. Such a lack of attention to detail leaves a poor impression and makes me wonder what else they couldn’t be bothered to fix.)

Similarly, many game developers leave aural elements until the last minute, with the result that the game sounds muddy and confusing. Unlike an album, games don’t have the luxury of a final mix-down process: the mixing has to be done in-game, in real time, ensuring sound effects or spoken dialogue elements aren’t drowned out by thundering tympani rolls.