nesdev.org

These past few months I've been steadily working on Goplanes, a game for the Sega Genesis. Written in C using the SGDK.

The main thread on Sprites Mind, is here.

Some latest development videos:

Goplanes Dev Video 012 http://youtu.be/Cv9s1H32RSc
Goplanes Dev Video 013 http://youtu.be/kRVg4_mE674
Goplanes Dev Video 014 http://youtu.be/5kYjLdKqWHo

Is that real software rotation?

psycopathicteen wrote:Is that real software rotation?

Heck no.

All precomputed, sprinkled with vertical and horizontal flipping.

Have you looked into how you will be able to add sound and music to your game yet?

MottZilla wrote:Have you looked into how you will be able to add sound and music to your game yet?

A little bit, but nothing serious yet. I'm still very far away before I can start looking into that. So many things to do. But I'm greatly looking forward to it.

I've looked at using Shiru's VGM Music Maker program to create TFM tracks and play that using SDGK's native support for it. haven't actually tried it yet. No idea what I'll do for sound effects. That's about as far as I've gone.

Latest update:

Goplanes Dev Video 015
http://youtu.be/tjb5SRYFVUA

From the description:

Yep, still working on it!

The brand new feature in this version is weapon power ups. Still have no idea what kind of weapons (or weapon system) the game will have, but I thought adding a fireball gun would be fun to do. If you get hit, you lose the item, but you can pick it up again.

Other than that, lots of tweaks.
- Changed the health bar to have more health points. Actually reduced the number of sprites used to indicate health (two 8x32 sprites now vs. three 16x16 sprites before)
- Wall bounces (but not sky edge bounces) now cause damage, just like the original Goplanes. Hopefully the added difficulty will be offset by the increased number of health points. For sure there will be health pick ups at some later time.
- Realized that the flying rotation lookup tables had slightly skewed values. Now when flying in a circle, the plane doesn't drift towards the upper left anymore.
- I was computing object visibility in too many places, now I compute it once during object update, cache the result and check it instead of calling the visibility function everywhere. Simple optimization.
- Fixed the radar arrows so that they don't move when the scrolling has reached a screen edge. It was distracting.
- The map exporter for Tiled also exports horizontal and vertical flipping. The two green blocks at the bottom of the screen show this off.

In other news, collision code is too damn slow. I'm limiting collisions to certain types and only when they're visible on screen, but firing six to eight bullets with a half dozen collidable objects slows the game down to 30 fps. I think the level design will naturally limit the number of active objects visible, but it bothers me that it's not faster. I haven't been able to come up with a solution to speed it up. Not even the Bresenham circle algorithm can help!(*)

(*) totally an inside joke. Hi Fred!


EDIT: Since I posted the video, I took another look at the collision code and sped it up with a quick refactoring. Now the framerate only drops to 55 instead of 30 for the same scene.

Have you tried sorting the objects by their Y coordinate and only looking far enough backward and forward in the array to see other objects that could possibly collide based on their sizes?

tepples wrote:Have you tried sorting the objects by their Y coordinate and only looking far enough backward and forward in the array to see other objects that could possibly collide based on their sizes?

Have not thought of that! Interesting idea. I'd have to think about it.

Goplanes Dev Video 016

http://youtu.be/9zuKr1L7BFc

From the description:

The game now supports having a level split into smaller sections and being able to go from section to section through "doors".

Sections are small because it's a quick test. They can be much larger than what is in the video.

Was scared I wasn't going to have this finished this week as this, while very important, was pretty boring work Had to refactor the game loop again which is always fun.

Anyway, every section can have up to four doors which is a totally arbitrary limit. Doors can be placed anywhere and can be any size.

After dying, the player comes from the last door they flew through. This works ok for now, but I might have to handle this better through checkpoints. Having the player come through the last door they took might have them fly smack into a difficult area over and over again.

I haven't figured out a good way to indicate to the player which edge of a level is a door and which is not. At the moment, there's no way to tell if there's a door. Flags flapping in the wind? Arrows? a different color sky? Not happy with any of those ideas.

Obvious bugs are enemies get respawned whenever the player reenters a section. That'll be handled better. Destroyed enemies will be kept destroyed.

I've never seen a shmup-PG before. (shmup + RPG) This looks very good.

Personally, I don't think you should put flags indicating a door. Let the player figure it out, that's half the fun. (remembers prince of persia )

isufje wrote:I've never seen a shmup-PG before. (shmup + RPG) This looks very good.

I keep debating what kind of style the game should be. I feel it can't be a simple shooter because I want to push myself but an RPG would be too much. I was thinking more something like Metroid, but simpler. Discrete levels, but made out of mazes and gives the player choices that can affect later gameplay. Say one level has a health extender, a weapon upgrade and a gradius style "option" but the player, though some kind of game mechanic, can only choose one. That way when they go and play the level again, they can try something else. Something like that.

Nothing's in stone yet, though. I haven't reached that part of development.

Shooter/RPGs have happened before. You might look into Fuzzical Fighter for Famicom or Sigma Star Story for GBA.

Both games have limited RPG elements but definitely manage to differentiate themselves.

Genesis Dev Video 017

http://youtu.be/qrsaF8h60uI


From the description:


Music! Sound effects!

(You should probably raise the volume. I think it recorded soft)

Finally figured out the whole music production pipeline using the Echo sound driver and tools for Sega Genesis.

Echo is worked on by sikthehedgehog and oerg866. You can find it here: https://github.com/sikthehedgehog/Echo

I used the C version.

What you hear is a song composed in OpenMPT which has been converted for Echo. It took a while and some thought to get to that point

Yes, the music is nothing but plink plink notes and the "sound effect" is just a chord but it proves that the production pipeline and in-game player work. I'm not a music composer

What you see in the video specifically are:
- a background music track playing. it plays a note on all 10 channels. No PCM effects at the moment.
- a sound effect when the player shoots. it takes the first three channels.
- the sound continues to play without interruption when the level section changes. No stuttering at all, which is great.

Finally the last remaining big unknown has been figured out. Phew!

Also, totally random: trees!

I clicked on your most recent youtube link got an error that said "An error occurred during validation.
Sorry about that."
I tried the link you posted on the spritesmind forum and got the same thing.
Did you forget to copy paste the last letter in the link?

It should be fixed now. Thanks for reporting!