stormwarestudios Posted December 20, 2017 Share Posted December 20, 2017 Hello! I've been diligently working on my game, and recently came upon the recently released BabylonJS v3.1 ... and I am super excited about NullEngine! My game is multiplayer client/server; the server component is Node.js running ActionHero v18 (and of course the client is running BabylonJS!). Taking a look at the documentation and accompanying example for NullEngine, it seems it does not run 100% out of the box. However... I've been able to get everything up and running under Node 8.9.3 with a combination of mock-browser, EventEmitter, xhr2 and sheer luck // assume this file is saved as mock-browser.js 'use strict'; const EventEmitter = require('events'); class ProgressEvent extends EventEmitter {} module.exports = { setupMockBrowser: () => { const MockBrowser = require('mock-browser').mocks.MockBrowser; const AbstractBrowser = require('mock-browser').delegates.AbstractBrowser; let window = MockBrowser.createWindow(); let opts = { window }; let browser = new AbstractBrowser( opts ); global.window = window; global.navigator = browser.getNavigator(); global.document = browser.getDocument(); global.XMLHttpRequest = require('xhr2').XMLHttpRequest; global.ProgressEvent = ProgressEvent; } }; To use this, it is as simple as: require('./mock-browser').setupMockBrowser(); I'm curious to know a few things: 1) Since the game supports multiple users interacting in different areas (e.g. multiple "rooms", multiple users per room, users can only interact with others in the same room) it makes sense to me to manage these "virtual player namespaces" separately, as one BabylonJS Scene per "room". Does this sound like a good way to divide up the game? Are there software limitations of managing multiple scenes simultaneously? 2) Since the game-server has many other responsibilities (database saves, websocket clients, periodic tasks via a task-runner) it seems wisest to manage the client-side-equivalent of the "render loop" in a periodic task, which would be responsible for updating objects' positions based on velocity, testing collision, and issuing events (via websockets) to game clients based on movement updates/positioning rather than the typical engine.renderLoop(). I don't need the updates to be real-time, but do need them to occur 'quickly enough' (e.g. every 100ms) that my game-server can keep up with the number of objects per-scene. Does managing my own engine.render() seem sane? (Now that I write this out I feel that updates and rendering are unrelated. I guess we'll see...) 3) For geometry collision, I'd like to have "proximity" and "actual" collision-testing; perhaps BoundingSphere for quickest/optimal proximity-testing, and BoundingBox derived from a mesh for actual collision. Good idea? Terrible? I'd love to hear the community's thoughts, and thanks for the amazing NullEngine update! Quote Link to comment Share on other sites More sharing options...
Pryme8 Posted December 20, 2017 Share Posted December 20, 2017 Pretty sure this is posted in the wrong section of the forum. Maybe move this to Questions and Answers? Or maybe Demos? Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted December 21, 2017 Share Posted December 21, 2017 I'll move it Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted December 21, 2017 Share Posted December 21, 2017 So..You should not need window. The nullEngine is designed to work without Window and Document object. We had one bug that is now fixed in 3.2 (So no more need for mock browser, window, document and ProgressEvent) 1. No problem to manage multiple scenes. It is a good usage of it. 2. Not at all. calling setTimeout(scene.render()) looks perfectly fine 3. Good idea And actually this is what I do for the collision engine (with a third level which is triangle collision check) Quote Link to comment Share on other sites More sharing options...
stormwarestudios Posted December 21, 2017 Author Share Posted December 21, 2017 19 hours ago, Deltakosh said: So..You should not need window. The nullEngine is designed to work without Window and Document object. We had one bug that is now fixed in 3.2 (So no more need for mock browser, window, document and ProgressEvent) Any indication when Babylon 3.2 will make its way to Github? Thanks for the feedback to my questions! Quote Link to comment Share on other sites More sharing options...
GameMonetize Posted December 21, 2017 Share Posted December 21, 2017 It is in github already: https://github.com/BabylonJS/Babylon.js/tree/master/dist/preview release And in npm as well Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.