Hanuman Typing Warrior [Version 1]

Comment

Comment by Dr. Mike Reddy on April 26, 2010 at 1:49pm

A couple more things occurred to me:

1) Adding a Splash and start screen, and a "well done" end screen would be good at this stage, to envelope the actual game play.
2) There is a lot of screen allotted to the sky. Is this really necessary? Is a later section of the game going to be in the air or on the mountains?
3) The character model merges with the background, particularly the feet on the green (grass?) background
4) The character is very pale in contrast with the dark edged rest of the game assets, which does allow him to stand out from the background, but presents two different "styles" on screen.

Still looking forward to the next version!

Comment by Dr. Mike Reddy on April 26, 2010 at 1:44pm

OK, here are some comments on the prototype; please note that as a professional lecturer I can give the Gods a list of criticisms ;-)

What you have is the "toy" beginning of your game. The toy is what game design teachers recommend that students build before putting in great effort on all the assets required for a polished game. The basic game play and interaction for your game concept are defined: this is a gated side scrolling game, where players must type correctly to overcome a temporary obstacle. Certain things stand out at this stage:

1) No sound - on the one I ran anyway. It's never too early to start with audio, even if it is a beep, as it shows that you are thinking about the way in which the game signals opportunities and threats to the player
2) No challenge - what separates the toy from the game is the communication of a goal to achieve and an obstacle/penalty for not achieving it. An example would be punishment for incorrect typing, or a limited time to type the word. Not penalising players for incorrect typing MAY have been a legitimate design choice, with the implicit penalty being just a slightly slower achievement. However, this prototype had a significant bug, in that if you type too fast the key presses are not recognised. So, I am being penalised for being able to touch type!
3) No variety - this is forgivable in a toy/early prototype, but there should be some variation in the visualisation of sub-goals, game play required, etc. e.g. how about having to type the word backwards, or showing it in reverse. Another alternative would be showing RED in green text and requiring the player to type GREEN. A further one would be nonsense or random letters as these test awareness of the keyboard much more deeply
4) No lower-case - If you look at the font you are using "A" and "R" look very alike. Having lower case AND punctuation in your game would improve readibility and extend the range of the game. Having the scope to allow phrases and sentences, which could actually be used to impart story - "Hanuman threw the spear" - would also be useful.
5) No polish - this isn't a criticism, but rather things to consider: The clouds and the scroll and run animation need some work. For example, the clouds could/should move independently of the background and the player character. The run and scroll, then scroll between obstacles doesn't feel quite right; it de-emphasises the player character, which seems counter-intuitive.

What works really well: The concept of how to interact (type the word shown) and the low-level reward (bashing the obstacle) are really clear. The graphics and background, etc, are really high quality. The character animation is just right - the bashing of the stones, the look at camera when the scroll continues after the run stops, etc - in that it makes the player feel that this sprite has some identity. And, most importantly, you have that first build and are putting it out for criticism/comments. This is not to be underestimated, as peer review is how good games become great, and bad games are not allowed to suck time and talent from better projects. Fortunately, your Hanuman game is the former.

Comment by Frank on April 14, 2010 at 10:10am

I had no problem getting it to work after setting up the keyboard controls. It's nice game, I like the concept of Hanuman moving forward with every keystroke. I also think the graphics are good the way they are now. I did noticed that if you type too fast, it won't register the keys (maybe that's an issue with the emulator). It would be nice to have a sense of progress, that Hanuman is actually going some place. e.g. a new background every 10 words or so. Or maybe just develop some sprites and clone them in different ways to generate different backgrounds as in the Mario games. It could also be interesting to have one 'rock' for each letter in the word. So big, complicated words would consist of a bigger tower of rocks.

Comment by nomadHAR on April 10, 2010 at 10:43am

i had set it up exactly as you described, but nothing works.

Comment by Kishan Patel on April 9, 2010 at 9:59pm

you have to enable the "Family Basic Keyboard" before it starts accepting inputs. I have described the procedure above for "nintendulator0960bin_unicode" emulator which I have also included. You can use any other emulator using similar configuration.

Comment by nomadHAR on April 9, 2010 at 2:44pm

i downloaded it, but it doesn't do anything. it doesn't respond to keyboard presses or controller buttons. the screen above is the only screen that appears.