Freeciv WebGL 3D
play.freeciv.org
play.freeciv.org
It is using the Three.js 3D engine. Currently it works nicely on modern computers and laptops with decent 3D hardware, and there could be some issues on some mobile devices. For example, old iPhone devices have very poor 3D hardware.
This is an open source project, so we're always looking for developers to help improve the game: https://github.com/freeciv/freeciv-web/
I did find the movement to be abrupt. So much so that I found it disconcerting to play. I would suggest a quick transition from one location to another for the units (maybe optional).
Does the 3D have animations on the models?
On the other hand, the graphics worked fine. The blue line for the feedback part of the "Go" command was ugly. The laptop has no discre(et|te) graphics, just what comes in the mobile Pentium it runs on. So the warning about compatibility might be overly strong.
The vertical aspect of the mountains is tricky. It adds an unnecessary challenge to lining up a worker with a mine or what have you.
There are clearly some aspects that apply to both the WebGL and HTML5 versions, so I have tried to focus on the WebGL side in these remarks.
- I notice you are using Collada 3D model files inside of a zip file: https://play.freeciv.org/3d-models/models.zip It may be better to store the models in glTF format. It would be smaller and faster loading. Although to be honest, the last time I checked converting to glTF with high fidelity was very difficult to do.
- You should probably have cache forever on your game assets (3d models, textures, etc.) but have version numbers or hashes (my preference) associated with them -- it will load faster.
- Even if you do not switch to glTF, it might be better to have each Collada 3D model as a separate resource, so that as you change things it doesn't have to redownload the whole zip file.
- It is weird that you have *.zip file. You can likely just serve the collada assets using the built-in HTTP gzip encoding: https://en.wikipedia.org/wiki/HTTP_compression Thus it will be handled by a faster path in the browser than using a JS unzipper.
- You may want a proxy scene of boxes to raycast against. Hit testing my simple scene takes 5ms and I have a top end computer. Ray casting against THREE.BufferGeometry in Three.JS is just unreasonably slow. And THREE.Geometry is just slow all around, even though raycasting is a bit faster than with THREE.BufferGeometry. Another approach is to render the scene a second time to the offscreen with unique colors per object. Then hit testing is just figuring out which color was at the pixel under the cursor. This is highly scalable and is a very commonly used technique in games.
You wouldn't use PSDs in your webpage. You'd use PNG/JPG. Pleas don't use Collada in your web page. Please use glTF.
tar.gz files compress the concatenation of all files, using redundancy between files to achieve better compression ratios.
Note that gzip and zip use deflate which has a small 32KB window, so if the repetition is more than 32KB apart it cannot be used for compression.
- You can use Canvas to draw to and then convert those to textures, that can make it easy to create very interesting pop-up information in the 3D scene. You could have the Canvas cleared to transparent and then write non-transparent stuff to it. Then you will have text and graphics floating in the air. Could look cool.
- You could use a DOF pass so that the 3D world could look tilt-shifted: https://en.wikipedia.org/wiki/Tilt%E2%80%93shift_photography https://threejs.org/examples/webgl_postprocessing_dof2.html
- You could use a Bloom pass with HDR to get some nice shines: https://threejs.org/examples/webgl_postprocessing_unreal_blo...
- You should probably try to use the STandard material model (GGX + Metallic + Roughness) in Three.JS rather than Phong. Looks much better: https://threejs.org/examples/#webgl_materials_standard
- Use the static serving of gzipped assets as discussed elsewhere.
- You should have hashes on your *.js files with caching for ever. This is pretty standard practice.
- Think about using the HDR stuff I contributing to Three.JS -- it can lead to amazing looking materials. Here is an example that uses IBL and HDR and tonemapping: https://threejs.org/examples/webgl_materials_envmaps_hdr.htm... https://threejs.org/examples/webgl_tonemapping.html Given that you are in daylight, I think this would work amazingly. Would look way better than simple lights. But it only works on Standard/Physical materials and not Phong materials.
I didn't look into too much more as I only looked at the production minified code.
Rendering a scene to another buffer is a good way, although you do need some minor tricks to get information such as position and normal of the intersection, particularly so with high precision.
It's worth noting that this approach causes a very costly GPU/CPU sync when hit testing needs to be done and the scene has changed since last time (because glReadPixels() has to be called to pull in the data from VRAM to RAM). This is wasteful if the scene changes every frame, as you're essentially limiting the performance of your GPU to the performance of your CPU. Rendering to a smaller off-screen buffer (thus sacrificing precision) or calling glReadPixels() at most on each Nth frame and relying on temporal coherence to save you from the most unpleasant false positives and false negatives.
Interesting quote from this article (not to diminish the feat of a webgl version on classic screens, gg guys!) :
> Support for virtual reality using Google Cardboard is also under development.
Flying around a world and manipulating armies sounds awesome, kind of like "google earth VR meets strategy games". I guess freeciv will need game controller support first to make this playable, though.
Please don't enforce password restrictions like this.
If you can't handle passwords with certain characters in them, you're probably doing something very wrong.
Highest Gfx settings (default). 2800x1700px window. Best out of 2 runs:
Chrome 56: 33 fps
Safari 10.0.3: 29 fps
Firefox 51: 13 fps
I can still play Team Fortress 2 at 1080p just fine on this tho ;)
That's somewhat disappointing, both in absolute terms as well as compared to your values. Although maybe it's being throttled at around 40fps which is probably beyond the point of diminishing returns?
Edit: Getting 35fps in Firefox, which seems to support the idea that it's being throttled somewhere around that value.
EDIT: With low settins & AA off, I get 12 fps.
Miserable :(
FPS: 1. Chrome Version 55.0.2883.87 m (64-bit) on Windows 10. AMD A8-3850 APU with Radeon HD Graphics 2.90 GHz 16 GB ram
On Firefox 51, I get 2 FPS (although probably roundoff error).
Doesn't matter if I use low textures without anti-aliasing.
I should not the CPU usage for shoots way up. So most likely the WebGL is not utilizing the GPU. I should note that the GPU is integrated into the CPU chip as an "APU"...maybe this particular model of APU isn't supported by the WebGL.
I mean WebGL has hardware acceleration, modern JS is quite fast. Is it just about performance or is there anything else?
Additionally, with something like this, I'd imagine it would be quite possible to port to a simple Node based system with OpenGL support without the need to embed a browser. Would probably improve performance too due to removed sandboxing.
I loved playing Age of Wonders with my friends on the same machine.
The captcha is solved, but the page doesn't recognize it. Is signing up really necessary for such a game?
I'm also wishing to see a Freetotalwar type of project. The map campaigns are turn based and highly entertaining.