Ovi Gaming - N-Gage and Ovi Store reviews

Heli Strike

Published by Steve Litchfield at 11:09 BST, June 4th 2010 under Games in N-Gage|| 10 Comments / Post New Comment

Steve Litchfield dons his flight helmet and heads out to do battle with texture mapped foes in his combat helicopter. Unfortunately, a shoddily implemented game title stands impenetrably in his way. Read on for his Ovi Gaming review, but be warned that this is one Ovi Store game you won't be recommending to your friends....

Author: Fish Labs
Version Reviewed:
Score: 53

The warning signs are there from moment one, if you're tuned in. The first thing you see is a sound options panel and you'll be tapping all over it trying to change the setting before you realise that you have to tap the word 'Sound' and not the blob or the actual setting. At this point, you start to think "Hmm.... maybe this is a port from another game platform and I shouldn't be surprised if things are a bit rough". 

Helistrike screenshot Helistrike screenshot 

Then, for a brief few minutes, things start to look up. A neat title screen (above, right) is followed by some super texture-mapped 3D modelled animation, seemingly being rendered in real time. Ships, planes, landscapes - not rendered incredibly fast, but usably so and your opinion changes to "Wow, there's some serious computer gaming in this title after all - it's definitely worth persevering with".

Helistrike screenshot Helistrike screenshot 

On top of all the texture mapping, a back story is built-up and you're introduced to your Apache variant, your helicopter for the game. You can skip this intro sequence if you like by tapping on the right hand advance icon:

Helistrike screenshot Helistrike screenshot 

And then the game starts. Which is where everything goes downhill. Although the main game engine uses the 3D models above, they're used incredibly sparingly and from a distance, presumably because of performance problems on non-accelerated Nokia smartphones (all the current S60 5th Edition devices). Worse, Heli Strike descends into a top-down 2D shooter - and not a very good one.

Your Apache can be moved within the flying corridor from left to right by tapping on on-screen controls, while tapping on the right-side bullets icon fires a salvo of something or other off towards enemy surface or aircraft. 

Helistrike screenshot Helistrike screenshot

So a standard game idea then. The twist here is supposed to be that by tapping on the up or down icons you can swivel the whole view into proper 3D (as if you're flying into the 3D landscape) - sounds good, but having done this, the game swivels the view back to top-down within a second or so, either by design or because (again) the processor can't keep up the frame rate in this view.

In addition, the frame rate when flying in simple top-down mode is poor, with your bullets and other craft stuttering around the screen as if on an underpowered, poorly specified device that's not really fit for gaming... oh, wait.

Within the constraints of Nokia's current hardware, Heli Strike could just have been rescued by making firing continuous and by implementing accelerometer control, both eliminating the clumsy screen tapping needed. A final nail in Heli Strike's coffin is that the 3D scenery is far more limited than the opening intro would have you believe - as the same island comes up in front of you for the tenth time in 5 minutes, it's easy to see where corners have been cut.

 Helistrike screenshot Helistrike screenshot 

I'd estimate that half the budget for Heli Strike went into the opening and help screen background animations. If not 90%. At which point the actual game engine itself was rushed out with little or no play-testing.

There is a seriously good 3D engine in here struggling to breakthrough the limitations of Nokia's mediocre touchscreen hardware - but the current version of Heli Strike merely hints at its potential. In the meantime, attack, attack, attack avoid, avoid, avoid.

Steve Litchfield, Ovi Gaming, 4 June 2010

Helistrike screenshot

Review Discussion

clonmult
That last image is mildly hilarious, for all of the wrong reasons.

I had one of the first ARM based devices, Archimedes A310. Running on an 8mHz ARM2 cpu. The lander game that came with it (for free) looked better than this by a long shot, with similar land textures. That was 20 years ago.

Its mildly embarrassing, either for Fishlabds coders, or for those doing the API design at Symbian, that 20 years of hardware/software development has led to a mild regression in graphics, despite having around 50 times the processing ability.
Unregistered
It is a combination of both so to speak.

1. The S60 5th devices from Nokia are bad at 3D because they have no 3D accellerator.
2. The game is implemented in Java, which is even slower at 3D.

However there is reason for optimism. I had the opertunity to try the new N8, and boy is it fast. It is in a totally other ball game compared to the S60 5th devices! And it is quite able to handle complex 3D games, unlike the N97 and 5800.
clonmult
Quote:
Originally Posted by Unregistered View Post
It is a combination of both so to speak.

1. The S60 5th devices from Nokia are bad at 3D because they have no 3D accellerator.
2. The game is implemented in Java, which is even slower at 3D.
You do not need a 3D accelerator to make good 3D games, you just need well written code. Fishlabs have done some great 3D games on java before now (had a few on the SE K800).

As I said, 20 years ago, there was quality 3D gaming on devices with an 8mHz processor. No graphics acceleration.
Unregistered
I agree. My point is that the S60 5th Java-implementation of graphics is very slow, and you cannot manipulate hardware framebuffers directly from Java.

Had the game been implemented natively in C, directly on top of the Symbian API, your points are valid. A good example of this are Polarbit's titles like Raging Thunder etc.

My point with N8 is that all drawing calls are accelerated, and it seems this also applies for the Java implementation in Symbian3, hence even Java titles will run much faster on the N8.
Paulo Pinto
You cannot manipulate hardware buffers from C either. The time where this was possible is long gone.

You have to do this by the OpenGL APIs, which are also a layer between your code and what goes on the graphics card.

But Symbian devices were always quite bad at 3D anyway. It still surprises me that Nokia has so few models with 3D processors, when compared with what the competition offers.

And lets not forget that the N8 is going to be the first model from Nokia to offer Java OpenGL ES support, when other manufacturers offer this support since ages!
clonmult
Quote:
Originally Posted by Unregistered View Post
Had the game been implemented natively in C, directly on top of the Symbian API, your points are valid. A good example of this are Polarbit's titles like Raging Thunder etc.
Bad example. The polarbit games look absolutely terrible - they're designed around a low resolution screen scaled up.

I've yet to see one 3D type game on Symbian^3 that really looks good. Plenty of top 2D/platform games.
Unregistered
clonmult:
"Bad example. The polarbit games look absolutely terrible - they're designed around a low resolution screen scaled up."

True, that the render resolution is 320x180 in Raging Thunder, and then scaled up to 640x360.
But why is this a bad example? This is my point - the Polarbit games are more or less what is possible _without_ a 3D accelerator chip, which neither 5800 nor the N97 has. Polarbit choose to prioritize framerate over resolution, which is a fair trade I think. The framerate in Raging Thunder would not be possible if the game was written in Java btw.

Btw. there are at least two software-rendered 3D games for the Symbian^1 5800 and N97 devices, that run at the full 640x360 resolution, and that is "Dance Fabulous" and "Creebies". Both can be bought from Ovi Store.

clonmult:
"I've yet to see one 3D type game on Symbian^3 that really looks good. Plenty of top 2D/platform games."

Really? Then you haven't been keeping yourself up to date I suppose.
Look here for some OpenGL 2.0 games running on the Symbian^3 based Nokia N8:

http://www.youtube.com/watch?v=FK48zrWxYHg -- (Rally Master Pro from Fishlabs and Bounce Evolution (the one known from N900) )

Some upcoming EA games for the Nokia N8 (propably ports from the iPhone 3GS) here:

http://www.youtube.com/watch?v=XZ6TyR2ZB2U
clonmult
Quote:
Originally Posted by Unregistered View Post
clonmult:
"Bad example. The polarbit games look absolutely terrible - they're designed around a low resolution screen scaled up."

True, that the render resolution is 320x180 in Raging Thunder, and then scaled up to 640x360.
But why is this a bad example? This is my point - the Polarbit games are more or less what is possible _without_ a 3D accelerator chip, which neither 5800 nor the N97 has. Polarbit choose to prioritize framerate over resolution, which is a fair trade I think. The framerate in Raging Thunder would not be possible if the game was written in Java btw.

Btw. there are at least two software-rendered 3D games for the Symbian^1 5800 and N97 devices, that run at the full 640x360 resolution, and that is "Dance Fabulous" and "Creebies". Both can be bought from Ovi Store.
So you see that you can't actually hold an argument here, can you? The platform is clearly capable of way more than Polarbit are doing, as demonstrated by Creebies (which I'd totally forgotten about, my bad!)

320x180 is lower resolution than what the old 8mHz ARM2 devices were handling in 3D 20 years ago (320x240, 3D racing or space flight sims). Tell me why a device with a 369+ mHz variant of the same processor can't handle even what appears to be a slight improvement?

I'm kinda irritated that software has somehow become incredibly bloated in the past few years, although its been a gradual "evolution".
Unregistered
@Paulo Pinto:
Yes, it's true that you cannot manipulate the hw screenbuffers directly, but you can manipulate memory buffers that have the same format as the target screen in C (and writing and copying/blitting arrays is much faster than in Java), this is not possible from Java.

Regarding OpenGL, I agree.
Regarding the few Nokia models that have, yes, I also agree that Nokia have been prioritizing badly in the regard, however it is pretty certain that this is history now going forward with Symbian^3 requiring OpenGL hardware as a minimum configuration to even work.

I wouldn't go as far as to say that all competitors has had OpenGL acceleration "for ages". The first Android devices did not, and Android only got support for it "recently" (about a year ago).

Regarding Symbian devices being bad at 3D - well, if you're referring to Nokia than yes, but both the Samsung OmniaHD and Sony Ericsson's Satio and Vivaz are quite capable, and in fact faster at 3D than the iPhone 3GS.

But no doubt, the N8 is the first in a long time from Nokia, and not a moment too soon.

@clonmult:

I do not disagree on any particular point, but you have to remember that what you refer to as "bloat" is not always so. I mean with abstraction comes vaste, yes. But as a developer I would really not want to go back to the "early days", where you had to do everything in assembly. The complexity in games and applications today, assembly would way to tedious to work with. Life is too short, and I want to get my games out before the platform I am working on is obsolete, before I am done. The old way is too time-consuming and inflexible. Sorry to say, I am an old dog as well, remembering the Atari ST and Amiga and Archimedes, but I am glad that sw development is easier today.

Lastly, regarding Creebies, yes it is an achievement, but the framerate is not nearly as high as the Polarbit games, luckily it doesnt matter for that games since it is not a "speed" game. A racing game or action game requires a high framerate (22 fps or better), and in this regard I think Polarbit did the correct prioritization. The problem is that graphics in the 5800 and N97 is rather slow compared to the screen size, and rendering the whole screen in full resolution at, say 25 fps, is a challenge to say the least, esspecially since the CPU has to do all the copying and also all the game calculations (physics, gamelogic, transformations etc.) every frame. Maybe Polarbit could have used even more time at optimizing, but it is propably not worth it.

With the new N8, everything will be much easier, since every single draw operation, blitting and transformations will, at the very least, be done by the GPU at vastly faster rate (5-6 times faster), and hence freeing up the CPU to do just the physics and gamelogic.
This is nice, because it will mean that the N8 will get a lot more games and entertainment software (propably a lot will be iPhone ports), because it is now very easy to do. This is a good for Nokia people ;-)
Unregistered
MOV Converter for Mac is specially designed for Mac OS X users which can convert various video and audio formats to MOV with just a few clicks, including avi, flv, 3gp, mp4, mpg, 3gp, mov, m4v, ts, tp, trp, mts, m2ts, tp, mkv, mod, asf, mp3, mka, wav, wma, mp2, jpg, bmp, ect.
In addition, you can customize watermark at will, such as set image watermark, text watermark, ect.
Category:
AVI to MOV Converter for Mac
FLV to MOV Converter for Mac
DIVX to MOV Converter for Mac
DVD to MOV Converter for Mac
MP4 to MOV Converter for Mac
M4V to VOB Converter for Mac
MPG to MOV Converter for Mac
WMV to MOV Converter for Mac
VOB to MOV Converter for Mac

10 Comments / Post New Comment

Copyright Notes || Contact Us || Privacy Policy (Ellie)