TimezAttack

We invite the community to download and comment on a pre-beta build of our multiplication game, TimezAttack. It can be downloaded here:

http://www.bigbrainz.com/TimezAttackBeta2.12.dmg

The game currently has only a character running around in a room, but it shows the progress in porting our existing product to Unity.

Some caveats:

The game immediately launches after installation (I'll change this soon)
The game initially launches in 640x480 fullscreen (or 800x500 on widescreen monitors)
On start-up, this version does a performance check of the hardware before entering game play.
On exit, the game launches a browser, uploads game performance stats and some hardware info to our database (memory, CPU, OSX version, video card info), then asks for comments--if you leave comments on the browser page, please specify that you are a Unity user. [EDIT--The uploading of data and asking for feedback is hardcoded to end March 1, 2007.]

Sorry if this seems a bit intrusive; we do all this to collect Mac performance stats from our typical user base prior to releasing a full version, and to see if the game crashes on anyone's machines. Please don't install the game if you don't want this data uploaded. Unfortunately, we don't have a web player available right now.

To uninstall the game, delete TimezAttack.app from the /Applications folder, and the TimezAttack folder from /Library/Application Support.

This pre-beta has one small level, but the final game will have the character running around battling various creatures by answering math facts.

Thanks, and please let us know if you have any suggestions.

 

Nifty. When I quit, it displayed credits, but did not ask for comments.

I noticed some kind of jitter in the frames. It seemed to be across both full screen and windowed, and in both low and high resolutions. (It's the sort of queasy jitter I have seen in some FPS demos. I'm using a 2GHz Intel iMac.)

 

i have the same mac as tsphillips and i did not get the comments page as well. are you receiving our computer info?

the environment looks great, for a kids game set in a castle i think you hit the right mood of dark but not too dark (emotionally involving but not scary i guess is what i'm saying). there are some issues with the character:

-there is a slight flicker which is especially noticable when stopped.

-depending on where you go the shadow can end up on the ceiling or the walls in odd places. i don't know if you were going for a cast shadow effect from the torches or its just an artifact of your shadow setup (projector?) - but it is noticable.

-the character doesn't "sit" well in the surroundings. its coloring, shading the jaggies around the edges make it stand out from your environment which on the whole is much tighter.

i know this is just a beta but figured i'd mention that as well.
overall really nice so far (great animations too ; )

 

PPC G5 Dual 2.0

When I quit, shows credits but no pop up window to submit comments.

Runs great and looks great by the way. I love the slow movement of the camera following the character.

I have the same thing with the shadows, depends on where the character is, sometimes I just get a straight dark line not very dark as in black color. I only notice it because I was looking for it.

My niece said your character is cute!

Ray

 

Pretty neat, although when I quit nothing happened at all. It just quit (no credits or comments). I'm on a brand new Intel Core 2 Duo iMac running Tiger.

 

Looking pretty good, very solid in fact. There are some texture seam problems and such, but nothing too glaring that it takes you out of the illusion. The floor breaking apart slowed my computer down to a crawl... if you're adding mesh/box colliders to each of those floor pieces you might want to just get rid of them (not necessary if you're going to fall through the floor anyway). Just let the pieces fall and disappear without the physics overhead.

The control is a little weird, the character bends his neck into some strange contortions trying to look forward. I'd try to mimick more conventional 3rd person control schemes.

Overall though very well done.

 

I really like the atmosphere of the dungeon and had no problems with the game slowing down on my imac ppc, even when the blocks fell. Everything went smoothly for me, and I got caught up in trying to escape. I almost forgot it was a test. Great job! The only thing that disappointed me was that I didn't learn to multiply.

 

You could have the blocks just fall thru and then rez or unalpha some blocks arranged on the ground, would drop the physics load on that a bit. Ran great on my machine tho. Dual 2.5 G5, 2Gigs of ram, 128 meg graphics card.

I do like the look, heck liked the look before on the pc version I saw you post, but it's good to see this is about to get a Mac launch.

I wish you the best of luck.

 

Thank you to everyone who gave us encouragement and suggestions on the forum, and on our feedback website. Your suggestions are exactly what I hoped to get (for example, I remembered that I needed to add fallback shader support on some materials for lower-end hardware--luckily shaderlab greatly facilitates this).

Sorry if this becomes a "fix my game" thread, but to maintain context I think I'll post a few questions here rather than in the support or scripting forums.

First of all, a few of our Mac testers (and some of the Unity users) don't get a browser popping up when exiting the game. We will only use this during our beta-testing phase, but I would still like to know what's going wrong. I use the code...

Code (csharp):

1. System.Diagnostics.Process.Start("open", url);

to open the web browser. How is this different inside Unity than the newer code construct...

Code (csharp):

1. Application.OpenURL(url);

which wasn't available back when I wrote the former code?

If they behave identically underneath, then the problem may be in the url, which embeds a number of key-value pairs to ship up to the server (perhaps the user's browser configuration limits the size of the upload url to a size smaller than I need). If this is the problem, or if it is elsewhere, I won't chase it down in the forum.

So the final question is, would using Application.OpenURL() make any difference from using the System call?

Thanks.

 

This is an issue that really bothers me, but that I have not been able to fix. It only shows up on frame rates higher than 20-25 fps. The symptom is manifest most when one rotates the view without moving forward, and it looks like stuttering or jerkyness in the normally smooth rotation of scenery.

The camera motion is modified using Time.smoothDeltaTime. I also tried my own very smooth delta time, I tried a slower, fixed frame rate (by forcing waits in an update function), and I tried placing the code in FixedUpdate() and in Update(), all to no avail.

I guess don't have a specific question, other than to solicit suggestions from anyone who has fixed a similar problem in their own game. The problem probably resides deep in the (rather involved) camera control code, and I'll just keep investigating the issue.

 

Thank you very much for mentioning this, aNTeNNa trEE. I do add box colliders to each of the floor pieces.

We use a frame rate control mechanism that includes, among other things, turning physics off for the stair blocks falling. However we keep physics in place for falling through the upper floor.

We certainly don't want things to slow to a crawl on most machines. On the other hand, we would like to use physics here if possible. The question is, how does your machine compare to our (yet to be determined) required and recommended hardware requirements for the game, and the hardware we have observed in our user base. We may need to change the gameplay in that location to not require physics.

aNTeNNa trEE, to give me a baseline comparison, would you mind sharing your CPU speed and number of cores or CPU's? You could use a forum private message if you prefer.

Thanks again.

 

Multiplying the axis value by deltaTime assumes a constant Input.GetAxis(), which obviously isn't right (it wasn't obvious to me back when I wrote the code!). Unfortunately removing the deltaTime multiply didn't seem to eliminate the problem. In investigating this issue more deeply, it seems that part of the problem is due to input quantization.

Ideally, we want the rotation angle to mimic what the mouse input was, like this:

Code (csharp):

1. float rotationInDegrees = Input.GetAxis("MouseX") * someConstRotFac * Mathf.Deg2Rad;
2. transform.localRotation *= Quaternion.AxisAngle (Vector3.up, rotationInDegrees);
3.  

where someConstRotFac could be 1 if we let the editor sensitivity control rotation rate. If the mouse movement were detected at perfect analog precision (in a make-believe world), then the GetAxis function correctly compensates for all inter-framerate differences. For exampe, if frame 2 took twice as long as frame 1, GetAxis() returns twice the distance for constant mouse motion. In effect, the deltaTime is "encoded" in GetAxis(). Even if the mouse motion were subsampled to high subpixel precision, we could get pretty close.

However, Input.GetAxis("MouseX") is quantized by the number of pixels the mouse covered in a given frame. A quick experiment showed that if the input Sensitivity is set to 1, Input.GetAxis("MouseX") appears to return .5 for the mouse moving one pixel to the right, 1.5 for three pixels, etc. I know Win32 only returns mouse movement in pixel increments, and I would guess that Carbon or whatever does too.

In my application I permit large rotations for small mouse movements, so this quantization interferes a lot with my desired rotation. Smoothing the rotation will only help so much, as it cannot compensate for the quantization, and in my experiments it does not reduce the artifact to below noticeability. One can see how higher frame rates exacerbate this problem, since the GetAxis() value becomes closer to the quantization rate.

Of course if I reduced my rotation-per-input unit, then the artifact goes away, but if I want to keep my high rotation rate, I need an additional solution. I'll keep working on it.

 

Thanks for that clarification, Joachim.

Upon further testing, I verified that I can get a non-zero GetAxis() with no visual mouse movement. That's great, in that it means the quantization problem is greatly reduced, and may not be my problem (and I wasted my time with a carefully crafted post).

I'll use an averaged mouse motion, and ask further questions if the artifact continues to be a problem.

 

Number of cores... I wish :wink: One "core" at 1.25 GHZ, PB G4, 64 MB ATI. My laptop is 3 years old now and I've never kept a computer for this long as my main work machine. But hell, it still gets the job done and I seriously don't see any reason to get a new one until every program I use is Intel compatible. In fact I could probably keep making artwork with this thing for the next 5 years if I wasn't aware of new tools coming out that made me jealous :wink:

 

I agree that it looks very solid. we tried it on an old dual 1.42 G4 and it ran smooth even on top resolution on a wide screen monitor. Nice shadows.Nice animation loops. only the jump seemed a bit too quick up-down. Was ready for more....

Seemed that you got nice video loops as textures and alphas for the fire. Would like to see your method for that.