pqm VS Flythrough.Space

I made a spreadsheet add-on similar to the pint library for python (dimensional analysis) based on my own open source JS library (https://github.com/GhostWrench/pqm). Website is still up: https://ghostwrench.net/convertplus.html.

To me it seemed like the perfect way to get a solo app up and running because Google was going to run all the sever stuff and I could just cash in. The app never really got off the ground and by the time I realized that Big G really doesn’t want to make it easy for any schmuck to run a profit generating app using their servers and their technology and it wasn’t worth the maintenance effort to keep up with the constant requests to update the app. I think it is no longer available on the GSuite store as of a few months ago. I think my biggest mistakes were as follows:

1) I needed a business/marketing oriented co-founder. I underestimated how difficult that job is and overestimated my ability to do it.

2) I wanted to charge too much for the app. I didn’t want to undersell myself and get caught in a trap of not making enough to keep up with maintenance. I went too far the other way. I think maybe a $50-$60 on time charge would have been appropriate, instead of requiring a subscription. This is an easy fix, but I would had to re-do my marketing effort and see #1

3) Built before I tested the market. I convinced myself that just asking a few of my engineering friend would use it was enough. Again, this is probably a symptom of #1

4) I was mentally unprepared to deal with failure and I lost motivation to keep working on the project when things didn’t go as I expected.

5) I underestimated how much people actually use spreasheet add-ons. There really isn’t a thriving market and most of the really popular apps are a utility attached to another popular standalone project.

6) Probably should have targeted Excel rather than Sheets, because the market is simply bigger.

I think if the stars align, I would like to give this project another go. I don’t think it has totally failed rather than just gone dormant, but I need a better strategy for round 2!

There are heaps of libraries for all languages because it is a fairly fun and straight forward project. I personally created this one because I was frustrated with how slow and clunky the existing javascript libraries were:

https://github.com/GhostWrench/pqm

Also, I open sourced just the unit database (in JSON format) for anyone interested in making their own version:

https://github.com/GhostWrench/unitdb

Here's what it looks like now (planet files):

My project was a 3d in-browser escape velocity clone (think Endless Sky.) It ended up with an impressive feature set, mediocre graphics, not nearly enough world, no real game loop, and no players: http://flythrough.space

My mistake was building it totally in secret for most of its life. I worked on it for years focusing on adding features that maybe nobody wanted without validating the product/market fit or generating any buzz. By the time I was "ready" someone had gained way more steam on their own EV remake, even getting the author of Override to endorse it, so the fact that I had a working prototype didn't really matter, the community that I thought would be receptive wasn't interested.

I learned that you need to build something worth playing first, including some kind of game loop, before you try to get people to play it. Turns out noodling around with a hacky prototype isn't something people find exciting even if the whole community is centered around noodling around with mods and hacking. People won't mod a game they don't love in the first place.

Since this project, I've committed to building smaller prototypes and validating concepts before I go all-in on building something polished and content rich, and thought I haven't shipped anything this big since, I have met my personal goals.

Full retrospective: http://blog.eamonnmr.com/2020/08/flythrough-space-retrospect...

The conclusion: http://blog.eamonnmr.com/2020/04/dont-remake-an-old-game/

Here's a real example from a project I worked on in my homebrew ECS framework and later implemented in Godot: a guided missile.

In the ECS project the notion of 'thing that can run into other things and do damage' so totally separate from the notion of 'thing that is driven around by AI.' So adding guidance to an existing projectile wasn't too much of a pain. In the Godot project I'm dealing with networking as well, so the division is between fire-and-forget projectiles (derived from Bullet) which know about hitting things and doing damage, and AI driven Ships with AI or player driven movement which needs to be synced over the Network. In that case I had to copypasta the AI driven movement code into a 'guided' class under Bullet. That said, for almost every other task, Godot's composition first model has been way easier to work with, especially because it lets you test elements in isolation. Here are the two projects if you'd like to compare the code:

Homebrew ECS framework on top of the babylonjs engine: https://github.com/EamonnMR/Flythrough.Space

Godot with networking: