September retrospective

General morale

Quite bad, but I’m holding on okay (all friends and family safe and well, don’t worry). Pandemic wise at least it looks like numbers are heading in the right direction, so I’m looking forward to catching up with other humans hopefully soonish.

A month ago my tomato seedlings had just started to sprout; now they are brushing the top of the greenhouse. I may need to think of planting them soon, but the weather is still a bit cold. I might try to greenhouse them a week or two longer, I think.

I assembled a new chair. That was quite useful, as my employer paid for most of the cost. The study where I do my paid work is a bit more comfortable now.

An order from a local garden and tools retailer also arrived, so now I have more seedlings to plant – including marigolds, as I have decided to try companion planting this year in order to improve the robustness of my crops. Marigolds are good for tomatoes.

The garden itself is ready for new plants. I’ve cleared four plots of land about 2 by 2 metres each, so way more than I probably need; but I’ve got tomatoes a-plenty to plant with more to spare, so I will be able to make use of this space I believe.

Some of the lettuce that was unfortunately dead due to chemical burns from a bicarbonate of soda experiment has been cleared to make room for some mustard plants. Those seem to be taking, which is good. Parsley is looking happy too, and the sage is looking very happy indeed.

I decided to prune the olive tree near the letterbox so that it is a bit more accessible to new letters and small parcels. The fruit trees look like they are going to have an abundant crop this year, even though the apple tree was chewed to nubs by possums last year around (apple tree leaves are very sweet, I’ve been told). Very robust it appears, apple trees; we’ve certainly had plenty of rain though. I might need to decide on a strategy for harvesting the fruit; it does seem wasteful but maybe we will let the birds and flying foxes have it like we usually do — although I could invest in some fruit tree nets. I sprayed the cherry tree with Pyrethrum (carefully) when I saw thrips starting to lay eggs on it. I also weeded quite thoroughly around the front, and disturbed a large frog in the process.

Other highlights … my neighbour recounted that he once saw a kangaroo watching his housemate and his housemate’s son playing on their xbox through a window at a strange time of morning. Pandemic life.

What went well?

Over the last month I:

• Solved automating deployment of an Ubuntu VM running wordpress with woocommerce pre-installed. This allowed me to get to a point where I had an ecommerce site ready for a business, so unblocked my previous work from June.
• Pivoted back to my June project and made very rapid progress, involving deploying a node.js app to heroku, getting a webrtc godot client working against it, plugging in the book-keeper, and implementing round-robin handover should the host of a lobby drop the connection.
• Furthermore, I laid the groundwork for determining how to build a non-trivial webrtc godot client, by doing a bit of research and poking at code.

So this month was a triumph productivity wise. I moved from strength to strength, and smashed any form of expectations regarding what I originally expected to achieve this month.

What didn’t go so well?

I abandoned sprint discipline and dropped work on one sprint in order to suddenly start work again on a completely different board. So in terms of planning, this month was a disaster. However, there is a philosophy in agile that agile is good to follow until it gets in the way; I think this was one of those times.

What’s the outlook?

Evidently the platform etsy clone project is no longer on the go. I might pick that up again next year – we will see how we go.

But my passion project is definitely looking promising again. In particular, I would like to aim to get a prototype godot multiplayer client running with webrtc on different computers by the end of October. If I can do that, I will have the project at a point where I can start sharing it with my friends for early feedback in November.

Evidently, I still need to figure out the whole in-game level editing shtick – but there are plenty of promising tools being developed at the moment, like Concept Graph, and other projects where developers are building these things directly, like Rungeon, so I might just continue to monitor these other efforts and learn what I can part time, until the networking angle is finally solid by close October / November. Hopefully towards the end of this year I can work out a sensible strategy for building something useful along said lines in 2021.

Discovered another project that I can use as a webrtc multiplayer template

Today I found a project that I can use, together with the godot office example one, in order to finally wire the dnd sandbox client together and make an operational webrtc multiplayer game.

I discovered this by discovering this itch.io link. One of the comments led to this reddit thread, which led to this link, at a particular developer’s personal website.

Unpackaging the file and mounting in Godot led to no immediate joy, as Godot will not allow for running multiple instances of itself to serve WebRTC directly.

Instead, to test it I first ran the node server, then compiled the godot client to html5, then ran http-server in the directory (due to security matters with wasm files), opened two browser tabs, and was able to test the game successfully.

So this is a fantastic place to launch from. Various bits and pieces are at hand:

• Godot docs on high level multiplayer and webrtc
• A comment on a video by TheApeMachine
• The Godot webrtc signalling server demo
• And now this particular Godot template project

I should have plenty to get going with now, and I feel that the difficulty of building a prototype multiplayer game is now not nearly so great.

Some minor research

Today I did a bit of research to see if there were any more complex extant demos I could just crib to accelerate progress on my project. I did find this comment on a particular video May 2020, comment dated from a couple of weeks ago. The video is associated to this github project. I took the github project for a spin, but concluded that it was probably not sufficient for my usecase.

I suspect that although the code in engine is a year old now, there is still not a large amount of common knowledge regarding how to implement webrtc in godot. So I suppose I will have to do things the hard way in the interim.

Round robin notify that host has changed

Today I:

• configured the example to emit a signal if there happens to be a new host for a lobby, and wired it up
• altered the signalling server to send a message to a client to in turn emit said signal if a host is changed for a lobby

This is useful because if I want to hook up any custom logic in the game client associated to the previous host leaving, and a new host being assigned, I can now do it.

I also added the WebRTCclient as an autoload script, and poked at the code a bit to try to understand it better.

Going forward I might have a bit of work to do, because I will need to convert much of the MultiplayerENet stuff to WebRTC in order to get the proof of concept working. Hopefully though I can munge something together and then tidy things up a bit later.

Solving the problem of persistence of the webrtc connection

Something that has been puzzling me since starting this current project for some time has been how to ensure that, when switching scenes, I can hold on to the multiplayer connection. For, in the sandbox client, I do need to be able to switch scenes.

The solution that I’ve settled on is to make the relevant client an autoload script in the game. The example places it on a node in the demo scene, but this won’t work for me as stated before, because I’ll be wanting to switch out the initial scene for the level scene (for the initial goal of loading a level, and driving around for instance).

With this change in mind, I should then hopefully be able to adapt the existing networking logic (which works on localhost, but is geared around the NetworkedMultiplayerENet class, and not the WebRTC one) to the new webrtc client.

It is quite likely that I’ll want to make a number of simplifications in order just to get something working, but hopefully things should not be too difficult.

Adventures in photogrammetry

Today I was pushed to try to fix my office chair.

Recently I ordered a new chair from Kogan. It is a relatively good piece of gear, but it happens to have a flimsy backrest that broke fairly quickly. I was thinking of using 3d scanning software to capture the shape of it, then 3d print a replacement part.

After some web research, I determined that what I am interested in is photogrammetry, and in particular, since most software has strings attached in that space, likely something opensource. Meshroom (https://github.com/alicevision/meshroom) seems to be an answer here.

So I think the general strategy will be to take a number of photos of the offending item, attempt to denoise them a bit, plonk them in a folder, and then point Meshroom at it and hope for the best.

After I have my 3D model I’ll probably aim to touch it up a bit in Blender and remove any artifacts, before exporting to stl format and approaching an outfit with the file to 3d print it.

I’ll likely want to have one experimental print on low quality resin first, so that I get an idea regarding scale. Then if all goes to plan I might be able to print a number of things on less flimsy material (so I have backup replacements) and also maybe improve the engineering of the struts of the thing, so that it is less flimsy in that respect, too.

Prework on the sandbox client

Today I spent some time thinking about how I would be able to dovetail my learnings with the sample client into the sandbox client (written in Godot).

My initial conclusion is that perhaps the best path is to abandon the existing scaffold I had for the sandbox, which was based on the Godot Getaway tutorial, in lieu of the simpler (and working) webrtc multiplayer godot example. There are two key reasons for this – one is that the webrtc multiplayer implementation / class is different to that used in Godot Getaway, so a lot of the logic that I originally wrote will be completely irrelevant (and, indeed, only work on a single computer with multiple controllers). The second is one of lack of attachment – I haven’t touched the sandbox client much for close to six months now, so I’m not really terribly vested in it at present, which presents an opportunity to break new ground.

Therefore, I’ve decided to work with the new project, and scavenge whatever I find useful from the old in order to get a simple proof of concept level working.

The proof of concept I want to get working is this: based on an initial screen, I want the client to be able to specify whether to start a new game or to join one.

If the client starts a new game, it should register that with the signalling server with a randomly generated lobby name (this will change later, but this is good enough for now). It should then be dropped into a very simple level and handed control of a car avatar, which it can drive around.

If a client wants to join an existing game, it should be presented with a list of currently running lobbies from the book-keeper. It should then be able to select one of these by clicking on it. Once it has selected one of these, it should then be able to click confirm, and be dropped into the same level as the host, and handed control of a different car avatar, which it can drive around.

Further requirements are that all cars “within a lobby” should be synchronised with each other, and it should be possible to have multiple lobbies with different instances of car levels with different peers, all synchronised with each other. A lot of the enabling logic here I should be able to scavenge or adapt from the existing sandbox scaffold.

A key problem that I need to solve is how to persist the webrtc multiplayer object between scenes in Godot. I suspect that I might need to make it a global object (if that is possible), but we will see.

GENE-3D and plasma physics progress

Today I heard about how the Max Planck Institute has made further inroads in terms of fusion power plant progress, with the announcement of a sweeping generalisation of a previous plasma physics numerical simulator (a piece of software), called GENE, to “GENE-3D”. (Progress in software might not necessarily sound as exciting as progress in hardware, but in complex projects like nuclear fusion, if one has better and more precise ways of modelling a real system, then this enables and facilitates later hardware improvements. In this way, hardware and software work synergistically in a form of feedback loop, one improving the other, in terms of sharpening one’s ability to solve a particular focused engineering problem.)

GENE, an acronym for “Gyrokinetic Electromagnetic Numerical Experiment”, presents a highly simplified form of plasma physics equations (presumably making various dimension reductions and asymptotic simplifications vis a vis similar methods applied to Navier Stokes within the operating regime of the plasma), which they term “gyrokinetic equations”. Previously GENE was a 2-dimensional model which was highly efficacious at helping to optimise Tokamak designs and procedures, such as that fast ions can greatly reduce turbulent transport in tokamak plasmas.

Turbulent transport is a problem for efficient operation of a candidate fusion power plant, as it leads to loss and potential leakage from the contained plasma, which leads to requirements for larger plants and more maintenance in order to control and/or deal with the leakage, which leads to more expensive energy. Therefore any way that engineers can find to reduce it is good.

Regardless, even with the highly simplified gyrokinetic plasma equations, GENE was still constrained by a 2d model of a highly symmetric system, a tokamak. And even with those assumptions, the most powerful supercomputers struggled (and still struggle!) to run the simulations.

That is what makes this forthcoming paper so impressive, since Maurice Maurer and co-authors were able to generalise this model to 3 dimensions, and in particular the types of geometry that are found in Stellarators – evidently much less regular and symmetric than a tokamak! Evidently they were able to do this in a way still tractable for a modern supercomputer to solve. In particular, initial simulations suggested that the fast ions trick (suggested by its predecessor GENE-2D for tokamaks) should be able to decrease turbulent transport in a stellarator by more than 50%, which would be tremendously useful. The paper, “GENE-3D: A global gyrokinetic turbulence code for stellarators”, can be found here (forthcoming November 2020 publication of the Journal of Computational Physics).

Notified book-keeper regarding new host

Today I had a look at the WebRTCMultiplayer api in Godot. It doesn’t appear to support what I need (all peers are equally important), so I’ve decided to transmit the information regarding lobby host from the signalling server to the book-keeper. In particular, I implemented that today, and deployed the new apps to their respective heroku locations (and also did another heroku run rake db:migrate for good measure).

Now it looks like the preliminary networking stuff is done save for tweaking the Godot client to communicate with the book-keeper and/or periodically poll it. A more optimal approach might be to only poll the book-keeper if a client leaves; however given that a client might not leave cleanly this probably would not work.

So probably I’d want to poll the relevant endpoint once every minute or so, and thereby indicate whether or not a new client is the host.

After doing that, I’d like to load a list of lobbies into the client UI so that a user can decide whether to join an existing lobby or start their own. If a user wishes to start their own, I should also allow them to give the lobby a sensible name, rather than a random string of characters.

Last but not least, I will want to ensure that there are not networking glitches between clients in my example scene when a game instance is eventually joined by a webrtc peer.

Implemented round robin lobby handover

Today I implemented round robin lobby handover for the signalling server.

Next, I’d like to ensure that the client indicates when it is the new host / has been nominated the new lobby owner by the signalling server. I have a feeling that that will lie somewhere within the Godot docs, if anywhere.