You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was really excited to see this project. I read your blog and I was also liking the original BiPlanes, especially the bluetooth multiplayer back in the days. I'm a mobile developer, and I've tried to recreate a biplanes game some 10+ years ago so that I could play it again. I have a screenshot here 😀
I didn't really finish it or anything, even though it had a working multiplayer. I also couldn't get the physics right, I was just guessing what I remembered about the original BiPlanes behaviour. That is why I was so surprised that you were able to recreate the original with the exact same code and assets. It was amazing playing it again with the look and feel how I remember it.
I think the game should be published for mobile, so it could be played like the old times. Also, a web version would make it more accessible to other people, who would like to try playing it again. What do you think?
Hello, @cvb941
First of all, thank you for recognising my work 😁 Even after 5 years, receiving these occasional little acclaims remind me this project was well worth the time spent on it.
Regarding your question/request, unfortunately there are a lot of complications:
Publishing the game on Google Play and similar platforms might be risky. Eventhough the original version is now an abandonware and it's quite hard to track down who owns rights to the game, I have a suspicion the chain of company acquisitions leads to one of the Big publishers of today. And publishing an APK here would hardly increase accessibility, as Google & Apple do everything it takes to complicate installation of 3rd party apps on their systems.
Since I spent the majority of my school years with either a cellphone or a very dated smartphone, I've never actually gotten into mobile gaming in modern sense. This effectively makes me hardly a suitable person for the job :) Not to mention the fact I never developed for mobile and web.
Original game was meant to be played with button-like controls, and I don't see how it would work with touchscreen input. It just would feel very awkward and unresponsive to play, because to my very limited view:
two thumbs are not enough for both firing and controlling the plane, or at least I can't think up of any control scheme which would allow precise & intuitive input. On cellphone I could get around that by pressing 2 buttons with 1 thumb, whereas touchscreen would probably get confused faced with such trickery;
plane directions are fixed by design, which complicates responsiveness even more;
As the game uses fixed aspect ratio to stay true to the original, black bars also wouldn't look well on wide smartphone screen. Again, this means the game would require major rewrite of not only input, but resolution scaling & camera viewport as well. Oh, and I also smell the sweet times of dozens game .jar versions for different screen sizes 😂
Mobile multiplayer... Well, good luck trying to punch through mobile ISPs NATs :)
On the other hand, web version is technically a more viable option, since my implementation is based on SDL2 and maybe it can be ported using something like Emscripten and hosted on itch.io. BUT it would probably be single-player only, as I've no idea whether current netcode is even compatible with browser environment.
Besides, I already spent almost all my coding years returning to this project from time to time, and I definitely don't want to spend months & years porting this game AGAIN for 2 completely different platforms (it already runs on Windows, Linux & macOS, mind you)... It was a perfect passion project for first coding experiences, but right now I have to pursue other interests.
All in all, I laid out my thoughts on the topic. This project is open source, so if you want to port the game to mobile/web yourself, you are free to look at the code, and I'll gladly answer any questions about the implementation. Afterall, since you've been in mobile development for so long (I've been coding for only 6 years at best, compared to your 10+), you are much more experienced and competent to get this kind of job right than me 👍
Thank you for your detailed response, I understand everything :)
I would like to take a go at porting the game to mobile or web, but the C++ ecosystem is in turn unfamiliar to me and I'm afraid it would take a significant amount of effort.
So maybe in the future there will be more time to tackle this. Or who knows, an AI agent will port this to Unity or something and make it run on all of the platforms in a couple of minutes😁
@cvb941, I managed to port the game to WebAssembly. It's now live on both our itch.io page & official website.
Indeed, Emscripten is like a magic button which allows porting properly structured SDL2-based projects with minimal effort (it took me roughly ~3 evenings). I mostly had to restructure my main loop and struggle with HTML gibberish.
Unfortunately, though, I also had to disable online multiplayer because UDP networking is not available in browsers (or DOES IT?). So, for the time being, the Web version can be considered merely a demo.
Anyway, with the proxying approach suggested in Emscripten docs, I always get tons of runtime JS errors/exceptions when I add -sPROXY_TO_PTHREAD flag (the game doesn't even initialise). If I just add all other required flags, the whole tab simply hangs upon socket creation. This whole concept of Browser<->JS<->WASM interoperation is way beyond my competence, so I leave it for future generations to solve :)
I'll soon update Emscripten branch so it builds with cut features, but it's up to others to make it run. I also suspect these problems could come from html template, as I basically got the default one from Emscripten and ripped all the redundant UI.
(I'm not even sure I got all the alignments/paddings/sizes right)
Technically, it's trivial to introduce touch screen input processing logic to allow web version to be played on mobile devices as well. But as I mentioned earlier, the code alone is not enough for making comfortable & responsive controls - UI/UX is more difficult to get right
Now it works on PS Vita :D
Although there are still many things to fix...
I couldn't find your contact details with a quick search, so I wanted to ask you. Would you mind if I posted the finished files on GitHub and VitaDB when I'm done?
Of course, I will credit you as the original author of the port.
@DvaMishkiLapa, WOW, that's cool! I see you're putting a lot of effort into your fork. And, by the way, it's actually the first active fork of the project!
Ideally, it would be best to have all ports in the main repository to make it easier to deliver new versions (there's at least 1 planned future update from me), but the codebase wasn't really designed for that, unfortunately. I learned it the hard way while doing the Emscripten port :(
So, you are free to post your code wherever you see fit, preserving the original project name/title
@Casqade is biplanes-revival-vita Ok?
Yes :D I noticed that the code is not entirely modular. However, thanks to SDL2, I was able to run your port with minimal changes.
I think that in terms of Emscripten, the controls will only work on the keyboard, since you only process SDL presses from it. I changed them to gamepad controls in my port.
PS Vita is more to blame here. Working with files, keystrokes, and the network will bring about major changes. I'm not sure I have the skills to separate it all. It will be easier for me to merge your changes manually when there is a new update.
And matchmaking will not work, because port 50005 on PS Vita is reserved by the system. Could you provide the option to select a port?
Reserved ports are 1-1023, 9293-9308, 40000-65535.
Yes. Though, I actually meant it in the context of user-visible title which actually appears in the game and readme files (Biplanes Revival)
It will be easier for me to merge your changes manually
Ok, sure
Could you provide the option to select a port?
AFAIK, MATCHMAKE_SOCKET_PORT is client-side, so you are free to override it with an arbitrary port. I don't see any reliance on this specific value in our matchmaking server code. @xxxxxion actually implemented the procedure for NAT hole punching, I just cleaned the code up a little bit. So I guess if you manage to get it working with other port, you can keep the value overridden.
If PS Vita uses WiFi to access the Internet, you should first confirm a successful match between two PC devices (e.g. PC A connected to WiFi A, PC B connected to WiFi B), then you can test how it works with Vita devices in the same network setup. If it succeeds, then you can try doing crossplay matchmaking (would be cool lol. Even cooler than direct connect match between different platforms).
Previously, I had some thoughts on exposing matchmaking hostname/ip in the config file, but never got to it for some reason. Maybe it's because our matchmaking server code is not public (at least, until our website is accessible), and without proper documentation for our matchmaking procedure there's really no use in these values for the user.
@KingBeanie44, if you used prebuilt Windows binaries, I think you had this issue #6, so there was no way you could actually test multiplayer properly.
I reuploaded the binaries with the fix, so at least you can now enter IP address normally
@Casqade
Is Matchmaking working properly right now?
I can't connect to anyone, even with Windows. I just can't figure out if it's my fault or my network's fault. I've already tried using mobile internet and my provider, but the result is the same: "Peer-to-peer connection timeout!"
@DvaMishkiLapa, matchmaking server is online. If you see "Searching for the opponent" message on top of the screen, that means the server is active and you've been put to the pending players queue.
"Peer-to-peer connection timeout" means the server did anything it could to establish a session between you and other player, but your clients failed to connect to each other. This may mean your (or other player's) ISP uses too restrictive NAT configuration, thus making it impossible to use true P2P connection. Btw, there's status messages reference.
Big platforms like Steam & Discord usually implement more robust NAT punching techniques, and in case that's not enough, they also provide intermediate relay servers as a fallback. Obviously, I can't provide any relay servers, so when NAT punching fails, you have to use other means to play multiplayer.
Please note that matchmaking doesn't work if both clients are in the same LAN, so make sure you use different networks for testing. Also, mobile ISPs are usually the worst for P2P.
I can only advise to try the following:
On client A, launch the game and start searching for the opponent
With status message confirming the search state, wait a bit (3-5s more than enough)
On client B, do step 1
If that doesn't work, try 2-3 times more, because hole-punching UDP packets may be lost in the way. That usually happens in bad network conditions, especially when using WiFi or mobile networks.
If still no success, try the same algorithm from step 1 with client B first. This will ensure a match if at least one of the clients has more accessible NAT
@DvaMishkiLapa, btw, if your ISP allows port forwarding and you can play Direct Connect, that means matchmaking is probably expected to work as well. You can also try enabling UPnP on your router
@Casqade
Well, then Matchmaking is the only thing I can't test on Vita yet. I'm just getting to the point of confirming the opponent. I need to figure out how to test it.
For some reason, I thought your server was an intermediary for transferring packets. I didn't delve into the network code that deeply. But now I finally understand.
@DvaMishkiLapa, I can leave my client running in the background for a bit, so you can test the matchmaking connection. I don't remember whether the first player in the queue is the host or client (in Direct Connect terms), so if this will fail repeatedly you should be the first to search
matchmaking server is online. If you see "Searching for the opponent" message on top of the screen, that means the server is active and you've been put to the pending players queue.
Describe this in README, it seems that it is not entirely obvious :D
Describe this in README, it seems that it is not entirely obvious :D
That's described in the ingame help system :D
Actually, I tried to write a FAQ for it somewhere outside the game in more detail, but I failed because such a simple task of explaining status messages requires dozens of paragraphs explaining all the things about networks, NATs, ISPs ect. to potentional readers who don't even know what a LAN is. If written in more technical way, these explanations won't mean anything to them.
And I'm not particularly well-versed in NAT to provide a thorough explanation anyway (or at least implement a better hole punching algorithm, because ours is far from being what I consider moderately robust)
@DvaMishkiLapa, initially, I used J2ME sprites, but throughout the development about 30-50% of the assets ended up being touched in some way. For instance, the original barn, parachute & plane sprites didn't have proper translucency, and pilot only had 2 animation frames on the ground. Me & my friend had to do some restoration work to adapt the sprites for the "big screen".
As the original game didn't have any audio (let's ignore the annoying menu theme), I made all the builtin sounds + my friend did several unofficial sound & texture packs available on itch.io and out website
Activity
Casqade commentedon Mar 6, 2025
Hello, @cvb941
First of all, thank you for recognising my work 😁 Even after 5 years, receiving these occasional little acclaims remind me this project was well worth the time spent on it.
Regarding your question/request, unfortunately there are a lot of complications:
Publishing the game on Google Play and similar platforms might be risky. Eventhough the original version is now an abandonware and it's quite hard to track down who owns rights to the game, I have a suspicion the chain of company acquisitions leads to one of the Big publishers of today. And publishing an APK here would hardly increase accessibility, as Google & Apple do everything it takes to complicate installation of 3rd party apps on their systems.
Since I spent the majority of my school years with either a cellphone or a very dated smartphone, I've never actually gotten into mobile gaming in modern sense. This effectively makes me hardly a suitable person for the job :) Not to mention the fact I never developed for mobile and web.
Original game was meant to be played with button-like controls, and I don't see how it would work with touchscreen input. It just would feel very awkward and unresponsive to play, because to my very limited view:
As the game uses fixed aspect ratio to stay true to the original, black bars also wouldn't look well on wide smartphone screen. Again, this means the game would require major rewrite of not only input, but resolution scaling & camera viewport as well. Oh, and I also smell the sweet times of dozens game .jar versions for different screen sizes 😂
Mobile multiplayer... Well, good luck trying to punch through mobile ISPs NATs :)
On the other hand, web version is technically a more viable option, since my implementation is based on SDL2 and maybe it can be ported using something like Emscripten and hosted on itch.io. BUT it would probably be single-player only, as I've no idea whether current netcode is even compatible with browser environment.
Besides, I already spent almost all my coding years returning to this project from time to time, and I definitely don't want to spend months & years porting this game AGAIN for 2 completely different platforms (it already runs on Windows, Linux & macOS, mind you)... It was a perfect passion project for first coding experiences, but right now I have to pursue other interests.
All in all, I laid out my thoughts on the topic. This project is open source, so if you want to port the game to mobile/web yourself, you are free to look at the code, and I'll gladly answer any questions about the implementation. Afterall, since you've been in mobile development for so long (I've been coding for only 6 years at best, compared to your 10+), you are much more experienced and competent to get this kind of job right than me 👍
cvb941 commentedon Mar 8, 2025
Thank you for your detailed response, I understand everything :)
I would like to take a go at porting the game to mobile or web, but the C++ ecosystem is in turn unfamiliar to me and I'm afraid it would take a significant amount of effort.
So maybe in the future there will be more time to tackle this. Or who knows, an AI agent will port this to Unity or something and make it run on all of the platforms in a couple of minutes😁
Thanks again for this project!
Casqade commentedon Apr 2, 2025
@cvb941, I managed to port the game to WebAssembly. It's now live on both our itch.io page & official website.
Indeed, Emscripten is like a magic button which allows porting properly structured SDL2-based projects with minimal effort (it took me roughly ~3 evenings). I mostly had to restructure my main loop and struggle with HTML gibberish.
Unfortunately, though, I also had to disable online multiplayer because UDP networking is not available in browsers (or DOES IT?). So, for the time being, the Web version can be considered merely a demo.
Anyway, with the proxying approach suggested in Emscripten docs, I always get tons of runtime JS errors/exceptions when I add
-sPROXY_TO_PTHREADflag (the game doesn't even initialise). If I just add all other required flags, the whole tab simply hangs upon socket creation. This whole concept of Browser<->JS<->WASM interoperation is way beyond my competence, so I leave it for future generations to solve :)I'll soon update Emscripten branch so it builds with cut features, but it's up to others to make it run. I also suspect these problems could come from html template, as I basically got the default one from Emscripten and ripped all the redundant UI.
(I'm not even sure I got all the alignments/paddings/sizes right)
cvb941 commentedon Apr 2, 2025
Good job @Casqade, I can finally play the game on web, it's great! Even without networking 😁
Casqade commentedon Apr 2, 2025
Technically, it's trivial to introduce touch screen input processing logic to allow web version to be played on mobile devices as well. But as I mentioned earlier, the code alone is not enough for making comfortable & responsive controls - UI/UX is more difficult to get right
KingBeanie44 commentedon Jul 18, 2025
hey guys, i wanted to ask for a mobile version as well but i can understand the reasons against it.
BUT
it's running great in winlator. and there we've touch controls or we can use the controller (tested on retroid pocket classic and odin 2/ mini) :)
Casqade commentedon Jul 18, 2025
@KingBeanie44, thanks for the feedback! May I ask a couple of questions:
KingBeanie44 commentedon Jul 18, 2025
Quick Photo that it's working in winlator
DvaMishkiLapa commentedon Jul 30, 2025
Now it works on PS Vita :D
Although there are still many things to fix...
I couldn't find your contact details with a quick search, so I wanted to ask you. Would you mind if I posted the finished files on GitHub and VitaDB when I'm done?
Of course, I will credit you as the original author of the port.
Casqade commentedon Jul 31, 2025
@DvaMishkiLapa, WOW, that's cool! I see you're putting a lot of effort into your fork. And, by the way, it's actually the first active fork of the project!
Ideally, it would be best to have all ports in the main repository to make it easier to deliver new versions (there's at least 1 planned future update from me), but the codebase wasn't really designed for that, unfortunately. I learned it the hard way while doing the Emscripten port :(
So, you are free to post your code wherever you see fit, preserving the original project name/title
[-]Mobile version[/-][+]Mobile/Console version[/+]DvaMishkiLapa commentedon Jul 31, 2025
@Casqade is
biplanes-revival-vitaOk?Yes :D I noticed that the code is not entirely modular. However, thanks to SDL2, I was able to run your port with minimal changes.
I think that in terms of Emscripten, the controls will only work on the keyboard, since you only process SDL presses from it. I changed them to gamepad controls in my port.
PS Vita is more to blame here. Working with files, keystrokes, and the network will bring about major changes. I'm not sure I have the skills to separate it all. It will be easier for me to merge your changes manually when there is a new update.
DvaMishkiLapa commentedon Jul 31, 2025
And matchmaking will not work, because port 50005 on PS Vita is reserved by the system. Could you provide the option to select a port?
Reserved ports are 1-1023, 9293-9308, 40000-65535.
Casqade commentedon Jul 31, 2025
@DvaMishkiLapa
Yes. Though, I actually meant it in the context of user-visible title which actually appears in the game and readme files (Biplanes Revival)
Ok, sure
AFAIK, MATCHMAKE_SOCKET_PORT is client-side, so you are free to override it with an arbitrary port. I don't see any reliance on this specific value in our matchmaking server code. @xxxxxion actually implemented the procedure for NAT hole punching, I just cleaned the code up a little bit. So I guess if you manage to get it working with other port, you can keep the value overridden.
If PS Vita uses WiFi to access the Internet, you should first confirm a successful match between two PC devices (e.g. PC A connected to WiFi A, PC B connected to WiFi B), then you can test how it works with Vita devices in the same network setup. If it succeeds, then you can try doing crossplay matchmaking (would be cool lol. Even cooler than direct connect match between different platforms).
Previously, I had some thoughts on exposing matchmaking hostname/ip in the config file, but never got to it for some reason. Maybe it's because our matchmaking server code is not public (at least, until our website is accessible), and without proper documentation for our matchmaking procedure there's really no use in these values for the user.
Casqade commentedon Jul 31, 2025
@KingBeanie44, if you used prebuilt Windows binaries, I think you had this issue #6, so there was no way you could actually test multiplayer properly.
I reuploaded the binaries with the fix, so at least you can now enter IP address normally
DvaMishkiLapa commentedon Jul 31, 2025
@Casqade
Is Matchmaking working properly right now?
I can't connect to anyone, even with Windows. I just can't figure out if it's my fault or my network's fault. I've already tried using mobile internet and my provider, but the result is the same: "Peer-to-peer connection timeout!"
Casqade commentedon Jul 31, 2025
@DvaMishkiLapa, matchmaking server is online. If you see "Searching for the opponent" message on top of the screen, that means the server is active and you've been put to the pending players queue.
"Peer-to-peer connection timeout" means the server did anything it could to establish a session between you and other player, but your clients failed to connect to each other. This may mean your (or other player's) ISP uses too restrictive NAT configuration, thus making it impossible to use true P2P connection. Btw, there's status messages reference.
Big platforms like Steam & Discord usually implement more robust NAT punching techniques, and in case that's not enough, they also provide intermediate relay servers as a fallback. Obviously, I can't provide any relay servers, so when NAT punching fails, you have to use other means to play multiplayer.
Please note that matchmaking doesn't work if both clients are in the same LAN, so make sure you use different networks for testing. Also, mobile ISPs are usually the worst for P2P.
I can only advise to try the following:
If that doesn't work, try 2-3 times more, because hole-punching UDP packets may be lost in the way. That usually happens in bad network conditions, especially when using WiFi or mobile networks.
If still no success, try the same algorithm from step 1 with client B first. This will ensure a match if at least one of the clients has more accessible NAT
Casqade commentedon Jul 31, 2025
@DvaMishkiLapa, btw, if your ISP allows port forwarding and you can play Direct Connect, that means matchmaking is probably expected to work as well. You can also try enabling UPnP on your router
DvaMishkiLapa commentedon Jul 31, 2025
@Casqade
Well, then Matchmaking is the only thing I can't test on Vita yet. I'm just getting to the point of confirming the opponent. I need to figure out how to test it.
For some reason, I thought your server was an intermediary for transferring packets. I didn't delve into the network code that deeply. But now I finally understand.
Casqade commentedon Jul 31, 2025
@DvaMishkiLapa, I can leave my client running in the background for a bit, so you can test the matchmaking connection. I don't remember whether the first player in the queue is the host or client (in Direct Connect terms), so if this will fail repeatedly you should be the first to search
DvaMishkiLapa commentedon Jul 31, 2025
Describe this in README, it seems that it is not entirely obvious :D
DvaMishkiLapa commentedon Jul 31, 2025
Don't bother. I checked the connection with a friend on the other side of the world, and the problem is with my provider.
Casqade commentedon Jul 31, 2025
That's described in the ingame help system :D
Actually, I tried to write a FAQ for it somewhere outside the game in more detail, but I failed because such a simple task of explaining status messages requires dozens of paragraphs explaining all the things about networks, NATs, ISPs ect. to potentional readers who don't even know what a LAN is. If written in more technical way, these explanations won't mean anything to them.
And I'm not particularly well-versed in NAT to provide a thorough explanation anyway (or at least implement a better hole punching algorithm, because ours is far from being what I consider moderately robust)
DvaMishkiLapa commentedon Aug 1, 2025
@Casqade
I would also like to clarify whether your assets are original or were they used from the J2ME version?
Casqade commentedon Aug 1, 2025
@DvaMishkiLapa, initially, I used J2ME sprites, but throughout the development about 30-50% of the assets ended up being touched in some way. For instance, the original barn, parachute & plane sprites didn't have proper translucency, and pilot only had 2 animation frames on the ground. Me & my friend had to do some restoration work to adapt the sprites for the "big screen".
As the original game didn't have any audio (let's ignore the annoying menu theme), I made all the builtin sounds + my friend did several unofficial sound & texture packs available on itch.io and out website