Jump to content

CrimsonStrife

Members
  • Posts

    563
  • Joined

  • Last visited

Posts posted by CrimsonStrife

  1. actually its officially listed as the first series of "Doctor Who 2005". (my bad was typing 2003 rather than 5 earlier.)

    Hence why I said technically....they are basically writing their own series using the lore and cannon so it is it's own thing...but they acknowledge the existence of the previous Doctors and therefore it is also a continuation, and therefore it is not "technically" the first.

  2. Time to turn it in now...so I guess this is as far as it will go....the Normal maps on the walls did something weird....that's the first and last time I trust the Photoshop plugin >.<

     

    render.jpeg

     

     

    I think the portals turned out dead sexy though...considering I had to fake them lol.

     

    -Edit-

     

    Had to make a "reflection" on the assignment too....so I'm gonna trow that at you guys to, cause hell, why not?

     

     

    Reflection

    Time Spent Overall: 4 to 6 hours

    I wound up using more objects than required for my portal room. In the end I had the two portals, the companion cube, two doors, and the room. The room was a bit of a pain to the get the detail I wanted, I made a nice detailed tile texture in two shades, but since the room had to use one whole map I had to fit them into one file as a pattern on each wall. In the long run this caused most of the detail to be too small to see, or blurry.

    The tiles should have looked similar to this:

    tiles1.jpg

    I attempted to remedy this by adding in additional details to the final texture, such as the “ratman drawing”.

    I think that the portals themselves were my finest work on this project, which is surprising since they were quite possibly the easiest texture to make.

    The Portals:

    portalb.jpgportalo.jpg

    I was not happy with the way the bump maps turned out in Maya however. This is primarily true with the room; however this could be mostly due to the resolution. If I could do this differently I would have made separate textures for each wall and the floor, or I would have tiled the texture and created a second surface and used alphas to create “decals” to put the worn effects on the tiles.

     

  3. Yeah I know what your referring to....the primary problem with the resolution is that according to the rules of the assignment each object can have one texture map, and the walls, floor, and ceiling must all be one object....I therefore have to make everything fit in one image file which is forcing my resolution to be wonky....as for the cube, it looks low detail because all I've done so far is flat shade it.

     

    This is what the tiles on the floor SHOULD look like as of what I have done now...

     

    tiles1.jpg

    tiles3.jpg

     

     

    But my instructor requires that I fit the textures into this

     

    room.png

     

     

    The main reason is that while I graduate after this semester, this is a new class that is supposed to be pretty entry level, I am just taking it (one so he would have enough people in it to have the class) and two because I needed an extra class on my schedule to stay a full time student....So I suspect that given how early in the class we still are, his main objective is to see who understands UV mapping...because from what I have seen, maybe one other student in the class can texture halfway decent.

    Scooper likes this
  4. is this dlx? man its good to "meet" u dude. yeah i worked with firedragon for a while on jau but it just had wayy too much to cover and tasks were never established so tons of work was done, mainly from what i seen by authuran, myslef and ashura and yerself... but most of it was most likely lost.

     

    Yeah it's me alright....and I am a hell of a lot better than I was back then...and this looks better than what I can recall mine looking like anyway XD good job so far

  5. So after coming to the realization that a handful of us here have formal Game Development education and or experience, I felt it might be beneficial for those who wish to pursue the industry if we banned together and shared from the fountains of our collective knowledge.

     

    I am going to kick things off with an item that is essential to a professional game design...the Design document.

    Your Design Document is essentially a summary and collection of EVERYTHING in and about your game, while you might not go dialogue for dialogue, you would include the story, the characters, the setting, etc...but you would also then list mechanics, how will the player move, how will they win, is there AI, if so how will it work?...

    This sounds like a lot I know...and it is, which is why I have decided to share a template that an instructor and I compiled last year. This way, you can see how you might lay out the info, what all is involved, and you can even treat it as a fill in the blanks.

     

    You can either copy and paste, or download it as a pdf from the spoiler box at the bottom of the page.

     

     

     

    Game Design Document Outline

     

    Version 0.5(draft) October 10, 2011

     

    By Adam Carriker

    and Patrick Barnhardt

     

    The Game Design Document (GDD) it the blueprint from which a computer or video game is to be built. As such, every single detail necessary to build the game must be addressed in the document (or support documents). If it’s not in the document, then it probably won’t be in the game.

     

    Below you will find an outline for a generic Game Design document. The problem is that no generic GDD will be able to address all the various genres for which a game may be created. For example, consider the games PacMan, SimCity and Doom. All three games required detailed design documents, but if you think about it, those documents would be entirely different! As such, when using the outline below you will find sections that will be totally meaningless to your game. But also, there will be sections that your GDD requires to describe the game. Just because it’s not in my outline, it doesn’t mean that it doesn’t belong.

     

    The GDD is a reference document. Members of the development team will constantly be using the document to find specific information for their specific needs. Consider the size such a document may grow to in order to document every piece of the game. We don’t want the GDD to cause information overload and then become a prop under somebody’s wobbly desk. As such it is important that you organize and format the document to make it easy to use. Also note that some of these sections might not appear in the GDD itself but instead would appear in supplemental documents such as an Art Bible or Test Plan. This helps make the overall document more manageable and readable.

     

    One last comment, a game design document is meant to be a living document. Just as when the artist changes the design of his painting every time he takes his brush to the canvas, a computer or video game evolves as code and art are created. The GDD then is the communication tool from which all the members of the team can follow that evolution.

     

     

    1. Title Page

    1.1. Game Name – Perhaps also add a subtitle or high concept sentence.

    1.2. Copyright Information

    1.3. Version Number, author, date

    2. Table of Contents – Make sure this includes all the subsections to make finding material. If practical, hyper linking the document will help here.

    3. Design History – This is a change listing quickly describing each major version and changes.

    4. Section I - Game Overview

    4.1. Game Concept

    4.2. Feature Set

    4.3. Genre

    4.4. Target Audience

    4.5. Game Flow Summary – How does the player move through the game. Both through framing interface and the game itself.

    4.6. Look and Feel – What is the basic look and feel of the game? What is the visual style?

    4.7. Project Scope – A summary of the scope of the game.

    4.7.1. Number of locations

    4.7.2. Number of levels

    4.7.3. Number of NPC’s

    4.7.4. Number of weapons

    4.7.5. Etc.

    5. Section II - Gameplay and Mechanics

    5.1. Gameplay

    5.1.1. Game Progression

    5.1.2. Mission/challenge Structure

    5.1.3. Puzzle Structure

    5.1.4. Objectives – What are the objectives of the game?

    5.1.5. Play Flow – How does the game flow for the game player

    5.2. Mechanics – What are the rules to the game, both implicit and explicit. This is the model of the universe that the game works under. Think of it as a simulation of a world, how do all the pieces interact? This actually can be a very large section.

    5.2.1. Physics – How does the physical universe work?

    5.2.2. Movement

    5.2.2.1.General Movement

    5.2.2.2.Other Movement

    5.2.3. Objects

    5.2.3.1.Picking Up Objects

    5.2.3.2.Moving Objects

    5.2.4. Actions

    5.2.4.1.Switches and Buttons

    5.2.4.2.Picking Up, Carrying and Dropping

    5.2.4.3.Talking

    5.2.4.4.Reading

    5.2.5. Combat – If there is combat or even conflict, how is this specifically modeled?

    5.2.6. Economy – What is the economy of the game? How does it work?

    5.3. Screen Flow

    5.3.1. Screen Flow Chart – A graphical description of how each screen is related to every other

    5.3.2. Screen Descriptions – What is the purpose of each screen?

    5.3.2.1.Main Menu Screen

    5.3.2.2.Options Screen

    5.3.2.3.Etc.

    5.4. Game Options – What are the options and how do they affect game play and mechanics?

    5.5. Replaying and Saving

    5.6. Cheats and Easter Eggs

    6. Section III – Story, Setting and Character

    6.1. Story and Narrative - Specific details like scripts and cut scenes may not be in this document but be in the Story Bible.

    6.1.1. Back story

    6.1.2. Plot Elements

    6.1.3. Game Progression

    6.1.4. License Considerations

    6.1.5. Cut Scenes

    6.1.5.1.Cut scene #1

    6.1.5.1.1. Actors

    6.1.5.1.2. Description

    6.1.5.1.3. Storyboard

    6.1.5.1.4. Script

    6.1.5.2.Cut scene #2

    6.1.5.3.etc.

    6.2. Game World

    6.2.1. General look and feel of world

    6.2.2. Area #1

    6.2.2.1.General Description

    6.2.2.2.Physical Characteristics

    6.2.2.3.Levels that use area

    6.2.2.4.Connections to other areas

    6.2.3. Area #2

    6.2.3.1.etc.

    6.3. Characters

    6.3.1. Character #1

    6.3.1.1.Back story

    6.3.1.2.Personality

    6.3.1.3.Look

    6.3.1.3.1. Physical characteristics

    6.3.1.3.2. Animations

    6.3.1.4.Special Abilities

    6.3.1.5.Relevance to game story

    6.3.1.6.Relationship to other characters

    6.3.1.7.Statistics

    6.3.2. Character #2

    6.3.3. etc.

    7. Section IV – Levels

    7.1. Level #1

    7.1.1. Synopsis

    7.1.2. Introductory Material (Cut scene? Mission briefing?)

    7.1.3. Objectives

    7.1.4. Physical Description

    7.1.5. Map

    7.1.6. Critical Path

    7.1.7. Encounters

    7.1.8. Level Walkthrough

    7.1.9. Closing Material

    7.2. Level #2

    7.3. etc.

    7.4. Training Level

    8. Section V - Interface

    8.1. Visual System

    8.1.1. HUD - What controls

    8.1.2. Menus

    8.1.3. Rendering System

    8.1.4. Camera

    8.1.5. Lighting Models

    8.2. Control System – How does the game player control the game? What are the specific commands?

    8.3. Audio

    8.4. Music

    8.5. Sound Effects

    8.6. Help System

    9. Section VI - Artificial Intelligence

    9.1. Opponent AI – The active opponent that plays against the game player and therefore requires strategic decision making (example, Civilization or Chess, how is it to be designed?

    9.2. Enemy AI – Villains and Monsters

    9.3. Non-combat Characters

    9.4. Friendly Characters

    9.5. Support AI

    9.5.1. Player and Collision Detection

    9.5.2. Pathfinding

    10. Section VII – Technical – This may be abbreviated with most in the Technical Bible.

    10.1. Target Hardware

    10.2. Development hardware and software

    10.3. Development procedures and standards

    10.4. Game Engine

    10.5. Network

    10.6. Scripting Language

    10.7. etc.

    11. Section VIII – Game Art - This may be abbreviated with most of the content in an Art Bible.

    11.1. Concept Art

    11.2. Style Guides

    11.3. Characters

    11.4. Environments

    11.5. Equipment

    11.6. Cut scenes

    11.7. Miscellaneous

    12. Section IX - Secondary Software

    12.1. Editor

    12.2. Installer

    12.3. Update software

    13. Section X - Management

    13.1. Detailed Schedule

    13.2. Budget

    13.3. Risk Analysis

    13.4. Localization Plan

    13.5. Test Plan

    14. Appendices

    14.1. Asset List

    14.1.1. Art

    14.1.1.1. Model and Texture List

    14.1.1.2. Animation List

    14.1.1.3. Effects List

    14.1.1.4. Interface Art List

    14.1.1.5. Cut scene List

    14.1.2. Sound

    14.1.2.1. Environmental Sounds

    14.1.2.2. Weapon Sounds

    14.1.2.3. Interface Sounds

    14.1.3. Music

    14.1.3.1. Ambient

    14.1.3.2. “Action”

    14.1.3.3. Victory

    14.1.3.4. Defeat

    14.1.4. Voice

    14.1.4.1. Actor #1 lines

    14.1.4.2. Actor #2 lines

    14.1.4.3. Etc.

     

     

     

     

     

    One of the major advantages to writing a GDD is that even if you cannot make it yourself, it gives you something with which to pitch your idea to a major developer.

  6. The courses are not a requirement...you could learn to do everything on you own. The classes I took were actually for UE3 which is the exact same interface as UDK, and I wasn't taking them to learn to use it, but because that is the engine my school uses for the degree, the point I was making was that I am more comfortable with it, because I have spent so much time with it.

    It does dramatically cut down on difficulty because it comes with essentially all the technical tools you would need built in, but it also relies entirely on what you as an individual are either already capable of when you pick it up or what you are willing to research. Not to mention it is still a beta product, so they have not yet released much in the way of documentation.

     

    Quoted from the UDK FAQ

    Q: How much knowledge is required for someone to make a project with UDK?

    A: Users who are new to Unreal Engine 3 should visit Getting Started with UDK on the Unreal Developer Network (UDN). There are also new “Mastering Unreal Technology” books, authored by 3D Buzz and published by Sams:

×
×
  • Create New...