Mission: Paper Airplane

[mzxtuelkl]

---

Mission: Paper Airplane

---

Username: mzxtuelkl
Project Title: Mission: Paper Airplane
Time to Complete: 4 months
SDK: Psy-Q + Custom
Genre: Game
Latest Release: Version 1.0
In Development: No
Initial Release Date: 18-FEBRUARY-2023
Last Date Updated: 13-MARCH-2023
Controller: Digital
Players: 1
Memory Card: None
Languages: Eng
Region: NTSC
Burn and Play: Yes
Executable Included: No
Source Included: Yes

---

Mission: Paper Airplane is a time trial game where you must complete 5 levels as fast as possible. There are speed powerups and tube obstacles scattered throughout each level. It's a very short game—you can probably beat it in less than 10 minutes on your first playthrough. Most of the code is written in C, but there are some bits of assembly hanging around the rendering code. A couple notes:


Polygon Subdivision:
Earlier in development I had all of the assets jammed into main memory, so to save on space, any primitive that was to be subdivided was slightly enlarged relative to itself, and then passed onto the subdivision routine (in this case, RCpoly). I never moved from this method, so although the models will look off, it still performs an OK job at minimizing seams between polygons of differing subdivision levels.

Collisions:
Most of the level geometry still relies on AABB, but for tubes, the code plots a sphere centered on a point along the tube's bezier curve that is closest to the player and determines whether or not the player is in a valid position based off current conditions. The camera however doesn't adapt to whether or not you're right next to a wall, so sometimes the camera will clip outside of level geometry.

Clipping:
Unsubdivided polygons are clipped by checking if at least two of the polygon's vertices are within a specified on-screen boundary. Subdivided polygons are clipped by RCpoly. Unfortunately it's not perfect due to reasons I'm currently unsure of.

Lighting:
I once had Gouraud shading on the tubes, but my code was too slow so I ended up with flat-shaded polygons instead.

Assets:
The game breaks copyright 3 times:

• PsyQ SDK (code)
• Alpine Stars - Jump Jet (music)
• GTA LCS - MSX 98 (music)

Everything else was made either by me or by an artist who licensed their work under a free license.



I unfortunately only got to implement a fraction of what I had outlined in my design doc, but as my interest on this project continued to dwindle, I decided that I was not going to leave yet another unfinished game project lay about on my hard drive. Hopefully you find it fun!

---

ISO: https://mzxtuelkl.qeeds6.net/downloads/MPA.7z
Source Code: https://mzxtuelkl.qeeds6.net/downloads/MPA_source.7z

Playthrough: https://www.youtube.com/watch?v=0LhPgJ_a9eA

---

[Administrator]

That's pretty impressive. It looks very difficult though. I'd suggest improving the textures, adding lighting and working on maintaining 60 FPS. The biggest problem to me seems to be the texture resolution. Also, paper aeroplanes are white (not sure why you picked grey)

For some reference to what the game could look like and what you should be aiming for, take a look at the game Kula World (Roll Away).

[mzxtuelkl]

Thanks for the feedback Shadow! The reason why many of the levels are low resolution is because each level utilizes only one texture page, which is an engine-specific issue I need to fix. Regarding the framerate, I'm not sure if I'm skilled enough to achieve a stable 60fps, but I'll try anyway for my next project. Thanks again.

[nocash]

That looks nice. I've only watched the movie because I haven't been able to decompress the .7z file, the downloaded file is 30,246,760 bytes tall, but 7zip tells me that it can't open it as an archive (my 7zip version is quite old, but I never had that problem before).

For lighting: I can't see any lighting, neither gouraud shaded, nor flat shaded. Especially the tubes would benefit from lighting (or from more colors in general, like using different colors for floor/walls/ceiling and perhaps different brightness for near/distant sections).

How did you manage to get the lighting too slow... did you overload the CPU/GTE or GPU?

The GPU should be fast enough for that, unless you are rendering thousands of hidden polygons (hidden behind the polygons in foreground).
The CPU/GTE should be also fast enough (again, try to skip processing of invisible polygons, like those too distant or behind camera).

For light vectors: You don't need them at all in a fixed scene with fixed light source (you could just pre-compute the light colors on the PC).
Flat shading and gouraud shading shouldn't make much of a difference. For flat you need one color per polygon, for gouraud you need one color per vertex (but the vertices are shared for multiple polygons, so it's the same amount of colors in total).

[Administrator]

That looks nice. I've only watched the movie because I haven't been able to decompress the .7z file, the downloaded file is 30,246,760 bytes tall, but 7zip tells me that it can't open it as an archive (my 7zip version is quite old, but I never had that problem before).

I have that problem on Windows 98 as well. Instead of opening the archive, try just extracting it to the same directory the archive is placed it. If that still doesn't work, then it's maybe an old bug and it could be the filesize is too large and you're running out of working memory.

[mzxtuelkl]

For lighting: I can't see any lighting, neither gouraud shaded, nor flat shaded. Especially the tubes would benefit from lighting (or from more colors in general, like using different colors for floor/walls/ceiling and perhaps different brightness for near/distant sections).

How did you manage to get the lighting too slow... did you overload the CPU/GTE or GPU?

I've seen the POLY_F3/POLY_F4/etc.. reference pages so many times that I've begun to refer to the primitives themselves as "flat shaded" even though I've not actually implemented any flat shading in my engine. Sorry about that. You're correct about the lighting, there's none whatsoever. However, earlier in development I did have actual Gouraud shaded polygons:

(Nothing else being rendered except the tube and the player):


I wanted a point light (like this), but PsyQ seemed to only support directional light sources (like this), so I decided to write my own point light code entirely on the CPU. The original plan was to have one attached to the player to brighten up the tubes like in the youtube vid, but the code ran like hot garbage and was buggy so I scrapped lighting altogether.

An earlier gouraud-shaded point light implementation:

For light vectors: You don't need them at all in a fixed scene with fixed light source (you could just pre-compute the light colors on the PC).
Flat shading and gouraud shading shouldn't make much of a difference. For flat you need one color per polygon, for gouraud you need one color per vertex (but the vertices are shared for multiple polygons, so it's the same amount of colors in total).

This is a file format issue related to blender that I need to fix, since most of the file formats used in this project are entirely built from scratch. I have NIH syndrome unfortunately.

The GPU should be fast enough for that, unless you are rendering thousands of hidden polygons (hidden behind the polygons in foreground).
The CPU/GTE should be also fast enough (again, try to skip processing of invisible polygons, like those too distant or behind camera).

Yeah, that's exactly what's happening. I didn't implement occlusion culling, but back-face culling was something I had in my engine since half a year ago. I forgot to use it during the development of this game (mostly because I began to despise this project a couple months in, but that's besides the point). I instead tried to increase performance with LODs, which did help somewhat. I'll probably write up a list of engine features and have it stickied next to my dev PC so that I don't forget haha.

That looks nice. I've only watched the movie because I haven't been able to decompress the .7z file, the downloaded file is 30,246,760 bytes tall, but 7zip tells me that it can't open it as an archive (my 7zip version is quite old, but I never had that problem before).

Hmm.. I compressed the .7z file with a new version of 7zip on windows 10 and it decompressed fine on my XP machine. Try this: https://mzxtuelkl.qeeds6.net/downloads/MPA.rar. I created the rar file with winrar 3.93, so maybe your version of 7zip will have better luck with it. Thanks for the feedback!

[nocash]

I have redownloaded the original 7z file, it's now working and 50MB tall instead 30MB, apparently my browser screwed up in the first attempt. Decompressed it's 400MB tall, that's, well, outstanding even among other homebrews with poor value for memory ratio. It would be more impressive if you could squeeze it into 40KB.

The game engine looks neat, but the gameplay is just competely unplayable...

The plane is losing speed and usually drops down shortly before or after reaching the tube opening. A build-in help function is completely missing, and the three .txt files don't contain any useful info on how to gain/maintain speed or height.

Controls up=up and down=down are very confusing for planes, I have played for an hour (without ever passing the first tube), and the only thing I've achived is to keep pressing the wrong buttons in every critical situation.

Apart from losing speed, touching the green energy items is making the plane insanely fast, resulting in instant crash (at least so in no$psx, maybe it's acting differently on real hardware). I've managed to dodge the first energy item a few times (to avoid the speedup overkill), but never passed the second item.

Also, when picking up the green items, the plane starts to tumble and rotate around itself, the looks cool, but the message to the user is: You are fucked up & steering is impossible now (at least to hopeless gamers who get confused easiy). The tumbling effect might be better placed when reaching the goal, or at the begin of level (as intro, before handing control to the user).

The video with the green/black tube lighting, I am not sure if that is an improvement, or if it's making it even more difficult to estimate the distance between plane and walls. I would recommend different colors for the floor/ceiling/sides to make it easier to spot the tube curves (best with clearly distinct colors, with little or no gouraud shading), and perhaps a shadow underneath of the plane. Or make the walls glow brighter if they are too close to the plane, somewhat treating the plane as light source.

The only fun thing is the outdoor scenery, but unfortunately the game does immediately restart when steering into that direction instead of entering the tube opening.

It would be all better with more open scenery, starting with shorter tubes, with initial speed lasting longer, but less green item speedup, and ideally some kind of soft collisions where you can softly touch the walls without instantly restarting the game.

[mzxtuelkl]

I guess I should've gotten more feedback from more people other than my mom. I still consider myself a novice developer and I'll do my best to improve. Thanks for the critique, nocash

[sahlberg]

Very nice. Disclaimer: I am the maintainer of pop-fe, a utility to convert cue/bin into PS Classics for the PSP/PS3 and more.

I play most of my PS1 games on a PS3 nowadays so I have tooling to convert PS1 games to play on the PS3 with nice cover graphics and everything.
I see in your system.cnf you call the game MAIN.EXE, would it be possible to instead call it something that is similar to the naming convention on official PS1 games?
I am thinking maybe it could be called "BOOT=cdrom:\HBRW00001;1" (homebrew 00001)

That way I can add it to my game database pop-fe gamedb so that anytime someone uses your cue/bin and tries to create a PSP or PS3 package then it will show up with the correct name of the game and also I can add links to cover and screenshot images to use for the assets on the XMB.

[mzxtuelkl]

The HBRW_000.01 naming scheme could be an interesting idea, but everyone would end up accidentally mixing serial numbers without a strong central authority (like Sony).

I've updated MPA.7z and instead renamed the exe to "MZXTUELK.001". The naming scheme is <AUTHOR>.<GAME#> which should work more smoothly with your database.

[Xavi92]

I had missed this contribution until now, and it looks great! Looks very impressive for someone who considers himself/herself a "novice developer". I mostly agree with the feedback from nocash:

• The up=up/down=down controls are confusing for airplanes (think of how real-life airplanes are controlled).

• The gameplay is too difficult for inexperienced players.

• As for the green power-up, maybe it would be more rewarding for players if, apart from traveling at a (much) higher speed, the paper airplane would also be guided automatically.

• 400 MiB for a homebrew PS1 video game is way too much. Is it because of CD-quality music? If so, maybe you should consider alternatives, such as MIDI or MOD files.

I also had a quick glance at the source code, and I have a few questions about it:

I was partly amused at the use of K&R-style C function definitions and int as the default data type. Is that intentional? Such constructs were already deprecated on more recent revisions of the ISO C standard, and are usually risky to use. For example, ent_zero is returning int because no data type is specified on the function signature, but there is no return inside the function, which to my understanding is undefined behaviour.

On the other hand, I was surprised to see no Makefile or any reference to a build system. It does not look complicated to set up one for this project, but was this omission intentional?

Also, is the source code under a free software license? Take into account that sharing it without a license does not make it free software, and does not make it possible for others to modify or distribute the source code.

Despite the room for improvement, it already looks impressive. Very good job!

[mzxtuelkl]

I had missed this contribution until now, and it looks great! Looks very impressive for someone who considers himself/herself a "novice developer". I mostly agree with the feedback from nocash:

• The up=up/down=down controls are confusing for airplanes (think of how real-life airplanes are controlled).

• The gameplay is too difficult for inexperienced players.

• As for the green power-up, maybe it would be more rewarding for players if, apart from traveling at a (much) higher speed, the paper airplane would also be guided automatically.

One of the main inspirations for this game was a flash game called accelerator where you play as a bullet dodging obstacles. I ended up copying that game's controls without thinking about the design implications of changing the character from a bullet via first-person to an airplane via third-person, but that should be resolved in the sequel (if I eventually decide to make it). That's also why there's tubes with the green powerup you have to fly through but I may just scrap that entirely.

As for the difficulty, having more playtesters should help tune it to a more reasonable level. I'm thinking of just posting here a bit more for feedback but I don't know yet.

• 400 MiB for a homebrew PS1 video game is way too much. Is it because of CD-quality music? If so, maybe you should consider alternatives, such as MIDI or MOD files.

I'm pretty sure it's because I jammed much of MSX FM (around 20-40mins) into one XA audio channel and called it a day. Towards the game's release I was getting desperate for development to end and wasn't really thinking straight. Honestly would've been better with no music and to just let the player play their own stuff via their own separate device if they wanted to, but that's something to be addressed in a second game.

I also had a quick glance at the source code, and I have a few questions about it:

I was partly amused at the use of K&R-style C function definitions and int as the default data type. Is that intentional? Such constructs were already deprecated on more recent revisions of the ISO C standard, and are usually risky to use. For example, ent_zero is returning int because no data type is specified on the function signature, but there is no return inside the function, which to my understanding is undefined behaviour.

The only reason why the code is written like that is because some years ago I saw the source code for rogue (http://www.rots.net/rogue/source/source.htm) and became somewhat obsessed with how it looked. I intentionally started using it as an inspiration for my own code while I was rewriting my engine back in 2021. I really wanted to make it look like it was straight out of the early 1980s while disregarding the consequences of doing so..

On the other hand, I was surprised to see no Makefile or any reference to a build system. It does not look complicated to set up one for this project, but was this omission intentional?

Also, is the source code under a free software license? Take into account that sharing it without a license does not make it free software, and does not make it possible for others to modify or distribute the source code.

I omitted the build system and left no license associated with the code because I'd prefer if people just looked at it.

I honestly still consider myself a novice developer because I still haven't created a good game, but I guess sometimes you have to make some stinkers before making something actually decent.

Thanks for the critique, Xavi92

[nocash]

Can you explain the game mechanics: How do you gain speed, or lose speed?

The obvious ways to gain speed would be:
1) push a button, but paper plain has no engine.
2) dive down, but that doesn't seem raise speed in this game.
3) wind hat would help you to gain speed or height, but there are no visible indications that the game might rely on things like air circulation.
4) reach those power-ups, but there's a 80% chance that the plane drops down before even reaching the first power-up.
5) Perhaps steering via LEFT+RIGHT does somehow decrease (or even increase) the plane speed...?
6) Maybe the game speed varies depending on whether using specific hardware or emulators?
7) Is there some random factor, like starting each game with different plane speeds, so the player will die no matter what, unless the game did start with suitable speed?
8) pushing a button in a specific way to "throw" the plane when the game starts?

I am sure that you know how to play your game, but for other people it's very frustating if they don't know what they shall do.

My main development advice: Include instructions, and ideally make the controls so intuitive that users could play the game even without reading the instructions).

[mzxtuelkl]

Can you explain the game mechanics: How do you gain speed, or lose speed?

The only way to gain speed (other than the green powerup) is to point the plane towards the ground, while the only way to lose speed is to point the plane towards the sky (there are no other tricks, I swear!). That idea in itself is intuitive and is present in the game, but I'm guessing that the bad execution of controlling the plane itself (such as up=up, down=down controls) along with other design flaws (such as the impossible levels) has led to the game not being as simple to understand and play as you'd expect.

My main development advice: Include instructions, and ideally make the controls so intuitive that users could play the game even without reading the instructions).

My goal was to have it be intuitive enough that you wouldn't need a manual, but of course that's much much harder to pull off properly without playtesters to catch dumb mistakes (in which I really should've found playtesters, but didn't because I was (and likely still am) a novice game developer). I'm now aware that I should've added a manual anyway.