jsFO - Javascript Fallout2

hardsetHead

First time out of the vault
Hi guys,
I've been busy for a little while working on a bit of a portfolio project.

https://github.com/ajxs/jsFO

My project was a conversion of the Fallout2 engine to be playable in your browser. After a good deal of work, I've come to the point where, for the time being, I am unable to commit to working on the project on a regular basis. I've made quite a bit of progress thus far, but due to the limitations of the platform I've decided not to continue the project to completion. That may change in the future, but as the project currently stands I don't view the goal of playing Fallout within the browser as being realistic and feasible. From time to time I might fix a few things here and there, and if other people are interested in helping out I'd be more than happy to get involved again or give any help I can.
The project has always been open-source, and I've decided I'd like to publish the code here so that it can provide a good basis from which other mod authors, or interested parties can learn ways in which a port of the Fallout engine can be accomplished.
Should there be interest in the project, I plan to publish documentation of the engine and it's functionality over the next few weeks.
If you want to test it out, all you have to do is download the source, and run the index.html file.
Currently it has several maps converted. It'll load up the Gecko Power Plant by default.
Be aware, that the project is in a 'non-playable' state. Presently, you can run around the map with minimal object interaction. But it demonstrates the capabilities of the engine fairly well.
Feel free to report any problems running it you have here. I'm still willing to fix minor problems here and there.

The main hurdles to a full playable release, as I see them, are:
* Due to the way the browser works, all game assets need to be converted to native browser formats and loaded into the browser's memory prior to launching the game. Even with compression these files can be quite large, which would place a large burden on the user if they were streaming the game online. Even though the capability for this currently exists.
* Lack of documentation of the scripting engine: even if I was able to commit the time to making a vm in Javascript for running the scripting engine, I'd still need to do large amounts of research into the actual implementation of the scripting engine itself. Which would be more than I'm willing to take on.
* Certain rendering processes, such as animated palettes and realtime light-mapping of objects are quite costly in terms of FPS, or outright impossible due to the limitations of real-time asset loading. I've already implemented a fairly hacky framework for light mapping, but it's rough at best.
* Real time loading of assets is nigh on impossible. Javascript is unfortunately incredibly slow in this regard.

Nevertheless, if anyone is interested in further development feel free to get involved!
I'd be more than happy to answer any questions of how things work.
Let me know your thoughts!

Also, you can download the current version zipped from this link:
https://github.com/ajxs/jsFO/archive/0.0.5.zip
 
Last edited:
This is unbelievably cool. I work as a web developer and use Javascript every day, but I spend my time off modding Fallout 2. It's amazing what you've done here.

Couldn't the CPU-intensive tasks be handled serverside?
 
This is unbelievably cool. I work as a web developer and use Javascript every day, but I spend my time off modding Fallout 2. It's amazing what you've done here.

Couldn't the CPU-intensive tasks be handled serverside?

If you're interested in this, you might also check out DarkFO, in which I aim to make an entire port of the FO2 engine to the Web and be playable. It's not open source yet, unfortunately, but I hope to continue working on it and incorporated some of the really cool ideas and code jsFO has.

Anyway, this is a great project!
 
why is playing FO in browser so great? What's wrong with playing it the way we're playing it now? Is there any real benefit from this new system?
 
why is playing FO in browser so great? What's wrong with playing it the way we're playing it now? Is there any real benefit from this new system?

None at all, but a complete rewrite (in a more appropriate language) would give us full control over the engine, and finally let us edit all perks and hardcoded behaviors. The more people who are interested in doing such things, the greater the chances of such a rewrite actually happening one day.
 
why is playing FO in browser so great? What's wrong with playing it the way we're playing it now? Is there any real benefit from this new system?

Mostly it was just a way for me to demonstrate my coding abilities. From there I explored the possibilities of what could reasonably be accomplished on the platform.
As it says in the post, I don't think it's something that is long term feasible. But if anyone else is keen on this sort of idea, don't let me discourage you!
I know darkf is working on something similar, and of course, I wish him the best of luck! :)
To give you an idea of your limitations...
Precaching all the main game assets, and all the assets for a single level ( in this case geckpwpl.map ) is about 16mb of assets, and that's not even every possible animation for all of the actors present, only enough to have them stand and walk around with all the guns. I've separated the main asset loading from the map loading to minimize duplication of loading efforts. Of course, there are many possible ways of accomplishing this.
Which brings me to:

Couldn't the CPU-intensive tasks be handled serverside?
( Thanks for the kind words too Magnus! :) )

Initially, I had the main Python loaders all wired up to a cgi app on my server so it could request assets from that when needed, but the conversion/transfer time isn't really something reasonable. Doing it on the server in Python is indeed faster than doing it client-side in Javascript, but the transfer times render any benefit moot. Plus, I thought decoupling it as much as possible from needing the server was a smart idea. One way or another, you come up against a problem.
Loading assets one by one in Javascript is more or less impossible. There's a huge overhead on xhr's, and even Javascript were as fast at parsing binary data as other languages, it'd take about 3minutes to do something that Python would do in about 3seconds.
Just to clarify, Javascript isn't going to handle realtime loading of anything. So any ingame asset is going to need to be converted to JSON prior to starting the game.

I won't say this task can't be overcome in some creative way. But you'll have to overcome those particular hurdles. To sum it up: The biggest problem you're going to have to deal with is precaching assets. Everything else is pretty much fine! ( aside from lighting that is hehe )
 
Precaching assets isn't that big of a deal. I have scripts to convert all of the data files into formats I can use, and then just load those through an HTTP server. Most maps load in about 30 seconds, but this is over a local connection (negligible latency, high thoroughput). Over an Internet-connected website, loading times would be much worse, but I never planned on doing that anyway (it would be fine for a personal game, but once you start sharing the assets you get into dark legal territory.)
 
Would BSON instead of JSON make any difference?

Most of the data is images, not JSON, really. Although I started investigating using BSON for save games and found that it's the only way to reasonably do that without writing a custom serializer. BSON is a *ton* faster *and* smaller than JSON (JSON would completely hang for a few minutes and result in a 23 mb blob of text, whereas BSON would serialize it almost instantly and give me 233 kb of binary.)

You could use BSON for the map and ancillary data too, but then you're just squeezing out a few hundred kb.
 
Back
Top