I have a multiplayer cooperative game project in mind and my main concern is the game map.
A bit of context
The players interact with a world map. This map is a first pre generated. This map should be tiled based (each tile representing a part of the world). However, the players should have the capacity to change the map (build something here, destroy another thing here). These modifications of the map should be visible for all other players.
Question
What is an efficient way of doing this ?
Classic array stored server side and update this array when a user does an action? Wouldn't it be quite CPU consuming on client side when building the map from that array? (image maps? <map></map>)
Use a game "engine" such as gdevelop or babylonjs?
From my point of view, for me to be able to fully customize my map, the array solution seems an easy way to get it done. But I don't have any experience on this topic.
I have recently hade a look on this map generator and tried to build a map on it (<map></map>), but this does not allow me to customize the map after it has been generated.
I think your best option would be to:
Store the map data in a simple serializable data structure. For example a double array of objects with some integers - a Tile Type enum, a Building Type, state data if you need it, etc. That will allow you to easily serialize and send the data between the server and the clients.
Use a game engine / canvas renderer / webgl renderer to render a view to the client by using the data array. I have experience with PIXI.js (a 2D rendering framework using either WebGL or Canvas) and Phaser (a 2D game engine, build on top of PIXI). So i can recommend you those two if your game is 2D. PIXI is used just for rendering, there is no game logic in it and you will have to implement it. It's good if the game is not that complex or if you want to learn how to do stuff on your own. Phaser on the other hand is a full game engine that has all sorts of game development functionality, but that also means that it's more bloated with things that you might not need.
When a user clicks something send to the server that "user x clicked tile x,y", process the input, edit the main data array and send it back to all clients. You can use Web sockets for that or just plain HTTP requests
Alternatively you can use one of the "big" game engines and just compile it down to js and html from there - Unity, Godot, Cocos creator (in this one you actually write in JS)
Related
With each passing day I'm getting more and more annoyed with Cesium.
There was a project that used QuadTreeProvider to create 3D structures from WFS data.
But the Cesium guys saw the 3D stuff was more lucrative and not only created difficulties to create WFS primitives but created mechanisms to avoid all types of use other than its "Ion 3D tiles".
Now, any kind of question involving 3D they answer with a commercial answer like:
"That sounds like the ideal use case for 3DTiles except for the
dynamic data. Depending on your needs and resources, you could always
contact Todd at todd#agi.com to talk about possibly getting your data
working with 3DTiles."
Of course we can contact Todd. But I don't want to! I want to use free 3D stuff. I WANT to use Geoserver WFS data Todd. Can you allow this for me? Can you allow this project to work again as before?
If you want to make money from your products, you have every right to do so, but don't stop users from creating their own solutions if they don't want to contact Todd.
After all, my question is: How can I use WFS data from Geoserver to create 3D objects in Cesium without need to use Ion / 3DTiles ?
I am working on a Wysiwyg Editor for CesiumJS content.
The user will be able to create many points, lines and other graphics, connect them according to definable relations and group them in separate Groups.
Now I am wondering what the best practises are in terms of performance.
At the moment I create one PointPrimitiveCollection for each Group
and then add points:
group.points = scene.primitives.add(new Cesium.PointPrimitiveCollection());
and then
group.points.add({
position : cartesian,
...
});
for each new point.
Polygons are created using:
network.hull_polygon = viewer.entities.add({
name : 'xxx',
polygon : {
hierarchy : Cesium.Cartesian3.fromDegreesArray(points_array),
material : color,
...
}
});
polylines similarly.
Now since the Objects can also be dragged around / animated, I was wondering where Cesiums entity logic would come in?
Thanks for all help!
Cesium's Entity logic is useful primarily for objects that move along a known path over time, for example the flight plan of an aircraft in the future, or a GPS recording of the route taken by a vehicle in the past. Such routes can be loaded into the Entity system (often via CZML), and the user can run the simulation time forwards and backwards at arbitrary speeds, to review the routes of all the vehicles. The Entity system owns the logic for updating graphics primitive positions based on simulation time changes.
Entities are also often used as a quick way to make some disparate graphics primitives associate with each other. For example, a polygon, a point, and a label can all be created as a single Entity even if they are three separate graphics primitives at the same location. This saves a bit of effort on the part of the application developer, and doesn't hurt performance too much since the properties involved are all marked as constants, so the Entity layer knows not to update them with simulation time.
But, it sounds like you may have a case where paths are not known in advance. For things like user interactive edits or real-time telemetry being received, the Entity system can't know what's coming up next, so its whole system for updating positions from simulation times is not doing you any good. In that case it may be better to skip the Entities, and deal exclusively with graphics primitives for this. This would mean you need to write your own update function to alter graphics positions as new information is being received, similar to the Entity layer's update functions, but based on your own live inputs instead of recorded paths.
Note that the public "Sandcastle" demos only include Entity demos. But, if you download and build the source for Cesium and run Sandcastle locally from a dev build, a separate tab appears in the Sandcastle Gallery called Development that shows a whole set of demos based on graphics primitives as opposed to Entities. This can be useful for seeing examples of how to control things at this layer.
Hopefully this is helpful in understanding how the different layers of Cesium interact.
Is there a way to reduce mesh polygons?
As an example project I use the TGA model provided by Autodesk. (https://knowledge.autodesk.com/support/revit-products/getting-started/caas/CloudHelp/cloudhelp/2019/ENU/Revit-GetStarted/files/GUID-61EF2F22-3A1F-4317-B925-1E85F138BE88-htm.html rme_advanced_sample_project.rvt)
If you add all instances to the scene you get a polygon count of about 1.3M.
For the computer this is no problem at all. The model is downloaded in about 1 min and displayed completely.
For my iPhone ( iPhone 8) this is clearly too big.
As soon as I start the AR Scene and download the model, the memory requirement rises to over 1.2 GB (bevore 0,15GB) and crashes the app.
Even if you exclude some instances (walls, ceilings, etc.) before processing the scene to display only the technical building equipment, the model is still too big for the iPhone.
Are there possibilities to reduce the mesh with the ar-vr-toolkit api . Do I have to do this manually in Revit?
Edit: 27.06.18
Here is the model i want to display in AR (Tris: 2.8m, Verts: 2.4M).
Steps:
1) Upload the original .rvt file (70mb) to my bucket.
2) Translated the file via forge.
3) Created a scene with ar-vr-toolkit api.
4) Processed scene witha ar-vr-toolkit api.
5) Downloaded the scene to unity.
6) Created a prefab.
The Meshes are way to detailed. The Graphics would not change a lot if i reduce the Vertex count to 10-15%.
In Unity i can use assets like Mesh Simplify (https://assetstore.unity.com/packages/tools/modeling/mesh-simplify-43658) to reduce the count.
An other way is to export the model to e.g. 3D max or Maya to reduce the count.
But i want to try to do this automatically.
My question is: Is there a way to to this with Forge?
Image 1
Image 2
My colleagues who are expert on this area are on vacation now, so let me try to answer your question first, and my colleague may add some more information later.
Unfortunately, the answer is No AFAIK. For the Forge AR|VR toolkit service, I remember there are some mesh reduction work done automatically at server side if it detect the client device is Hololens or DAQRI, you can get that info if checking https://github.com/wallabyway/ARVRToolkit/blob/master/unity-src/ARVRToolkit/Assets/Forge/ARKit/RequestQueue.cs#L155. But that's it, we do not provide any API to help reduce the mesh, and there is also no API within Forge which can do that either.
As you already know, you may need to do the mesh reduction in some other product, like 3ds Max, that's the current way I can think of.
My colleague may have more comments on this when they come back.
It seems most Bokeh embedding examples are using bokeh.plotting.figure object. Is it possible to embed a high level chart, like bokeh.charts.Bar or bokeh.charts.Scatter? Or is it possible to have convert a high level chart to a bokeh.plotting.figure object?
Thanks a lot.
The User's Guide section on Bokeh APIs has a good run down of how all these parts fit together, that I would suggest reading.
The long-story-short: Regardless of what API you use, bokeh.plotting or bokeh.charts, the end result is always just a collection of the same low-level bokeh.models objects. You can can think of bokeh.models as very basic building blocks, and the other higher level APIs as conveniences that help you to assemble the building blocks more efficiently and correctly.
So, in that light, yes, it is perfectly fine to embed a bokeh.chart using exactly the same functions described in Embedding Plots and Apps.
The one thing I will add is that if you need to update the plot's data after the fact, in place, then the bokeh.figure API will probably be more straightforward. The mapping between your data, and what gets plotted is more direct. Things generated by bokeh.charts may transform your input data into entirely different forms before plotting (e.g. you give a series, and Histogram has to spit out coordinates for boxes—not the data you started with)
I'm currently trying to make a small platformer, but don't want to use Tile2D (specific reasons), what should I use instead to make platforms (objects the player can collide with).
At the moment, I have a List with every Rectangle the player can collide with and I go through every Rectangle when I want to check collisions, but I find that to be very clunky.
What should I use to make platforms, the player etc. I haven't used Box2D yet, dont know if its the thing I need and am also not sure wether Scene2D is the thing I am looking for. Any tips would be appreciated. Not sure if this is the right place to post this, but its worth a try.
Don't mix two things:
Box2D is a physics engine that allows you to simulate physical world with its whole actions like collisions handling, applying forces or velocity etc
Scene2D is a framework to "clean up" handling objects you want to manage - by definition it is scene graph that allows you to treat bunches of objects as single objects (groups) and apply for them some actions (like setting position on the screen)
So basically when Box2D is more about how objects will behave themselves during application running the Scene2D is more about how you write your code before application running.
Of course Scene2D is very helpful if you want to implement your own mechanism of collisions (like you wrote - you have rectangles array, then iterate over them and check their positions... etc) but the Box2D deliveres you this mechanism so you don't have to do nothing to check just tell the application what to do when collision will occurs.
Then it is problem about is it worth to implement your own collisions mechanism. The most frequent answer I guess is - if the game is simple and the mechanism will be then yes. If not just use physics engine - do not invent fire again ;)
To read about Box2D and learn how to use it visit:
Libgdx box2d intro
Box2D official manual
To read about Scene2D:
Libgdx Scene2D intro
This tutorial