Maizie Bones - The aMAZEing code a game comp entry

[BasicBoy]

Maizie Bones

Platform: Windows (I originally intended to make a cross-platform game, but I subsequently decided to stick with what I was most familiar with, especially given the relatively short 6-week duration of the competition).

Download link: http://www.proggies.uk/progs/zip/maiziebones.zip

Screenshots:

[RemiD]

@BasicBoy>>i see (understand) a few things that you have done in these mini games, this demonstrates understanding and skill, congrats 

[BasicBoy]

Just some long-winded remarks on some of the performance issues that I already know affect parts of my game (none of which, by the way, have anything to do with the game being mostly coded in a relatively slow, interpreted dialect of BASIC):

* Frame-rate independence: Most of the game is (supposed to be) frame-rate independent, using averaged delta times (8-frame averages in most cases, 30 in one particular case - see below). The trouble is, I used a fairly low-resolution timer via the standard Windows API call GetTickCount, which returns the current time in milliseconds - but not with actual real-time millisecond precision! I think the resolution is around 14 or 15 ms. Believe it or not (and I'm being totally honest here), in the final hours leading up to the deadline, I actually remembered that I had access to a much higher precision timer via QueryPerformanceCounter, which I had already used in a previous aborted compo entry. I had totally forgotten about it during the making of Maizie Bones. Incredible. The bottom line is: the supposedly frame-rate independent scrolling, sprite movement and other animation isn't as smooth as it could have been, and due to use of low-resolution millisecond timer, the game isn't as frame-rate independent as it could have been either. There are other reason why the game's animation wouldn't always be smooth on every PC, related to often poor VSync synchronisation (for efficiency, Maizie Bones uses the raster polling method, rather than tying up the CPU in waiting in a tight loop for the VSync 'signal' - that option's available, but your CPU will get very warm!).

* Blue Monster Hunter (minigame): This uses Direct3D (Direct3D 8, to be specific) to render the scene. This game should run much, much more smoothly than it does. I don't know why the performance is as bad as it is - it could be related, at least in part, to the frame-rate independence & VSync issues described above. But actually, the main reason I suspect is that I didn't implement any kind of occlusion culling (probably because I didn't think I needed to!). Anyway, by the time I realised that occlusion culling probably was necessary after all, it was too late - I was running out of time. I would probably had to have re-coded the whole minigame. The 3D Maze object is one single object, and due to lack of occlusion culling, the GPU is rendering/z-buffering dozens of flat-shaded walls that cannot ever be seen from a particular vantage point. This is immensely wasteful, but I didn't consider it a serious enough issue when coding this minigame. I will try to pin down the exact reasons for the relatively poor performance of this minigame.

EDIT: After all that, it appears -- after some testing -- that the lack of "occlusion culling" almost certainly has nothing to do with the performance issue! I've just discovered that I didn't in fact employ *averaged* delta times with this particular minigame, which is really not good. Also, I was messing with the process priority (raised it to 'above normal') just prior to calling the 3D scene rendering function, which I don't think was a bright idea.


* A Maze In Sphere (minigame): Scrolling is really not smooth at all on any of the 3 PCs on which I've tested the game. I currently don't know why, but I have my suspicions. Two of the reasons will probably be as described previously - low-res delta times, and poor VSync synchronisation. But then if that was the case, why is the scrolling in the 'Treasure Tower' subgame much smoother? With 'A Maze In Sphere' I resorted to averaging the delta times over 30 frames to really smooth things out, but the result was still not satisfactory. I noticed that when I removed frame-rate independence and used a fixed, constant delta time of 15 milliseconds, the scrolling was practically perfectly smooth! Hardly any glitches at all. So I'm a bit confused about why the performance with this minigame is especially poor.  What I suspect is the real culprit (and it's entirely my fault), is so-called 'cache thrashing' (look it up!). A bitmap is 'mapped' (roughly) to a sphere, but instead of being sensible and scanning the source bitmap horizontally in a nice, cache-friendly way, I instead scan through the source bitmap data vertically, which thrashes the f**k out of the (L2?) cache. That's what I reckon's going on. The 'Treasure Tower' minigame, which usually scrolls smoothly, uses a practically identical routine, except that the source bitmap offsets data is arranged so that the source bitmap is scanned pretty much horizontally, so in a much more cache-friendly manner. I didn't have time to re-code the sphere-mapping offsets generator, but I really wish I had done. Of course it's possible that 'cache-thrashing' has nothing to do with it, but that remains my chief suspect.

* Noticeable pauses when music sections loop:  You will probably notice that every time a section of music loops, the game pauses momentarily (and sometime not so momentarily!). This is an issue with the ancient method I use to play music (the Windows MCI).  Short of using an alternative means of playing music, I don't know how to fix this.


David.
--



 

   

[Derron]

Can't you use some kind of "framework" you write for your games? Just to have "fix once and forever" options ;-)

Create a timing class, create a music player (with crossfade option or gapless playing) ...


Nice idea to do minigames (not tried them yet).


bye
Ron

[BasicBoy]

Can't you use some kind of "framework" you write for your games? Just to have "fix once and forever" options ;-)

Good idea 


David.
--

[BasicBoy]

I have just uploaded an updated version of Maizie Bones to my FTP area.

Here are the modifications I made:

* The poor, jerky performence of the 'Blue Monster Hunter' subgame has been improved a bit (although at the cost of higher CPU usage). The game still doesn't run totally smoothly, but it should be better than it was.

* The game now pauses when the window loses focus (and the music pauses too). The fact that the game is paused is also indicated.

* The averaging of the frame delta times has been reduced from 8 to 5 frame averages (8 was a bit excessive, I think).

I hope the above modifications are permitted. If not, I'll withdraw the updated version and replace it with the original one.

EDIT: Version 1.02 uses a higher resolution timer in an attempt to improve performance (smoother scrolling, sprite movement, etc.), but most players probably won't notice much if any difference.

Download link for Maizie Bones v1.02:

http://www.proggies.uk/progs/zip/maiziebones.zip (~15 MB, Windows only, extract from Zip folder before running).


David.
--

[Derron]

just insert "correctly" here and there so it sounds like a fix

* The game now pauses correctly when the window loses focus (and the music pauses too). The fact that the game is paused is also indicated.

It's just a matter of finding the right words ;-)


seriously:
For the other two things - they are no "game-wise features" so I do not see problems there.

[therevills]

Wow! Great submission, so many mini maze games! Top job!

[Steve Elliott]

Wow! Great submission, so many mini maze games! Top job!

Totally agree.  The Orb Collector (Thrust) game could be developed into a full game in it's own right.  So could that 3D Monster Maze/Ghost hunter game.  Obviously written by a programmer who knows what he's doing.  It ran silky smooth here, although the scroll window was small. 

[Xerra]

Wow! Great submission, so many mini maze games! Top job!

Totally agree.  The Orb Collector (Thrust) game could be developed into a full game in it's own right.  So could that 3D Monster Maze/Ghost hunter game.  Obviously written by a programmer who knows what he's doing.  It ran silky smooth here, although the scroll window was small.

That 3d maze mini-game was freaking me out - seeing those Pacman monsters closing in on me. I kept getting bloody cornered by them even on a respawn which kind of put me off a bit. I suspect the reactions I had were very similar to how people must have felt playing the old ZX81 3D monster maze at the time.

Think you could probably have made a competent enough game out of that part alone so the whole package is pretty impressive. Got to say I disliked the ball bearing in the rotating maze bit. Technically, it's a good bit of coding, but the rotation was too slow for me to get it off the second line. Not sure if that was just me, however.

This game is going to vote well, I think, just on the amount of game in there alone. And what's been said earlier is definitely true. The coding has to be pretty good to do some of the stuff that's going on here. Would scare the shit out of me trying to attempt stuff like that rotating maze.

[STEVIE G]

Excellent work. 

The game crashed for me when I was just about to start the 'Treasure Tower' game though.  I have an old rig - specifically so that all my games work on anything so that might be the reason if you're using fancy shaders etc..?

[BasicBoy]

Excellent work. 

The game crashed for me when I was just about to start the 'Treasure Tower' game though.  I have an old rig - specifically so that all my games work on anything so that might be the reason if you're using fancy shaders etc..?

Thanks for the feedback, Stevie.  I think I know what the problem cause is (and I thought I'd already fixed it a week or two ago), but can you try downloading & running this test version of Maizie Bones -- it launches pretty much straight into the 'Treasure Tower' subgame. Does it work this time without crashing (even if your hatted man character doesn't animate properly)? Keep your eye on the program window's title bar. After you try to move, does it say something like "Error 1:  F% is negative!" ?

If the subgame still crashes then I'm currently clueless as to why that is (could be a memory leak -- which would be scary because it could be an absolute pain to track down).

'Maizie Bones' doesn't use any shaders - it's all software-based rendering (with the exception of 'Blue Monster Hunter' which uses Direct3D 8 ).

Here's the link to the test version, if you don't mind trying it:

http://www.proggies.uk/temp/mb_103x.zip  (as usual, extract before running)


Finally, did the 'Blue Monster Hunter' subgame work okay for you (assuming you've tried it yet)?


David.
--

[STEVIE G]

Excellent work. 

The game crashed for me when I was just about to start the 'Treasure Tower' game though.  I have an old rig - specifically so that all my games work on anything so that might be the reason if you're using fancy shaders etc..?

Thanks for the feedback, Stevie.  I think I know what the problem cause is (and I thought I'd already fixed it a week or two ago), but can you try downloading & running this test version of Maizie Bones -- it launches pretty much straight into the 'Treasure Tower' subgame. Does it work this time without crashing (even if your hatted man character doesn't animate properly)? Keep your eye on the program window's title bar. After you try to move, does it say something like "Error 1:  F% is negative!" ?

If the subgame still crashes then I'm currently clueless as to why that is (could be a memory leak -- which would be scary because it could be an absolute pain to track down).

'Maizie Bones' doesn't use any shaders - it's all software-based rendering (with the exception of 'Blue Monster Hunter' which uses Direct3D 8 ).

Here's the link to the test version, if you don't mind trying it:

http://www.proggies.uk/temp/mb_103x.zip  (as usual, extract before running)


Finally, did the 'Blue Monster Hunter' subgame work okay for you (assuming you've tried it yet)?


David.
--

Treasure Tower now works - thanks!  I hadn't got to the Blue Monster Hunter game yet but will try it at some stage next week.

[BasicBoy]

I'm currently in the process of playing/assessing everyone else's games (and recording myself doing so via Bandicam), but in the meantime here's a video I recorded of myself playing my own game (Maizie Bones). This video might be of interest to those who don't have access to a Windows box!

https://www.youtube.com/watch?v=0wAhM3fQU9g

[Derron]

Small side note: your game would run on linux - with wine. It flickers a bit occasionally. But you it errored out to not be able to load a specific image file: "Maizie Bones/Resources/maingame/gfx/maptiles/sometile.GIF". Linux and Mac systems are using a case sensitive file system - so "image.gif" and "image.gIF" or "Image.gif" are different files.

Dunno if your engine/bbc could compile for linux/mac too ?


@ game itself (executed via native Windows then)
I think the idea of having "many" small games in one single game "hull" is adding a lot variation (and stress for you as programmer ;-)). Graphically it could ...well... be better. In other words: with some polishing here and there the game could be a pretty entertaining and well doing at the same time. In its current state the music was cool but the graphics kind of "put me off". They had a "game maker 2k"-charme of games I played 15+ years ago. Maybe create a game less and improve the visual appearance of the other games. You seem to be a skilled programmer so why not use the chance of these competitions to begin improving GFX wise?
As said: the games itself are a cool "mix" but the visual appearance is what needs improvement.
Ok, and the "fake 3D labyrinth with balls" (forgot the name of the level) had some clipping issues when bouncing into the walls - or slowly approaching a collectible (the collectible is drawn after the forward moving player - but is still not collected).


bye
Ron