I'm currently developing a robotics simulator from scratch (python+raylib) and, due to lack of game dev experience I went "full OOP" on it. A SceneObject with a lot of inherited interfaces (e.g. Collidable, Movable etc.). These are inherited and fixed at run time.

The main loop inevitably became:

  for scene_object in sim.scene_objects:
    scene_object.update(...)
  for scene_object in sim.scene_objects:
    scene_object.draw(...)

Having recently learned more about ECS[1,2], I started doing a bunch of experiments in a sandbox with turning the update() function into ECS. The idea is that the data is stored in columnar numpy arrays (components) + a lot of data structure optimizations for querying scene objects and fast access e.g.

  qr = scene.query(HasMotion, HasPosition) # query result acting like a np array of (N, ...) shape
  qr.position += ... # operate like numpy / vectorized

I'd love some feedback on it, e.g. what is it missing or what are gotchas I'll find out later on during the simulator development.

As an anecdote: I used Claude as an 'engineering manager', I wrote the code myself, it did the code review, tasks management and tests (super useful for corner cases).

[1] https://www.youtube.com/watch?v=qglU107_DA4 hytale's ECS video (great for beginners)

[2] Casey Muratori's latest video about the first ECS in the game industry (https://www.youtube.com/watch?v=73Do0OScoOU)

Comments URL: https://news.ycombinator.com/item?id=48500561

Points: 5

# Comments: 0

A more skilled person that understands all the underlying steps will always be more efficient in scaling up due to knowing where to allocate more.

basically... you always need the skills and the money is the fine tuning.

Nowadays I code for a living, but for sure this is the game that started the spark for me.

It was a great time and I feel that I can always run this game and get back to that childhood feeling.

On the other hand, for mobile apps, there is still a device-specific mentality.

Imagine web apps being built with a different flavor for all the major browsers...

I hope that the same level of standardization comes to mobile apps too with the option to use more device-specific features on top of the generic UI.

- one single machine - nginx proxy - many services on the same machine; some are internal, some are supposed to be public, are all accessible via the web! - internal ones have a humongous large password for HTTP basic auth that I store in an external password manager (firefox built in one) - public ones are either public or have google oauth

I coded all of them from scratch as that's the point of what I'm doing with homelabbing. You want images? browsers can read them. Videos? Browsers can play them.

The hard part is the backend for me. The frontend is very much "90s html".

How can you idiomatically do a read only request with complex filters? For me both PUT and POST are "writable" operations, while "GET" are assumed to be read only. However, if you need to encode the state of the UI (filters or whatnot), it's preferred to use JSON rather than query params (which have length limitations).

So ... how does one do it?

text on the left, render on the right pane

example: https://imgur.com/9rjoMa2.png

I insisted a lot on this unix (ish as it's not pipes) philosophy. It paid off so far.

We can test each cli app as well as make broader integration tests.

`zip out.zip dir/`

This results in a single out.zip file that is, let's say 500Mb (1:2 compression)

If you want to shard it, you have a separate tool, let's call it `shard` that works on any type of byte streams:

`shard -I out.zip -O out_shards/ --shard_size 100Mb`

This results in `out_shards/1.shard, ..., out_shards/5.shard`, each of 100Mb each.

And then you have the opposite: `unshard` (back into 1 zip file) and `unzip`.

No need for 'sharding' to exist as a feature in the zip utility.

And... if you want only the shard from the get go without the original 1 file archive, you can do something like:

`zip dir/ | shard -O out_shards/`

Now, these can be copied to the floppy disks (as discussed above) or sent via the network etc. The main thing here is that the sharding tool works on bytes only (doesn't know if it's an mp4 file, a zip file, a txt file etc.) and does no compression and the zip tool does no sharding but optimizes compression.

We need to separate and design modules as unitary as possible:

- zip should ARCHIVE/COMPRESS, i.e. reduce the file size and create a single file from the file system point of view. The complexity should go in the compression algorithm.

- Sharding/sending multiple coherent pieces of the same file (zip or not) is a different module and should be handled by specialized and agnostic protocols that do this like the ones you mentioned.

People are always doing tools that handle 2 or more use cases instead of following the UNIX principle to create generic and good single respectability tools that can be combined together (thus allowing a 'whitelist' of combinations which is safe). Quite frankly it's annoying and very often leads to issues such as this that weren't even thought in the original design because of the exponential problem of combining tools together.

It also simplifies the stack a lot to have a single set of sensors, so the software becomes mostly: getting good training data (iterative loops from failing production cases) and an efficient training algorithm.

This scales to more than just AD and also can leverage new breakthroughs from academia