Skip to content

Idiomatic Go - biggest breaking change yet #13

@EtienneBruines

Description

@EtienneBruines

So, I was told by some people at the slack-chat, that we aren't using idiomatic Go. There may be collisions between the Type() string methods, and we're wasting performance by doing constant lookups.

They said: why don't you use reflect? Well, reflect is horrible so I don't want to use it.

But the idea is simple: get rid of the global []Entity, which stores every Entity. Instead, add the user-made entities to the appropriate systems,


Usage would be something like:

type MyEntity struct {
    BasicEntity
    SpaceComponent
    RenderComponent
}

func main() {
    // There'd be some kind of global list of systems, which contain every system, so we can loop over them
    var systems []BasicSystem

    // Each system we create, we add to that global list of systems
    RS := &RenderSystem{}
    systems = append(systems, RS)

    // Then we can define initialize our own custom-made entity struct
    e := &MyEntity{}

    // Add the appropriate component-references to the RenderSystem - this way you know for sure which components the render-systems requires
    RS.Add(&e.BasicEntity, &e.SpaceComponent, &e.RenderComponent)

    // And now we loop
    for _, sys := range systems {
        sys.Update(0.25)
    }
}

Upsides;

  • It's blazing-fast. The current Component function takes 91ns per lookup, the ComponentFast about 18ns, and this approach takes 0ns. For something that might happen thousands / millions of times a second, this is nice.
  • It's idiomatic Go, in the sense that it uses Go's type-safety. If it compiles, it'll most-likely run.

Downsides:

  • You need a reference to each system you want to use. Where to keep those references? What if we changed Scenes? They would have to start using other references.
  • It would break everything

This change is huge, but might also be worth it. I'd love a discussion on this, and maybe a fix for the downside? @paked, @everyone?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions