I ported my old project from 2007 to WASM.
Original game was built in C++ for Win32 DirectX.
This was an educational project with a team of 6 and 5 months of development.
How to play: Press Quick Start.
Left/Right keys to aim,
Up/Down for power.
W/A/S/D to move the camera, tab to lock/unlock the camera.
Works on mobile too, though not perfect yet - drag the arrow around to aim, adjust the power bar, tap fire.
Originally started porting back in 2020. The first step was to port native DirectX code into OpenGL, DirectSound to SoLoud and platform code to SDL.
I ended up porting the rendering code to bgfx and coding agents game me a big boost this year so to finish the project.
The aesthetics and feature all remain original.
Some of the porting challenges:
- Lots of DirectX code. Back in 2007 portability was not a high priority for us. Custom-built engine.
- Packed 32 bit custom model and animation file format with packed structures.
Back then we also made some interesting choices:
- Wrote our own custom STL-like library.
- For performance, the model loading code was pre-allocating a block, reading the entire file and then fixing up the binary structure offsets into pointers. This was the packed structure binary format and was not portable to modern systems so had to rewrite the loader.
- Originally I wrote a custom Maya exporter plugin and model format that supported skeletal animations. Ironically we ran out of budget to produce the animations so it ended up barely used.
- We had a strict rule: Absolutely no exception handling or RTTI. This ended up paying off 19 years later because it made it easier to port to WASM.
Trivia:
- The weird player names are mostly nicknames of other students and staff at the time.
- There are some pop culture sci/fi references to Space Balls and other movies if you notice them.
- The game pre-dates Angry Birds by 2 years but has some of the same vibes to it.
Thank you. Yeah the load times could probably be improved. It's still the desktop assets and all pre-loaded ahead of time. It could benefit from some streaming of assets in future updates.
In terms of gravity, I actually recall this was a team debate. The original design was to use real gravity but the team thought it was simpler to have discrete areas of influence. We never really had time to A/B test it. Kerbal Space Program uses a similar model.
I had too much physics in my life so my brain is screaming "Is energy and angular momentum conserved here???". I'm not sure if I'm a typical user :) What I dislike about influence areas is that sometimes small changes in the direction or speed makes big changes in the trajectory.
* I'm not sure if it's a good idea to start the first game with so many weapons. I understand it's more fun, but not knowing what they do and the cost is confusing.
* In the weapon buying screen, it would be nice to have a visual representation of the explosion. (This looks like a very hard change. I'm not sure if you are going to add more features.)
* In the weapon buying screen, I prefer that the list is not cyclic, i.e. if I click down it stops when the list ends instead of cycling to the more expensive weapons again.
4 comments
[ 5.1 ms ] story [ 36.7 ms ] threadHow to play: Press Quick Start. Left/Right keys to aim, Up/Down for power. W/A/S/D to move the camera, tab to lock/unlock the camera.
Works on mobile too, though not perfect yet - drag the arrow around to aim, adjust the power bar, tap fire.
Originally started porting back in 2020. The first step was to port native DirectX code into OpenGL, DirectSound to SoLoud and platform code to SDL.
I ended up porting the rendering code to bgfx and coding agents game me a big boost this year so to finish the project.
The aesthetics and feature all remain original.
Some of the porting challenges: - Lots of DirectX code. Back in 2007 portability was not a high priority for us. Custom-built engine.
- Packed 32 bit custom model and animation file format with packed structures.
Back then we also made some interesting choices: - Wrote our own custom STL-like library. - For performance, the model loading code was pre-allocating a block, reading the entire file and then fixing up the binary structure offsets into pointers. This was the packed structure binary format and was not portable to modern systems so had to rewrite the loader. - Originally I wrote a custom Maya exporter plugin and model format that supported skeletal animations. Ironically we ran out of budget to produce the animations so it ended up barely used. - We had a strict rule: Absolutely no exception handling or RTTI. This ended up paying off 19 years later because it made it easier to port to WASM.
Trivia: - The weird player names are mostly nicknames of other students and staff at the time. - There are some pop culture sci/fi references to Space Balls and other movies if you notice them. - The game pre-dates Angry Birds by 2 years but has some of the same vibes to it.
Are you simulating real gravity or some quick method that consider the closest planet?
In terms of gravity, I actually recall this was a team debate. The original design was to use real gravity but the team thought it was simpler to have discrete areas of influence. We never really had time to A/B test it. Kerbal Space Program uses a similar model.
You may enjoy looking at another recent game "Hole Punch: Sling your spaceship around gravitational fields" https://notoriousbfg.com/hole-punch/ (HN discussion https://news.ycombinator.com/item?id=49946393 (364 points | 2 days ago | 90 comments))
About your game, three feature request:
* I'm not sure if it's a good idea to start the first game with so many weapons. I understand it's more fun, but not knowing what they do and the cost is confusing.
* In the weapon buying screen, it would be nice to have a visual representation of the explosion. (This looks like a very hard change. I'm not sure if you are going to add more features.)
* In the weapon buying screen, I prefer that the list is not cyclic, i.e. if I click down it stops when the list ends instead of cycling to the more expensive weapons again.