The Pole Game White Paper, Revision 0 The Pole Game White Paper



Download 119.78 Kb.
Date conversion13.05.2016
Size119.78 Kb.

The Pole Game White Paper, Revision 1.0


The Pole Game White Paper

About This Document 2

Document Revisions 2

Project Team 3

Programming Team 3

Art Team 3

Music and Tunes 3

Web Design Team 3

Special Thanks 3



Gameflow 4

Loading Screen 4

Title Screen 4

Decorate Jacket 5

Options Menu 5

Art Specifications 7

Graphics Template 7

Timeline 7

Terms used in Timeline 7



Completed 7

Documented 7

Saved on Leilu 8

Graphic Tree 8

Sound Specifications 9

Sound Template 9

Suggested Effects Needed (Out of Date) 9

Sound Effects Recorded 10



Pole Game Press Release, August 1997 13

Misc. Information about the game 15

What Will the Game Look Like? 15

Projected System Requirements 15

Making the Frosh Artificially “Intelligent” 15



Things to keep in mind 15

(Mis)Behaviour 16

Keeping the Frosh From the Tam 17



Amongst Our Weaponry Are Such Diverse Elements As: 17

The Iron Ring 17

Something Cool To Do 17



Programming and Documentation Conventions 20

Hungarian Notation (condensed) 20




About This Document


The Pole Game White Paper contains all the up-to-date information needed for developing The Pole Game, an arcade rendition of the ultimate Frosh Week event for the Windows95 platform.

It should be accompanied by “Graphics Template.cpt”, a file which contains as a series of layers many of the graphics used in the Pole Game. As you begin work on part of the game’s art, music or programming, you are welcome to download large colletions of artwork or sound effects associated with the game. We have over 300 MB of stock graphics, and 450 MB of stock sound effects.


Document Revisions


1.0 – Friday September 25, 1997 Name of document changed to “Pole Game WhitePaper” from “Pole Game Compendium.” Pretty much totally revamped.

0.2 – Friday September 14, 1996 Sound Effects Recorded included; released at the first Pole Game meeting, Saturday September 14.

0.1 – Friday August 2, 1996 First rough copy of the document; released at The Wellington Friday August 9.

Project Team

Programming Team


Team Leader: Robert Burke

DirectX Guru: Pat Bouffard

Art Team


Artistic Director: Craig Calvert

Contributors: Kitty Lee (Sci ’99)

Photography: Brendan Carroll

Frosh Character Design:

Elizabeth Burke

Music and Tunes


Musical Director: Matt Garrett

Web Design Team


EngSoc Liaison: Jamie ffolliott

Special Thanks


Mr. Peter Burke, Nikon Canada Inc.

Mr Donald Bloor, Math and Eng ’78
Additional credits can be found on the Web Site. If you know of someone who deserves mention in these credits but doesn’t appear here yet, please e-mail Robert at 4rb8@qlink.queensu.ca as soon as possible.

Gameflow


There are essentially only five “states” the game can be in: Loading Screen, Title Screen, Decorate Jacket Screen, Options Screen and Pole Game. Here is how it moves between these stages:


Loading Screen


This “Splash Screen” displays as the game is loading the non-streamed sound files and the menu graphics into memory. It shouldn’t be too fancy. A progress meter is not required, as this process takes less than 4 seconds on a Pentium 133 system. Something like http://engsoc.queensu.ca/sci99/pole/images/The_Legend_of_the_Greasepole_Sized.jpg would be appropriate, but without the text that currently clutters that graphic.

Graphics Required:

Load\Splashscreen.bmp (640x480)



Sounds Required:

Menu\LoadRepeat.wav (Tentative: Start of MHTH)

Menu\LoadInit.wav (“How high’s the pole, Frosh?”)

Title Screen


The “Title Screen” displays the title of the Pole Game. The working title is “The Legend of the Greasepole,” and we welcome other suggestions at this point. The only requirement for this screen is that it contains the two choices “Start” and “Options,” which can be selected by a mouse click. Design of the mouse cursor, title screen, and these two buttons is entirely in the hands of the artist. Some ideas that have surfaced:

  • Could the “l” in “GreasePole” or “Legend” somehow be the pole in the title graphic?

  • If you plan on using a bitmap that shows the pole against a backdrop of the sky or the pit on this bitmap, could the Pole be saved in a second graphic and “zoomed in” or something? In short, could a half-second animation as this screen loads spice it up a little?

Graphics Required:

Menu\TitleBack.bmp (640x480)

Menu\Title\Start.bmp (The image that will be clicked to start the game)

Menu\Title\Options.bmp (The image that will be clicked to open the Options menu)



Sounds Required:

Menu\TitleInit.wav (Tentative: Bridge between LoadRepeat and TitleRepeat)

Menu\TitleRepeat.wav (Tentative: Slightly further into MHTH)

\Menu\Select.wav (Some sort of “Selection” noise for when you choose “Start” or “Options.”)


Decorate Jacket


After clicking “Start” the player is presented with a jacket arm on the left and all ten discipline bars on the right. A voice will say, “Select your discipline and click the Pass Crest to start!” “Select your discipline and click the Pass Crest” will be written on the screen.

The discipline bars can be dragged onto the arm of the jacket. A LMClick on a bar selects it, which will be accompanied by a sound clip (“Electricaaaaal!”, etc.) Until the LMB is released the bar will be flagged as “moving” and will follow the mouse. When the LMB is released, the bar will assess if it is closer to the jacket arm than its original spot. If so, it will snap into position complete with an appropriate sound.

If the mouse is moved to the lower-right hand corner of the screen, a “Ritual” bar pops up

Graphics Required:

Menu\JacketBack.bmp (640x480, probably taken from stock footage. Get something that matches our palette nicely and doesn’t stand out too much)

Menu\Jacket\BarApple.bmp … BarRitual.bmp (Taken from CoolPix shots)

Menu\MenuJacket.bmp (~400 x 480 shot of a jacket arm with pass crest and no bars)

Menu\MenuPassCrest1.bmp through MenuPassCrest3.bmp (The crest glows while you wait, 3 is brightest.)

Menu\txtSelect.bmp (“Select your discipline and click the Pass Crest” in an appropriate font)



Sounds Required:

Menu\PlaceBar.wav (A bar being put into place on the jacket arm)

Menu\JacketInit.wav (“Select your discipline and click the Pass Crest to start.”)

Menu\JacketRepeat.wav (Tentative: Further along MHTH?)


Options Menu


This one is largely unplanned as of yet. There is certainly need for some sort of backdrop and selection devices. I have looked to the Options screens of “X-Wing vs. TIE Fighter” for inspiration here. LucasArts employed cool little gadgets for selecting options, and they completely abandon the use of “scrollbars.” What I’m saying is instead of 10 different levels of Frosh Lameness, all we really need is a “SO lame” setting and a “Keener” setting. And that’ll give people all the flexibility they need.

The Options Menu Backdrop (Menu\OptionsBack.bmp) does NOT need to be 640x480. It will always be displayed on top of the Start Menu, so plan the graphics accordingly and work with the person designing the Start Menu.



Options Required:

Number of Colours (256, 65536)

Frosh Lameness (SO Lame, Keeners)

Sound (Off, Loud, Louder)

Intense Crowd (Off, On)

Intense Scenery (Off, On)

Done

Graphics Required:

Menu\OptionsBack.bmp (Not necessarily 640x480… stuff from title screen can bleed through.)

Menu\Options\(Toggles, any additional animation in the toggles, etc.)

Sounds Required:

Menu\Toggle.wav (Toggle noise)

Menu\Select.wav (“Done” button noise (also used for selecting Discipline bar above))

Art Specifications

Graphics Template


Included with this document is the Pole Game Graphics Template. It is a high-colour 640x800 Corel PhotoPAINT! 7.0 file that contains over a dozen layered graphics that are used in the Pole Game. There are a couple of Frosh for you to play with, mock-ups of the final background graphics, and so on.

Keep in mind that due to the parallax scrolling during the game, the background elements will displace in relation to each other. The display shown in the Template is what the pit looks like “straight on” before the screen pans up.

Note that the majority of the graphics used there are not in their final version. Immediately you may be able to notice some sections of the graphics that need work. For example:


  • In the final version, the water will ripple. We need new, rippling water effects. You can draw from the vast amount of footage on file of water at the Pit site. How’s your PhotoPAINT skill?

  • We have pictures of the ambulances, busses, U-Haul’s and so on. What would the perfect background look like?

  • No lanolin is gooping down the pole. Anyone willing to give that a shot?

Timeline


The timeline can be found at the Pole Game Web Site, and will soon be dynamically updating.

Terms used in Timeline

Completed


For a graphic to be considered completed, it should:

  • Be saved as an uncompressed Windows Bitmap (.bmp) file in 16-bit colour.

  • Use RGB(200, 200, 255) (a pale blue shade) as the “see-through” or “alpha” colour.

  • Be trimmed to the smallest possible rectangle.

  • Be touched up to the quality you’d be proud to sign as an artist.

Documented


For a graphic to be considered documented, it should satisfy the following:

  • Accompanied by a file with the same name and extension .txt which contains information formatted as follows:

  • // filename: Description (m/n)

  • \directory\filename.bmp

  • hotspotx

  • hotspoty

The HotSpot coordinate indicates the displacement of a special point on the graphic from the rectangle’s upper-left corner. For people in the background of the game, the hotspot is in the middle of their feet. For the Frosh, it is the point where their shirt touches the water. Please ask Craig or Rob if you are unsure where the hotspot sits. In most cases, you can invent a location for the hotspot yourself. Be sure to document what the hotspot represents in the accompanying text file.

An example would be:



  • // bmpSPLASHSCREEN: The Pole Game "Loading..." Splashscreen (1/1)

  • load\splashscreen.bmp

  • 0

  • 0

Saved on Leilu


Leilu is the hard drive on Craig Calvert’s computer. It is shared over the Queen’s at Home service and is thus available to Robert Burke’s computer as well. To gain access to this hard drive, send files to either Craig or Rob. We are both reachable by e-mail, or via the impressive ICQ service. Visit http://www.mirabilis.com to obtain a copy of ICQ. It is an “Internet Pager” that lets you know if your friends are online. You can send them messages, files, and engage in “conference call” IRC-style chats.

Graphic Tree


If you are working on a set of graphics for a sprite that can go through a series of “motions” or behaviours, you will need to design a Graphic Tree. This is simply a diagram that depicts under which circumstances a sprite can change from one image to another, along with any additional information required to animate the sprite.

The following is an example of a very simple Graphic Tree. Note that the frame rate of the game is 25 fps, and all delays should be expressed in terms of frames.




Sound Specifications

Sound Template


All sound effects should be saved at 22050Hz, in 16-bit Stereo. To a great extent, the sound effects will make or break the game, and it is exciting to see several Sci ‘99s taking an interest in improving the aural aspects of the game.

Suggested Effects Needed (Out of Date)


The following list was compiled towards the start of the project, and suggests the sound effects that will be needed for the game. These have changed to some extent over the past year.

Sound Effect

Produced by

Recorded

.WAV

Assorted splashes

Toogood Pond and Lake Ontario (and some bricks)




SPLASH

Intro








RE-POLE1 RE-POLE2 POLE102

Unused: Psycho, Pole10, Marika1, LuvChFrc, HardCore, GotChFrc, ArtChr1, EngHymn2/3, ConRad, Grant1-8, 8KixAss

Sound Effects Recorded


These sound effects were all recorded using a TASCAM digital audio recorder, and are stored at 22050Hz, 16-bit Stereo. In a nutshell, they kick ass. The “Description” column shown here is by no means complete, and “hidden gems” can be found in most of these files. Let’s see what we can find!

File Name

Description

114Hard

How hard’s 114?








Pole Game Press Release, August 1997


The Greasepole is still the most significant event in the bonding of an Engineering year at Queen’s. For the uninitiated, it was conceived in the fall of 1956 by Chief FREC Ron ‘Porky’ Eade of Science ’59. In memory of the “invincible” U of T goal posts borrowed by Queen’s Engineers in the mid-fifties, Frosh climbed a Greased Pole in lieu of wearing their Tams until November. Sci ’60’s time of eight minutes, ten seconds didn’t quite cut it – nor would modern times of over an hour and a half. Knee-deep in muddy water, the Frosh have a hard enough time climbing a lanolin-covered pole, so spectators at today’s Grasepoles don’t bother trying to slow them down … but what if they did?

On Canada Day, 1996, a group of Queen’s students sat on Parliament Hill and brainstormed the idea of a computer game based on the Greasepole. Since then, Robert Burke (Math and Eng. ’99) has written a lot of Artificial Intelligence code, and is leading a team of nearly 20 programmers, artists and musicians who are working to bring the game to life.

At last year’s Greasepole, Rob recorded over 650 megabytes of digital audio using a TASCAM recorder, the same instrument Dan Gibson uses to sample nature sounds for his ambient music CD’s. Using the new DirectX extensions to Microsoft Windows, Pat Bouffard (Math and Eng. ’99) is developing “wrappers” that give the programmers the ability to tap into an individual computer’s graphics and sound acceleration hardware. On Pentium systems displaying a pit chock full of 75 Frosh, we have achieved frame rates over 20 frames per second while mixing stereo sound effects at near-CD quality.

The graphics in the game are being developed from a hybrid of photographs taken at the Pole and sketched artwork. The current Pole graphic is actually the real greased-up Sci ’00 pole. Craig Calvert (Mechanical ’99) designed the opening logo and has been actively involved in graphics design. Elizabeth Burke, a first-year Sheridan College fine arts student, developed the Frosh character. The sprite images were scanned in, meticulously touched up and coloured by Kitty Lee (Math and Eng ’99).

In the game, you take the role of an upper-year student standing on the bank of the pit. Artificially “intelligent” Frosh [sic] struggle to climb the pole, and your mission is to delay the inevitable for as long as possible. Most of the weaponry – Apples, Clark Hall Pub mugs full of beer, and even AriScis – is tossed into the pit using the same sort of first-person perspective seen in a game like “Doom” or “Quake.” The ultimate weapon is the Engineer’s Iron Ring. Its power is a function of your Engineering Discipline – and we’re open to suggestions if you have better ideas than these:

The Ring is held aloft on the little finger of a radiant arm. The wearer hollers out their discipline, “Apple Maaaaath!” Then:



Chem - A flask or two is tossed into the pit. A chemical reaction takes place to great bubbling and the Frosh pop like popcorn around the screen and into the drink.

Civil - A wrecking ball swings in from the sky, and, to bowling-pin-scattering sound effects, the pyramid falls.

Elec - A bolt of lightning hits the pole, electrocuting all the Frosh in contact with the Pole. The human pyramid collapses.

Geo - An earthquake rocks the screen and the Frosh tumble.

Materials - The pole deflates / decomposes and the Frosh fall. It returns to normal… after they’re all in the pit. (Alternative: The 16-Ton weight drops on the Frosh. (We need some Monty Python content.))

Math - The Pole morphs into an integral shape, and the Frosh slide down it into the pit.

Mech - A “Robotech” or “MechWarrior”-like machine walks in, swipes down the Frosh, and saunters off, leaving the pyramid collapsed.

Mining - An explosion at the base of the Pole sends all the Frosh flying.

Phys - An alien ship hovers above the Frosh, and, using an anti-gravity unit, makes them hover in the sky. Without warning, it drops them into the drink.

When completed, the game will be published on CD, complete with audio tracks of Sci ’99 Year Bands playing a variety of musical genres. Jason Silzer (Math and Eng. ’99) is writing a history of the Greasepole to include on the CD along with information about other Engineering traditions at Queen’s.

Interested? The Legend of the Greasepole (referred to by its developers as “Project Omega Supreme”) will be published in the summer of 1998, just before Sci ’02’s climb. Omega Supreme is a non-profit endeavor, and will be available for a nominal charge (less than $15) to cover development costs. If you’d like to reserve a copy, would like more information, or could contribute to the project, I’d love to hear from you!

Misc. Information about the game

What Will the Game Look Like?


Picture yourself a Frec standing on the bank overlooking the pit. Most of the weaponry – such as apples or even AriScis – is tossed into the pit using the same sort of first-person perspective as seem in a game like “Doom” or “Quake.”

Various components of the background will consist of animated sprites:



  • The Frec / Upper-year crowd in the background

  • A group of individual Frecs at the front of the background crowd (for jacket-slamming, hollering, etc.)

  • Ripples and water effects

  • Several dozen standing-around-wading Frosh

  • Assorted goofy “special effects” objects (planes, birds, big ‘Hawked heads walking by the camera)

And, of course:

  • Approximately 75 frosh, maybe up to 150! (This is up from initial estimates of 20!)

Projected System Requirements


  • Pentium processor

  • GPA

  • Windows 95 with DirectX 3.0 extensions

  • 16MB of RAM (possibly 32; let’s keep it down if we can.)

  • Gentian Violet

  • Sound Card and monstrous speakers for full effect

  • Alcohol for fuller effect

Making the Frosh Artificially “Intelligent”

Things to keep in mind


Perhaps the most critical element of the game will be the code which gives the Frosh “life.” The trick to developing this code will be to maximize the intelligence of the Frosh while minimizing the processing time required to maintain this level of intelligence. (Yikes, I’ve used the words “Frosh” and “intelligence” in the same sentence!) Keep these two things in mind:

  • Every conditional statement that has to be evaluated (i.e., an “if… then” clause) costs processor time.

Where this becomes important: It’s easy to translate a statement like “wade to the left a notch.” However, how do you tell a Frosh to “Find an spot at the base of the pole where none of your buddies are standing, and walk towards it.” You have to find an available spot, make sure nobody’s about to take it, determine which direction the Frosh has to move in, and then finally move him.

  • You don’t want to keep track of too many extraneous pieces of information.

Where this becomes important: Every Frosh has “properties” associated with him – strength and intelligence; Cartesian (x, y) co-ordinates onscreen; how much he’d like to devour a ‘Za, chug a Clark Mug full o’ Beer, how badly he wants to maul the Commie across the screen, and so on. There are also several “global properties” – the morale of the Frosh, the strength of the various levels of the pyramid, the number of nails still in the Tam, and so on. Having too many global properties is confusing and detracts from the programmer’s ability to integrate the elements of the game.

(Mis)Behaviour


A behaviour describes a particular way a Frosh interacts with his environment, as well as the set of conditions under which the Frosh can change its behaviour to another pattern. Factors affecting behaviour change (and performance within a behaviour) include:

  • intelligence (range: 5 to 20), lower is better

  • strength (range: 5 to 20), higher is better

  • morale (range: -3 to 3), higher is better

A behaviour consists of two component “activities” or functions:

Act - Do whatever it is you’re doing – move into position, splash water, plummet towards the earth, climb onto someone’s shoulders, etc. At some point in the process of “Acting,” the Frosh’s new co-ordinates and display graphic must be determined. The process of “Acting” may also involve a change in behavior. For example, a wading Frosh (4) may realize they have reached their position at the base of the Pole and change its behavior to Link Arms at Bottom of Pyramid (7).

Init - Initialize a new behavior.

Keeping the Frosh From the Tam


The object of the game is to keep the Frosh from getting the Tam for as long as possible. It’s how you go about prolonging the inevitable that makes the game interesting…

Amongst Our Weaponry Are Such Diverse Elements As:


Weapon

Quick Description

Apple

Tossed at Frosh from foreground (à la Doom). A beamed Frosh may be knocked into the air as a function of their strength.

Iron Ring

See below.

The Iron Ring


The Ring is held aloft on the little finger of a radiant arm. The wearer hollers out their discipline, “Mechanicaaaaal!” (or occasionally some random cool thing like, “Trust me – I’m an Engineer!”) Then… (see Sound Specifications, page 9).

Something Cool To Do


  • Load Word For Windows 95

  • Type “Frecs”

  • Click it with the Right Mouse Button

#

Behaviour

Comment

Poses

Sound Effects

1

Falling

4 or 5 different shots of frosh under the 9.8 m/s2 effects of gravity

  • 4 or 5 “flailing about” shots (some particularly silly)

  • whoosh with doppler effect

5

“Fun stuff”










5A

Eating Pizza

Picks up and muches the ‘Za

  • 1 - picking up the ‘Za hungrily

  • 1 or 2 - eating the ‘Za

  • Some froshie comments

  • eating noise

  • belching noise

6


“Confusion”










6A

Drunken Singing

After drinking beer (see 5B)

  • 1 or 2 - shots of Frosh serenading Camera

  • “We are, we are…”

  • “What would you do…”

7

“Pyramid Level One”







7A

Linking Arms

Frosh turn towards camera and link arms (note: would be great to have the “bookend” Frosh at different angles

  • 1 - shot turning toward camera

  • 1 - shot preparing to link arms

  • 1 - arms linked, forming pyramid



9


“Up to 2nd Level”






9A

Climb over shoulders

Frosh climbs up a Frosh in behaviour 7

  • 2 or 3 - climbing up over frosh onto his shoulders



16B

Hanging off Tam

A 16A finds himself with nothing to support his weight but the nails in the Tam

  • 1 - Hanging off Tam (high-quality… for a close-up)

  • uproarious cheering

Programming and Documentation Conventions

Hungarian Notation (condensed)


Prefix

Type

Description

Example

B

byte

unsigned byte

bSmallNumber

C

char

byte character

cEndFile

Cl


class

C++ object class

clStatusWindow



Page


The database is protected by copyright ©essaydocs.org 2016
send message

    Main page