uDG: Cubic's Rube

[drzeip]

Hi,

I keep on putting up new builds of my game but I still haven't had reports of any bugs or anything so I figured it'd be better to get them out of the way first.

You can download it here : Download (http://www.apdg26.dsl.pipex.com/zeip/CubicsRube.zip)

The controls are just left and right and thats about i all i intend to use to keep things simple. Do you think there should be a few controls to change the view? For example making the center block transparent to see the other sides?

I'm a bit worried about the way i draw textures for the HUD as it does some funny hacking with Quartz. How does that display for you?

I think the gameplay is pretty self explanatory so far - match up 3 small blocks and score points!!!

Feedback would be very greatly appreciated

Thanks

David Rzepa

[arekkusu]

It's not that self explanatory. What's the difference between the big and small blocks? The rotating blocks? Slowly shrinking block? Bomb block? I thought maybe the large blocks would stop your cursor, but no.

It seems too easy with four faces and matching in sets of three. I was able to play a game for 5 minutes by just hitting the left arrow key after each column had filled up-- it cleared itself out by chance every time. Ended up with score of "10643198", I think that may be a bug.

Also, is the font supposed to be outlined? That doesn't read very easily.

Feedback-wise, it would benefit from some sound effects when you've completed a set.

Implementation wise: use Deployment style. Compress your bitmaps. Fix the viewport scale to the window size, so resizing works properly.

[drzeip]

Yeh i was thinking it was way too easy - i'm gonna have to work on some evil creature things or something that cause problems. Hmm maybe they could be called Rubes - that would explain the name more. Also I still have to fix the balance of how the next block is allocated - probably introduce more grey ( useless ) blocks or something. I have already implemented set matching of more than three but decided to stay with three for testing purposes.

The slowly shrinking big blocks multiply your score - red multiplies red matches etc. They shrink until they disapear and no long multiply.

The spinning blocks change any small blocks ( or grey ) below to the same colour.

Bomb blocks blow up other blocks!!!

Huge scores - crazy bug, haven't been too bothered to fix it yet - didn't find it important enough.

I'm already using Deployment style - what made you think i wasn't?

Bitmaps are compressed - tgas to be precise.

Sound effects are being left for last - my favourite part along with the music which is gonna be in time with.

Yeh that viewport scale would help with using fullscreen mode - I'll do that next.

I thought maybe the large blocks would stop your cursor, but no.


This idea sounds interesting. Any chance of some more detail to what you mean?

Thanks a lot I needed some other views. Just glad to see i didn't kill your computer. :)

[EvolPenguin]

Grr, so insanely fast, how are we supposed to see the block and move to the right spot before it comes out?

Alex

[arekkusu]

The multipliers make sense now, the spinners and bombs weren't obvious during gameplay. Maybe more elaborate animations would highlight the effects?

Re: Deployment style, your executable is 768k. 428k if I strip. What's making it so big?
You use ~40% of my 1.25GHz G4 just sitting idle. About 60% during gameplay. What's taking so much CPU? Hint: Shark says it's CoreGraphics. You must be rendering some Quartz content every frame. The font? Just cache that into a texture at startup and be done with it. This game ought to take about 5% of my CPU.

Re: compressed bitmaps, yes, but TGA format totally sucks. Let's compare:

Uncompressed 32bpp TGAs:
256K converter.tga
256K grid.tga
256K inert.tga
1M milton.tga
256K multiplier.tga
16K spark.tga
4K wick.tga
-------------------
2.1M total on disk

Your shipped compressed TGAs:
250K converter.tga
196K grid.tga
249K inert.tga
996K milton.tga
249K multiplier.tga
8K spark.tga
3K wick.tga
-------------------
1.9M total on disk (90% of original size)

Resaving as compressed TGA with 24bpp (except spark):
189K converter.tga
153K grid.tga
188K inert.tga
749K milton.tga
188K multiplier.tga
8K spark.tga
2K wick.tga
-------------------
1.6M total on disk (73% of original size)

Resaving as lossless PNG:
62K converter.png
52K grid.png
93K inert.png
458K milton.png
58K multiplier.png
2K spark.png
2K wick.png
-------------------
744K total on disk (33% of original size)

Resaving as 70% quality JPEG (except spark):
21K converter.jpg
11K grid.jpg
13K inert.jpg
73K milton.jpg
18K multiplier.jpg
2K spark.png
1K wick.jpg
-------------------
164K total on disk (7% of original size)


To preempt the "but they'll all be compressed anyway in the downloadable" argument, here's the size of the folders after ZIP compression from Finder:


996K UncompressedTGA.zip
1002K ShippedTGA.zip
961K 24bppTGA.zip
734K PNG.zip
144K JPG.zip


So, don't use TGA format. Ever.

Re: large blocks, I was thinking that the grey blocks would prevent you from moving the cursor past them. So if you built up a wall of 5 greys on the side of one face of the cube, you wouldn't be able to rotate past that until you managed to take out the top one. Not sure if that's a good idea or not, but that was it.

Re: insanely fast: GLUT apps have a global preference for VBL sync. If it is off, you'll run as fast as your CPU allows (1000's of fps.) You can force it on with some OS specific code. See my postings in this thread (http://www.idevgames.com/forum/showthread.php?t=6750).

[Edit: fixed listing.]

[drzeip]

OK. I understand everything you are saying and that it's important but it's a lot of work. Especially the bitmap stuff. Do you have a thread that can help me with this or even using PNG?

My CPU was close to hitting 100% so i thought something was wrong.

What do you mean by stripping it?? Is that dead-code stripping in XCode? What does it do? Remove any code that isn't being used in the libraries that you link to?

The Quartz stuff i figure i will have to make use of but I guess I could optimise it to only update the textures when needed using some kind of 'postUpdate' routine. This would mean drawing to it just once a second or so. Don't know why i didnt think of this before. Would you say this would help or do you think that using Quartz at all is a bad idea?

The reason i want to use Quartz for certain textures is that I need different coloured text for certain things and sooner or later I am going to be drawing special objects into the HUD. What are your thoughts?

Too Easy

I've been thinking about additions to the gameplay and have decided to introduce blocks that over time can force others to freeze up and become useless. The only way then to remove these frozen blocks is to blow them up, spin them, or match blocks up next to them to only partially 'thaw' them.

Insanely Fast

EvolPenguins: Do you mean that it is very difficult but playable or that it literally is too fast to see anything happening?

There is timing implemented into the game to keep it running at the correct pace so it should be ok.

Do you think showing the next two or even three blocks about to come would be a good idea?

Thanks a lot. I appreciate your experience.

David

[arekkusu]

First, sorry if I'm coming off as a stickler for efficiency. Efficiency is important (particularly to people with laptops that are melting in their laps) but obviously getting the game actually written and enjoyable is much higher priority. So don't stress too much over bitmap sizes and so on-- in today's world a 2 meg download is still tiny, it just would be nice if it was 200k.

That said, there are many threads on this board about texture loading, supporting various image types. Just search around. I know TGA support is easy to write yourself, but loading an texture in Cocoa is as little as two lines of code (not including setup or error checking.) What you end up doing mostly depends on your cross-platform requirements.

Stripping: first there's regular stripping. This removes the debug symbols the compiler has saved into your binary. In your build style settings, look for the "Strip Debug Symbols From Binary Files", "Deployment Postprocessing", "Produce Unstripped Product", and "Generate Debug Symbols" settings. Depending on your version of Xcode and your project template these may or may not be set up for minimum binary size by default. The wording may also vary.

Then starting in Xcode 1.5 there's also dead code stripping, which removes any code segments that you never actually call (in your own code or statically linked libraries.) See the "Dead Code Stripping", "Dead-Strip Inits and Terms", and -gfull settings.

Drawing fonts with Quartz is fine, I do that too. But you should limit the updates to when you really need them. In the case of a font, you can generate all of the characters you need (for instance MacRoman glyphs 32-255) at startup into one texture and colorize them at runtime with glColor4f and texture modulation. If your needs are more dynamic, for example drawing Chinese (thousands of characters, too many to cache at startup) or arbitrary NSBezierPaths then you'll have to continually update textures. But if there's any way to minimize the updates, do it-- Quartz provides very high quality rendering (sub-pixel LCD antialiasing etc) and has a high associated cost.

[drzeip]

Don't worry. I'm glad somebody has nudged me into optimising this stuff.

Ok I have optimised the drawing to Quartz and my CPU usage is down from basically %100 to just %30. I've also turned on dead code stripping etc and my file size is down to....2.9M??? OK something is going on. I wont worry about it till later though - I'm in the mood for gameplay and stuf!! :wow:

I have also implemented new gameplay ( the freezing, or infection as I think I am going to call it, of blocks ) which has made gameplay much much harder in my opinion. You nutters probably think zombies should still come and kill everything....

Anyway i think most of your suggestions are done except converting to PNG which shouldnt be too hard...

New Build Up Soon

Thanks arekkusu

David

[EvolPenguin]

yes, next 2 or 3 blocks would help.

Alex

[arekkusu]

Groovy. Regarding optimizing texture updates, you may also want to check out Apple's TextureRange sample code. (http://developer.apple.com/samplecode/TextureRange/TextureRange.html)

[drzeip]

ok i'll add this to the list ;)

[drzeip]

The links and stuff for the new build can be found on my blog here (http://www.udevgames.com/index.php?option=com_mamblog&task=show&action=user&id=108) .

Tell me what you think and if it is coming anywhere close to resembling fun yet?

I know i should really write a list of the blocks and stuff but...well thats just long. I think the infection stuff is the most complicated bit, the other blocks are simpler.

[drzeip]

A new build is up finally and i have thrown together a rough manual. Anyway the download can be found here!! (http://www.rzepa.dsl.pipex.com/zeip/CubicsRube.zip) ...

I think most bugs are ok. I know about the fullscreen stuff :mad: ..

There is only one question for you guys: Is it FUN??

Thanks

david

[Andrew]

Hmm... I always wanted a program that displays an empty black window! But seriously, this must be a bug or something—that's all I get! :(

—Andrew

[drzeip]

Hmmmm I don't get why that is happening. It works fine on all of my computers. :???: Anything turn up if you press return? Could be something to do with my Quartz drawn textures...

[Nick]

1.33ghz PowerBook G4 with 512mb ram and 64mb ATI video card. Mac OS X v. 10.3.5

When I open the program I see the icon appear on the dock, then it fades away and I get nothing. It fails to open on my computer.

[drzeip]

yeh i suck

The reason it doesn't open is because i'm not embedding openAl properly. I need a hand with that...

I just tried it on a g5 and i experienced the black screen death bug for the first time. At least i have something to work with now. Time to kill OpenAl!!!! :mad:

[drzeip]

OpenAl is gone and the black screen of death fixed. I know i'm going to miss out on a whole load of points for sound but I don't care - at least it works now.

Black screen of death - two bugs. Not allocating memory to a string and also forgetting to include the levels folder in my upload!!!

Fixed some timing bugs i encountered for the first time also.

The moral of the story - test for major bugs before you ask about the game!!! :rolleyes:

[drzeip]

All of the avove stupid problems are fixed and all should work now. Download link is in my signature.

Can i confirm that it does work? If so what kind of framerates are you getting?

Any major gameplay issues? Try out the various modes/levels by pressing left and right at the main menu and return to play. In the 'Some like to think' mode press space to drop the block.

I would explain the rules but I want to know that the included documentation explains it well.

Thanks in advance

David

[phydeaux]

I have to admit that I read the documentation and I still don't understand the rules. A tutorial mode would help, though I know it's rather difficult to do at this point.

Everything seems to work properly on my system, so that seems to all be in order.

[drzeip]

Yeh the rules are twisted. You're right a tutorial mode would help but I haven't even got time to sort out the essential stuff.

My best advice is just to match up the colours and try figure out the rest.

Thanks for replying

[arekkusu]

Something is really broken in the current build-- it uses 100% CPU and the rotation updates at about 5 fps. The older builds were 60fps...

[drzeip]

I've uploaded a new one since voting began. I was in a mad crazy rush for school so I uploaded the wrong build!! I think it should be ok now.

Thanks for mentioning it tho :)

Hang on...It was just the intro that was like that right?

[arekkusu]

It wasn't just the intro, it was during rotating in game too.

The new build fixes the rotation, it is 60fps during the intro. But rotating in game is gone completely-- it just instantly goes to a full on or diagonal view. It also still uses 100% CPU during gameplay. :(

[drzeip]

mannnnn.....i think this is some weird stuff to do with my computer being slow so it doesn't use %100 !!! sounds weird but i duno.....i'm gonna try setting the camera update timer to a lower value which should move the camera more slowly along with eating less cpu....

sigh, i've had so much to do recently :(

edit:

ok i fixed it now - was subtracting from the timer in order to keep accuracy ( dont know why i wanted that :rolleyes: )

thanks arekkusu, you've helped me out on a number of occasions now :)