HailStone Game Proposal

[Feanor]

HailStone Proposal (http://homepage.mac.com/brentgulanowski/.cv/brentgulanowski/Public/HailStone%20Proposal.rtf-binhex.hqx)

Above is the link to the first draft of my game proposal. The most important part to be discussed would be the Project Goals, which I duplicate here for those not of a mind to read my essay:

1. A 3D simulated environment consisting of simplified urban-style terrain
2. Freedom of movement in 2 dimensions using keyboard
3. Freedom of view (ie: "eye" movement) in 2 dimensions, constrained view in the 3rd (up and down) using keyboard (and hopefully mouse)
4. Game level-end locations
5. A lighting model which simulates night vision, with enough colour to be interesting
6. The ability to load different game levels from a file
-- first landmark of achievement! --
7. Preferences to control resolution and other graphics settings (in full screen mode)
8. Simulated opponents with freedom of movement in the world
9. A simulated "tank cockpit" interface
10. 30fps with hardware acceleration, 15fps without (challenging!)
(this will be helped a lot by proper use of G3D's culling and scene-graph flattening)
11. An operational "sensor device" which informs the player of enemies and level end
12. Operational weapons with which to destroy enemies ( ultra-simple animations)
13. Weapons with which the enemies can damage/destroy the player's tank
-- second landmark of achievement! --
14. Enemy military target locations which can be destroyed, and show up on "sensors"
15. Textures for our models
16. Improved and varying behaviour for enemies
17. Multiple enemy units
18. Varying lighting conditions (daylight, moonlight, starlight)
19. basic sound effects
-- third landmark of achievement! --
20. animated enemies (whirring bits like turrets, headlights, etc.)
21. improved weapons animations and dramatic explosions (with sound)
22. air support: call in for extra ammo and tank-repair units
-- fourth landmark of achievement! --
23. two-player support
24. improved custom model and level editor (full WYSIWYG and mouse-drag)
25. shells will blow holes in sides of buildings so you can drive through
-- fifth landmark of achievement! --

A nice magic number: 25 goals that we can work towards, in roughly that order, and virtual beer&pizza at every landmark achievement! At that point we can hopefully call the game functionally complete and enter beta testing mode. If necessary, however, we can call it feature-complete at the fourth landmark and release improvements after that.

If you are interested in helping out, in any capacity, please download the proposal and have a look, and at least note the eleven proposed component systems, of which eight I have deemed "essential" to the project's having any veracity. Decide if you want to specialize or be a floater, and let me know your ideas and proposed means of developing the project. Please start a new forum thread for discussing each component system, and preserve this thread for the Project Goals discussion.

FÎanor

[OneSadCookie]

The game sounds cool!

I won't bring up the design debate again in this thread..

[Feanor]

Har har! I'll bet you enjoyed setting me off on a poorly-disguised tirade. Anyway, the design rules are essentially up to Mr. Pazolli, he being the official editor of Inkubator projects. It just so happens we think along similar lines, though.

Anyway, OneSadCookie, I hope you can help us out. I know at least that you'll be able to answer lots of questions for us!

Thanks for the approval.

[Carlos Camacho]

Rolling Thunder is copyrighted name of an old Japanese game. If my memory serves me correct, it was a side platform game. I'll check out your doc tonight.

Cheers

[DaFalcon]

Reading the other thread, the game that came to mind for me was Spectre, which I loved playing with friends on the mac years ago. I may have spelled it wrong, but it was essentially a simple tank game with simple weapons and enemies, and tons of fun. Anyone who remembers spectre: do I have the right idea about Rolling Thunder, or am I way off? :-) Just curious, 'cause I loved Spectre so much I'd love to see another, better, somewhat-similar game for OS X :-) And I'll get around to reading the design document soon... :-)

[Pazolli]

Actually Spectre (and I'm fairly sure you did spell it correctly :-)) came to my mind too but I never posted about it. The great thing about Spectre was that it was a very simple game concept that was loads of fun to play. It had very elementary graphics (everything was polygons on black except the skyline which was a gradient to black) and you'd slide around in your land-based ship shooting other ships (artificial or human), while attempting to collect all the flags in the shortest time possible without being shot yourself. You'd loose ammo as you shot, so you'd have to get to refuelling bases to refuel. Plus you could customize your ship with varying degrees of ammo capacity, shield levels and maximum speed levels - this added a touch of strategy to the game. We could add some extra scenarios to the game, (i.e. make it not all capturing flags), a good storyline, ability to customize at each level, etc. and make it really cool.

I'll take a look at your game concept document soon.

[Feanor]

Originally posted by Camacho
Rolling Thunder is copyrighted name of an old Japanese game.
Alternative names:
Blast!
Fire Power
Sneak Attack
Robot Tank War
Zeus Machine (make the Tank shoot lightning)
Stone's Throw
Lightning Strike
Hostility
Infiltration
Lights Out
Operation: Hailstone
Black Light
-anything that anybody wants to suggest-
I don't know about Spectre. I think I will avoid looking it up in case it influences me.

[Feanor]

I have written a second document which details my vision for the architecture of the game.

I warn you that it is complex, but the design premeditates extensive scaling of the concept. As it says in the document, a lot of what I describe would not be necessary for a game, yet the architectural still functions even with these unnecessary components removed. And later on, it will be nice if the code for the game lays the groundwork for a general-purpose 3D game library, to exist on top of the 3D geometry and rendering library.

Architecture for HailStone (new name) (http://homepage.mac.com/brentgulanowski/.cv/brentgulanowski/Public/HailStone%20Architecture.rtf-binhex.hqx)

Really, the best part is the Film SoundStage analogy. The rest of it might be too theoretical for most people to find enjoyable.

FÎanor

[Lemming]

Wow, awesome concept. I love it already and look forward to contributing what I can.

I have a question/suggestion: You listed the movement and view as two separate items in the goals list. Does this mean, I hope, that movement of the turret and body of the tank will actually be entirely independant of each other? I think that'd be really cool, seeing as how we haven't had a good game like that on the Mac since Avara.

[Feanor]

Yes, actually, that is in the concept, although that is not what I was implying in the goal list. I should edit it maybe. In all FPS games, you can turn your head and this might orient your body, but it doesn't actually cause you to move in a direction (only rotates you).

The first set of goals are relatively simple, but I want to do them properly the first time, so I've made them explicit. Later goals increase in difficulty somewhat exponentially, but as we progress, we will expect more of ourselves before we achieve each successive level of self-congratulation. :)

[Feanor]

Here's a graphical representation of the way the objects in the game will be retained. What this fails to show is the horizontal connections between objects. For example, the Entities will contain behaviourDelegate objects which will run the behaviour code that makes Entities act in interesting ways, but they won't retain them.

Object Graph

The instance heirarchy based on who allocates who. I have used the UML Convention for showing objects: "instanceName:className". An object with no instance name is simply anonymous. Some instances appear to have no purpose other than "ownership" of other instances. Most of them will have purposes later, but some may be eliminated.

-----

^ - objects from the NIB
@ - objects alloc'd at runtime in our code
ï - objects loaded from a file
(usually instances down the heirarchy come from the same
place as their ancestors)
@@@ or ïïï - means multiple instances of class/sub-classes

HailStone Classes all start with HS (for now)

-----

NSApplication (alloc'd by the runtime system)

applicationDelegate:HSProducer@
|
+- :HSVenue@
| |
| +- :NSOpenGLContext@ (a fullscreen context)
| |
| +- :NSOpenGLPixelFormat@
|
+- :HSTaskManager@
| |
| +- :HSInputTranslator@
| |
| +- :HSSchedule@
| |
| +- :HSTaskQueue@@@
| |
| +- :HSTaskPriorityFilter@
|
+- :HSDirector@
| |
| +- :HSSpecialist@@@ (abstract class or protocol?)
|
+- :HSActor@
| |
| +- :HSBehaviourïïï
|
| __________________________________________
| The Properties Group
|
+- :HSPropManager@
| |
| +- :G3DFileHandler@
| |
| +- :HSStageManager@
| |
| +- worldStage:G3DWorldï
| |
| +- :G3DCameraïïï
| |
| +- :G3DGraphNodeïïï (the scenegraph)
| | |
| | +- G3DShapeïïï
| | |
| | +- HSEntityïïï (category of G3DLeaf)
| |
| +- :G3DAttributeNodeïïï (all the rendering attribs)
|
| __________________________________________
| The following make up the Presentation Group
|
+- :HSCinematographer@
| |
| +- :G3DFrustum@
|
+- :HSSoundConductor@


This is high level. If it went to deep it would be unmanageable.

When the program starts, the Producer generates all of the necessary helper classes (they could be in the NIB but they are singletons with no state data -- only instances to own and methods to run).

The Properties Manager finds the current game file and loads up the world and everything in it, as well as the Venue and the Behaviours. It puts references to certain objects where the Producer can get them.

The Producer then starts the drawing thread, which begins drawing cool 3D titles and menus, which are part of the Venue. When the user chooses to start a new game, we switch the Venue from main menus to a load screen. When the world is ready, the producer launches a new thread for updating the world. This thread runs up to four times as fast as the drawing thread in some cases. Then we switch the Venue to the HUD and start drawing from the point of view of the player's avatar.

At that point, the InputTranslator (on behalf of the player) and the Entities (really, the Master Actor) begin submitting their Impulse Messages to the Schedule's Impulse Queue. These are sorted by the TaskPriorityFilter, and picked up by the Director. The Director's Specialists process them, rejecting those that break simulation rules. They also generate new ones in response to certain interactions between Entities.

The Director submits the completed Action Messages to the Action Queue. Camera Messages that result from the player's change of viewpoint are placed on the Camera Queue, and Sound Messages that result from both the Impulses of Entities and the Events in the world are placed on the Sound Queue.
The Queues are once again sorted and culled as necessary (hey, there's only so much time).

The Cinematographer reads its instructions and alters the view frustum appropriately. The Stage Manager moves Entities around in the world (which requires setting and unsetting the a thread protection lock on the entity being updated). The Sound manager submits sound playing instructions to the operating system.

When the draw thread comes around, the owning camera (fixed inside the player's tank avatar), sets up any global OpenGL state, passing its orientation (ie frustum) information to OpenGL. It then sends orders to the world (the root of the scene graph) to flatten itself (that is, to organize itself for optimal drawing order, based on minimizing the number of OpenGL state changes), to perform visibility culling, and then to draw itself. Next the Venue's HUD is drawn, and finally the Context's buffer is flushed and the screen is painted with the newly rendered scene.

I think that's enough to keep everyone busy for now!

FÎanor

[Feanor]

I have expanded as liberally as possible on the various component systems, which I'm calling Production Groups, that make up HailStone. It's called HailStone Architecture.rtf. You can find all three in one convenient place:

FÎanor's iDisk (http://homepage.mac.com/brentgulanowski) (Thank you Apple!)

I'm thinking now that the entire Task Group is overkill for this application, so maybe just imagine that it isn't there and that the other Groups talk to each other directly, instead of using the intermediary approach (which is really only necessary for inter-process communication, not inter-thread).

You can also check out a couple of Cocoa OpenGL sample applications. One demos threading and fullscreen, while the other demonstrates a painfully simplistic "scene graph" (hah!) -- well, it lets me make multiple entities that share the same equally simplistic geometry relatively painlessly. It can make boxes and pyramids, and it can turn them inside out (to make a kind of enclosure skybox), which is neat. Sorry, no textures, but we've got proper lighting and depth culling in both.

Tonight I will hopefully attempt my first application that uses the GNU 3DKit. Has anybody else looked at that yet? The boards have been really quiet the last two days. I kid myself with the fantasy that everyone is reading my Game Proposal docs. I know, you all want to *play* the game. I'm working on it...

Enjoy.

[Carlos Camacho]

Hi, I downloaded both builds and confirmed thaat they ran well on my LCD iMac.

This is off-topic. Could you package the code to go full-screen and send me the sit.? I think it would be nice to have some code for newbies to be able to switch to full-screen mode. No rush on this.

I also read the Proposal. Overall, it looks fine.

A question I have... In some places I get the impression of a WW2 tank but in other sections I feel it is very SF.

I'm interested in seeing the world builder (level designer) for this project. It would be mighty interesting if some worlds had a gravity setting. I could see that affecting tactics and selection of weapons/machines. Also, have a value for atmosphere (density?) Again, perhaps some levels would be fought in/on a world with an atmosphere of mostly sulfur, etc... That would be neat.

The level designer could/should contain the mission builder. Your doc talked about the type of missions. I think it good to list them. You might want to add this...
1.) Destroy ONE main target
2.) Destroy various targets
3.) Protect ONE main target
4.) Protect various targets
5.) Destroy X enemies
6.) Destroy ONE main enemy (i.e. boss)
7.) Retrive ONE main object
8.) Retrive X objects
9.) Last X time units (i.e. for example, the The Alamo level)
10.) Haul X objects to position X
11.) Escort X objects to position X
12.) Reach position X in the world

I think with the abovem you can levels with just one of them and then in later levels combine objects. Before each level starts, lets make a cool de-briefing cut-screen.

I do like the idea of the night vision screen. I'd like to request a feature. Somewhere in the HUD or GUI/cockpit, the nearest enemy appears in a small 3d wireframe model. It rotates around once (or twice) showing the player what it looks like. i.e. Kind of like a 3d hologram. Did I explain that well? Anyhow, it would add to the polish. Use the same concept in the start of the game. For example, there are 3 type of tanks to pick from and they are shown on screen in wireframe. Move input device and model zooms up and spins around and vital machine stats drop down/appear.

Well, I have a lot on my mind, so I will sstop here. Anyhow, you can count on me for sounds, music, models, GUI and polish input.

Cheers

[Feanor]

Originally posted by Camacho
Could you package the code to go full-screen and send me the sit.? I think it would be nice to have some code for newbies to be able to switch to full-screen mode. No rush on this.
The downloads included the code didn't they? Are you saying you'd like a really little program that just did the switch? That would take, like five minutes!
A question I have... In some places I get the impression of a WW2 tank but in other sections I feel it is very SF. ... so, which? How about a crazy 1950's feel. I was thinking of a tank with retro fins...
I'm interested in seeing the world builder (level designer) for this project. It would be mighty interesting if some worlds had a gravity setting. I could see that affecting tactics and selection of weapons/machines. Also, have a value for atmosphere (density?) Again, perhaps some levels would be fought in/on a world with an atmosphere of mostly sulfur, etc... That would be neat.You're conspiring to keep us busy for years! Maybe I've been posting too much lately...

Somewhere in the HUD or GUI/cockpit, the nearest enemy appears in a small 3d wireframe model. It rotates around once (or twice) showing the player what it looks like. i.e. Kind of like a 3d hologram. Did I explain that well? Anyhow, it would add to the polish. Use the same concept in the start of the game. For example, there are 3 type of tanks to pick from and they are shown on screen in wireframe. Move input device and model zooms up and spins around and vital machine stats drop down/appear.
Those are great suggestions, and really wouldn't be that hard at all. Once the models exist, wireframe is the easiest thing to do. That could certainly be an eye-candy component of the HUD. The challenge (since I don't know how to do it yet) is making a mouse-pointer in OpenGL -- probably we'll go with keyboard input, at least at first. Now I have to work those requests into my 25-item priority list... FÎanor

[Feanor]

What would really blow people's minds is if we could figure out a way to draw wire-frames in OpenGL on a computer that looked just like non-scan-line monitors, where the beam draws the outline directly. That would require either a shader texture, a pixel shader, or dynamic lighting on the model. Ouch! -- FÎanor

[Feanor]

I still love using Scott Kevill's Quake 1 editor for the Mac, called Quiver. It was so great. The editor I make for HailStone is gonna be a lot like Quiver. I'll try to make sure it supports game missions types.

Here's some tanks I made in today in Quiver, and a crazy geometric sculpture I made last week (just 'cause I like to show off). Actually the tank is pretty boring, but I wanted to get my imagination going and take a break from writing and coding.

The outline drawing was a screen capture from Quiver in flat polygon mode, filtered in PhotoShop (Glowing Edges). The rest are from GLQuake (Fruitz of Dojo port).

http://homepage.mac.com/brentgulanowski/.Pictures/Various/tank1.jpg

http://homepage.mac.com/brentgulanowski/.Pictures/Various/tank2.jpg

http://homepage.mac.com/brentgulanowski/.Pictures/Various/Tank%20Outline.jpg

http://homepage.mac.com/brentgulanowski/.Pictures/Various/PrismRD.jpg

[Carlos Camacho]

As for my request... Yes, let us call it a simple little framework that contains enough code to get a newbie into what I call "a game state" for example, go full-screen, hide menu bar, fade to black and contains an about box. 8maybe a key-scan for Quit, etc.. Then "said" newbie can just start typing away their game loop. Simple, but useful for someone just starting out. If you have the time, that would be great. I'm others can download it and add in some other goodies (like comments) in the future.

Back to your game... You were talking about vector-based screens vs raster screens. Like a "scope" or Vectrex System/Asteroids. That would be neat.

I was thinking, do you know how some games have a SKIP-LINE/FRAME mode not so long ago? This helped to increase the FPS by skipping each other line. This effect also gives you that "TVish" look. It would be SUPER if the GUI's little monitors had this effect.

BTW.. Nice screen shots....

About the time period... I like the idea that the player is PLAYING the tank game INSIDE a SIM. This allows you to jump to different ideas for design and look. Could you render out some screen shots with solid colors and high specular lighting? I'm interested in that "Tron look."

Perhaps I should render what I was thinking in a 3D app to help you visualize it?

cheers

[Feanor]

Carlos,

The thing is, I just had a look at Apple's site, and they've already got nice sample code that does fullscreen, in multiple flavours:

(Platform, drawing environment, [language,] HowItGetsToFullScreen)

Carbon, 2D, QuickTime (ftp://ftp.apple.com/developer/Sample_Code/Graphics_2D/FullScreen.sit)

Carbon, OpenGL, DrawSprocket (ftp://ftp.apple.com/developer/Sample_Code/Graphics_3D/OpenGL_Full_Screen.sit) (also requires aglDrawString (ftp://ftp.apple.com/developer/Sample_Code/Graphics_3D/aglString.sit), which draws framerate using display lists)

Carbon, OpenGL, C++, CGDirectDisplay (ftp://ftp.apple.com/developer/Sample_Code/Graphics_3D/fullscreen_CGL.sit)

Funny I can't find one which does what mine does, that is: Cocoa, OpenGL, CGDirectDisplay. Now my example does have extra gunk in it, so I'll make a simpler version, but the code to do fullscreen with CGDirectDisplay looks like this:

-(IBAction)screenMode:(id)sender {

if( fullscreen ) {
[fullscreenContext clearDrawable];
[[self openGLContext] makeCurrentContext];
[theWorld setContext: [self openGLContext]];
CGDisplaySwitchToMode(kCGDirectMainDisplay, previousScreenMode);
CGDisplayRelease(kCGDirectMainDisplay); // release the display
fullscreen = NO;
} else {
CGDisplayCapture(kCGDirectMainDisplay); // capture the main display
CGDisplaySwitchToMode(kCGDirectMainDisplay, newScreenMode);
// check the error...
[fullscreenContext makeCurrentContext];
[fullscreenContext setFullScreen];
[theWorld setContext: fullscreenContext];
fullscreen = YES;
}
}

That's all there is to it, except that you have to have two separate NSOpenGLContext's (one for drawing in an NSView, one for full-screen). But I don't use NSOpenGLView -- it will automatically
switch if you give it a new full-screen pixel format. The action method above responds to a menu item (sender).

In none of these examples is it necessary to hide the menu bar. For Carbon 2D, the example above is really simple, perfect for newbies. (I'm not a Carbon developer, however, so I offer this link merely as a service.)

What I can't find is how to draw Cocoa 2D in Fullscreen, so what I'll do is research that. Probably one makes a window without the window title bar programmatically and then puts it on a layer above the menu -- I'll look into it and get back to you.

!!UPDATE!! -- OK, I created a Cocoa app that switches between a normal window and Fullscreen. It draws some OpenGL, but you can easily tear out the gl stuff and just draw NSBezierPaths or NSImages in the NSView. You can't really mix them, though, because OpenGL will just draw all over everything else. Um, well, you can have two separate views of course. That would require proper management of the frame rectangles and rearranging the view heirarchy (in the sample I just set the window's content view to the drawing view, where usually you drop all your working views into the content view, which itself draws nothing).

I've commented pretty liberally, but this is a really simple application. Cocoa simply ROX!

FullScreen Cocoa (http://homepage.mac.com/brentgulanowski/.cv/brentgulanowski/Public/CocoaFullScreen.sit-binhex.hqx)

FÎanor

[Carlos Camacho]

Thank you for that run down. Can you do me a HUGE favor? Go to the WIKI system set up for this site and add parts of that last post into the appropriate section. It would be mighty helpful.

BTW, where did you get that low-count polygon tank?

Cheers

[OneSadCookie]

Originally posted by Camacho
I was thinking, do you know how some games have a SKIP-LINE/FRAME mode not so long ago? This helped to increase the FPS by skipping each other line. This effect also gives you that "TVish" look. It would be SUPER if the GUI's little monitors had this effect.

The problem with doing that in OpenGL is that it slows things down a lot. Kind of a reversal of fortunes there :)

[Feanor]

Originally posted by Camacho
Thank you for that run down. Can you do me a HUGE favor? Go to the WIKI system set up for this site and add parts of that last post into the appropriate section. It would be mighty helpful.

BTW, where did you get that low-count polygon tank?

Wiki: sure, I'll do it after ST:TNG at 11 EDT.
Tank: I built the thing. Took about an hour or two to make. It's in a non-transferable format, though -- it's not a model, it's built out of Quake1 map brushes. I was just messing around. I could build it again in another format easily enough.

OneSadCookie, couldn't you just stick a foreground poly with a transparent/black striped texture? I guess it would have to be a big texture...

[OneSadCookie]

I guess you could do that, although you risk killing your fill rate... alpha testing rather than blending would help with that, but would it be enough?

The texture could be 1x2 (one black opaque texel; one black transparent) -- just set to GL_REPEAT in each direction. Should look OK as long as you're careful to line it up on pixel boundaries. Probably also want to filter it as GL_NEAREST just in case :)

It'd actually be interesting to see how fast that is.

[Pazolli]

These shots look fantastic, unfortunately I've been extrodinarily busy this last week and I'm dead certain I'll be extrodinarily busy next week too. After then though I'll be able to take a more active part in the project (both Hooptie and this).

Keep up the good work,
Mark Pazolli

[Feanor]

Originally posted by OneSadCookie
The texture could be 1x2 (one black opaque texel; one black transparent) -- just set to GL_REPEAT in each direction. Should look OK as long as you're careful to line it up on pixel boundaries. Probably also want to filter it as GL_NEAREST just in case :)

It'd actually be interesting to see how fast that is.
It's quite possible, given the look I'm thinking of for the game, that I could sacrifice some screen resolution to make up for fill rate.

Anyway, give me a few weeks, maybe I'll have some kind of experimental code as a test/demo, but I think special FX are pretty far down the priority list ;-).

My current thoughts are on how to get some initial content -into- the engine, since with the 3dkit, the engine already exists. So I've revised the priority list somewhat to put tool development on a parallel track. With a simple editor I should be able to start building some rectilinear levels. I have to think about things like level size and complexity and test the engine and see what it can handle, although I'm not terribly worried. So far it looks pretty efficient. Unfortunately I don't have access to any sample code or documentation besides the source (the manual is, uh, incomplete).

FÎanor

[Pazolli]

Feanor,

I still haven't gotten around to looking at your proposals yet (sorry). But I hope you're still keen about working with us. If you are, might I suggest you give me your SourceForge nick, login or user name (they're all the same thing I believe) and I'll add you to the administrative level of our project. Once this is done I'll give you a while to organize stuff and then we can look at CVS, licenses, updates etc. (It's not as scary as it sounds :-)).

Mark.