A new game : Feedback required

Hi all

I’m going through a process of self education for game design. My current " exercise ", now complete, is a game. A shmup game. I would appreciate it very much if anyone would like to playtest it for me and give me some feedback on what I am doing right / wrong with the design. The game runs in 640 × 480 @60hz and includes a !Help file to explain the game and its features. It runs okay on PI2, Iyonix and StrongARM RISC PC. However I have issues with both Iyonix and RISC PC in that both machines I believe have some sort of hardware issues which makes it impossible to be 100% sure that it works okay on these machines but what I have been able to achieve in game time has been fine. There is however, on PI 2, a rare bug where it crashes and hangs the machine but in my experience I have played it dozens of times without instance.

This is a link to a video of the full game play ( 5 levels ) for those interested : https://www.youtube.com/watch?v=zle8vCvNij0

Thanks for any feedback

Greg

Swarm in space!
I would love to play, loose and rage quit this game :)

Yes I also think that it looks very good but also I am sure I wouldn’t be able to finish the 5 levels without a lot of practise ;-)

@ David
Thats great. If you could let me know where to send the zip file I’ll send to you.

@ Michael
If you would like to playtest for me let me know where I am sending the zip file. There is a !Help file included that, hopefully, explains the game features well enough in that it may look like the game is really tough but you actualy have quite a bit of control over your demise. Yes practice does help a lot.

EDIT : As an after thought I thought I’d better say that the game uses the default framerate that your setup uses for 640 × 480. So, it may run faster if your hz is >60 or slower if your hz <60.

Thanks for your interest.

Greg

Hi greg
I’ve watched the video of your Shoot-em up and these are my thoughts.

1. The intro screen looks very professional with great looking background and matching colour scheme. very nice.
2. The Intro Text moving in and out of the screen also looks nice and professional.
3. The Level One intro has the stars scrolling very fast and gives a great sense of what might be to come during the game.
4. As Level One starts the stars slow down too much and loses the sense of speed and excitement that I think you had built up to this point. That was a shame.
5. The enemy ships needed to have more sprites to show a sense of vertical movement, as did your own ship.
6. The power-ups sprite would look better if there are bigger.
7. The enemy power-level indicators are a really nice touch and looked nice.
8. Would be better with some music.

I really liked what you’ve done and I think with a little bit more work could turn into something pretty cool indeed. Hopefully my feedback doesn’t come across as too negative; there are lots of positive to take away, especially as it’s your first attempt at a shoot-em up.

If you want to send it for further ‘testing’ send to nxWibblenytrex.com. Replace the Wibble with the @ symbol.

Here is a link to a very cool shoot-em up on a very old 8-bit console and shows what can be done with low-end hardware. https://www.youtube.com/watch?v=2b6YOKIoGLg

Yes, I would like to give it a try and see how far I get. Not sure I will find time before the weekend hope that’s ok. You can send it to m.gerbrachtWibblecityweb.de using Alans encryption ;-)

@ Alan

Thank you very much for your kind remarks. Better than what I expected. Thank you. With regards to point 4 the idea of the fast stars was to imply you was rushing of to the sector you have been assigned to and the slowing down was to imply your arrival. I don’t understand what you are trying to convey in point 5, could you explain a bit better please. With regards to music there are 2 reasons.

1) Music is absolutely not a strong point for me and

2) Since this project was only an " exercise " in learning the skills in game design, hence me looking for feedback and play testing, it was not going to be a fully polished ready for release game so never really looked into it.

Your feedback has absolutely not been negative. I will send you the zip file for play testing.

Many thanks again

Greg

@ Michael

Thank you. Will send you the zip file

@ Alan

Ive seen Gradius and a whole bunch of other shmups to try and get an idea on where i should be going.

Greg

Zip sent Michael and alan.

Cheers.

Greg

on a very old 8-bit console and shows what can be done with low-end hardware.

The Famicom clones tend to be a 6502 core hooked to a tiny amount of RAM, equally tiny VRAM, and a fairly complicated hardware sprite handler to make such games possible.

Take a look at this for an example:
http://www.vrt.com.tw/old_site/admin/upload/datasheet/VT16%20Data%20Sheet%20RevisionA7_ENG_.pdf

BTW, Greg, what’s your game written in? BASIC? C? Assembler?

Its written in assembly Rick using BASICS assembler. Don’t tell me off :-), I know how much you like high level languages and another assembler.

Hi Greg
regarding point 5, I think it would be better to display different player/enemy ship sprites when they move up and down; that way it shows a extra level of movement to your game. i.e player ship would look like it is yawing to the left when moving up, and yawing to the right when moving down.

@ Alan

I see what you mean. I did consider this for the player but since my animation skills are non too good either all my sprites were acquired from free to use sources and couldn’t find at the time anything that I liked. But yes I agree with you, more animation on my sprites would be desirable

Send it to the usual place: temp1267@riscos.fr
Thanks!

Ive sent the zip file David.

Thank you

Greg

Don’t tell me off :-)

:-) It’s your choice.

I know how much you like high level languages

The liking of C these days is because both Norcroft and GCC are competent enough to output decent compilation, so it makes sense to use a high level language and leave all the nit-picky little details to the compiler to deal with. I’d rather think up a better algorithm for shoving aliens around the screen than worry about what is stacked and when.

Additionally, the ARM has suffered a number of breaking changes in its behaviour. Not just the 26-32 transition, but rotated loads, deprecation of SWP, and so on. Compiled code can, of course, suffer from these issues just as much as anything else (compiler release 5 of the Castle era seemed in love with using rotated loads). The difference is that “fixing” the problem with high level code usually means just rebuilding the project with an updated compiler. With assembler, it needs to be gone through. If you’re lucky, it’ll be a simple fix. If you’re unlucky, you’ll find all sorts of flags stuffed into addresses and applied magic that requires the use of a whiteboard to work out what the hell is going on. There’s a reason RISC OS itself has been 32bitted, but Impression still hasn’t. ;-)

I used to like assembler, back when processors were 8MHz and you needed it to get any useful speed out of the machine. But with processors being 800MHz+, there’s less necessity.
Doesn’t mean I never use assembler these days, sometimes I write stuff in it “just because”.

and another assembler

Nothing wrong with BASIC’s assembler.
I just use ObjAsm now as it outputs stuff that can be linked with C; and you don’t need the preamble (P% = code%, FOR pass% = blah TO blah STEP blah, etc etc).

If you’d like a play tester (ARMv7 Pi2) by somebody who sucks at games and has the coordination of a dead goldfish, feel free to send me a copy. I’ll be happy to see if I can break it!
rick -at- heyrick -dot- eu

Rick I’ve sent a copy to you. Thank you.

The main reason why I code in assembler is because Ive always done so and also nowadays I don’t get a lot of decent time where I can concentrate on coding so I simply take the route of “least resistence”, I use what I am most familiar with. Not that this makes me a great programmer but it gives me the opportunity to be the best I can be while I still have an interest in codeing. I’m not getting any younger you see. Who knows, In the future I may not have a choice in what to use and then I will have to decide if I still want to code or not…..

For now though assembler it is.

Not played it but the YouTube video looked cool! And any ASM programmer is automatically a good programmer imo hah, watched a few commodore video tutorials and completely lost :P

Nyt!

Thanks for the nice thoughts Nyt. What RISC OS machine have you got ?

Thanks Greg. It doesn’t work, since with my recent ROM, all 256 colours mode are black with only the cursor :)

I’ll try on a vanilla 5.24 ROM later.

Thats not good. I would be lost without my machine. Its what I get up for on my days off :-)

since with my recent ROM, all 256 colours mode are black with only the cursor

That may indicate you’re still using 2018 firmware. Try it with the latest firmware instead.

Be aware that the 5.24 ROM won’t work with the latest firmware.

I am using a RPI2 Risc OS 5, might see if I can download it when I get a moment.

Nyt.

Thanks Stuart!