This is an alpha version of the game I’m working on for the coding competition.
The story, objective, and controls are all explained in-game.
The source is not included, but it will be when the game is done.
What’s already done:
– The thing system.
– Collision detection against screen edges, and between the player and enemies (not very precise however).
– The AI for two things: the sattelite and the space rock. The rock uses a “ship” sprite because its sprite isn’t done yet, and I suck at drawing.
– The font.
What’s not done yet:
– Shooting. You’re defenceless.
– The game over screen.
– The score counter.
– A lives display.
– Saved games on SRAM, maybe?
– Level switching. I don’t actually know when the player should be brought to the next level.
– The remaining two enemies.
– The scrolling background with stars.
Bugs:
– Sometimes a thing will appear “cut off”, and sometimes it will move very fast in one direction. I have no idea why this happens.
– The random number generator doesn’t always work right.
I welcome your ideas, questions, suggestions, and comments.
By the way: the game is prepadded. Its ID is “SU” and my developer ID is “MH”.
Attachments:
I just tried it on a FlashBoy, and it works up until you try to start the game. It then keeps stopping and displaying the ‘read instructions’ screen. Press start again, bit of movement, then back to the screen again.
Yeah, that’s what happens in Mednafen too. Did you even try this yourself? :thumpdown:
Nice intro though :thumpup:
It works in Reality Boy, I guess that’s where HorvatM tested it in? It has many bugs, though. But as he said, it’s an alpha version, so I did not expect anything else.
Are you going for something like Vertical Force? Using a second layer?
Added the codes to the Dev Wiki.
Hm, I don’t use Reality Boy anymore… I think everyone should really switch to only use Mednafen, it really is the better emulator in almost every aspect. (the only exception is that it lacks a char/map viewer).
I didn’t mean to sound like a douche though, sorry about that. It’s a good start for a game 🙂
I just tried it on a FlashBoy, and it works up until you try to start the game. It then keeps stopping and displaying the ‘read instructions’ screen. Press start again, bit of movement, then back to the screen again.
Yeah, that’s what happens in Mednafen too. Did you even try this yourself?
It works in Reality Boy, I guess that’s where HorvatM tested it in?
Yeah, I used Reality Boy for testing, but it also worked for me in VBjin (with a big decrease in speed). Isn’t that just Mednafen with a GUI? Weird, because I only use basic stuff; 2 worlds and 272 objects. The only thing that happens on the title screen is that the random number seed gets set, which I do by incrementing it in a loop, overflowing and rolling over in the process. Maybe that causes it to reset for some reason?
It has many bugs, though.
Besides the ones I listed, and the one where you get trapped after dying, what ones did you encounter?
Are you going for something like Vertical Force? Using a second layer?
Well, I envisioned it as a strictly 2D game with a 3D background. Having a second layer would also require me to make new sprites and animations for transition, as well as redesign the collision detection and thing system.
I’m not completely sure about the gameplay either. Right now, everything is generated randomly. This would mean that levels would be all the same, maybe with differences in the number of enemies and their speed.
Like I said, ideas are welcome.
(PS: if someone can make a “space rock” sprite, 32*32 (4*4 chars) in size, it would be very appreciated.
- This reply was modified 14 years, 4 months ago by HorvatM.
I just compiled it again (with a few additions and modifications) and VBjin indeed gives me frightening messages:
Immediately after boot:
Unknown HWCTRL Write: 02000008 80
Unknown HWCTRL Write: 02000000 14
Unknown HWCTRL Write: 02000004 ff
If those are addresses and values, they appear to do something with the link port, according to the Dev Wiki. But I don’t access the link port!
And then, at the start of the actual game
Exception: ffffff60 ff70
which, again according to the Dev Wiki, is “FIV (float invalid op)”. That makes sense, because my random numbers use floating point operations. But I don’t understand what causes it.
It’s probably a loop somewhere that goes on for to long and overflows and make you write to places you didn’t intend to.
It’s a little hard to troubleshoot without the source code. If you’d like me to take a look but don’t want to post it in public yet, you could pm me with it and I’ll try to help.
It looks like you’re multiplying a constant(loading immediately before the mulf.s) floating point number by a denormal. The V810 will never(AFAIK) generate a denormal as the result of an FPU operation, as any result that would be a denormal is replaced with zero.
…and on another run, it looks like the result of the mulf.s instruction is larger that can be expressed in an integer, so cvt.sw is generating an exception.
Would it be an incorrect guess that you have no idea how your random number generator works, nor its mathematical properties?
Would it be an incorrect guess that you have no idea how your random number generator works, nor its mathematical properties?
Maybe. It’s not really a generator, just a list of single-precision numbers between 0 and 1 (non-inclusive), and at the title screen loop there’s a counter which is incremented every iteration and determines the point in the list where the numbers will begin reading. The function which gets a random number just increments the cursor and returns the number at that position.
I did a couple of changes and it works in VBjin. Never mind how I did it.
I’m having some trouble. The code that’s supposed to create things doesn’t work now that I’ve switched to a level-based system. Additionally the code could use some optimization.
If anyone wants to help me, please send me a private message.
Alpha 2 is here!
What’s new:
– A scrolling background.
– A level-based system. A prototype of what I consider level 1 is included.
The story/controls screens and collision detection were disabled for this version. The former annoyed me when testing and the latter doesn’t make much sense because the level doesn’t restart on death.
A big thank you goes to DanB who made the level-based thing creation work and otherwise improved the code.
Attachments:
it needs a lot of work but its looks very good
Would have been better to have a side scrolling shmup game but wont complain to much
For what it is it looks good
planning on going in and out of the background like in vertical force?
Would have been better to have a side scrolling shmup game
Now that you mention it, it would have probably made more sense to take advantage of the screen dimensions and make it a horizontal shooter. But I think that people are more familiar with vertical shooters (1942, Galaga, Space Invaders, Vertical Force, etc.) so I’m keeping it vertical.
but wont complain to much
For what it is it looks good
Thank you.
planning on going in and out of the background like in vertical force?
No. It would make programming more difficult and it would require more sprites. And I plan to port this game to other platforms.
Now that you mention it, it would have probably made more sense to take advantage of the screen dimensions and make it a horizontal shooter. But I think that people are more familiar with vertical shooters (1942, Galaga, Space Invaders, Vertical Force, etc.) so I’m keeping it vertical.
JUST seems most people on other systems who do homebrew do side scrolling shmups but I will like I said not complain
Thank you.
Thank me when you finish the game and I give it high marks in the voting for the competition
No. It would make programming more difficult and it would require more sprites. And I plan to port this game to other platforms.
Well most good games were not made by 1 person alone, even if its just source code
I added a lives and level display. The game increases the level counter when you finish a level. The score and high score displays yet have to be added. I have also started writing the projectile-controlling code so the player and enemies will be able to shoot.
Does anyone want to design levels for this?
Attachments: