@everyone As the internal crate

network-core

grew in size and scope, I realized that we might as well rename this to

fishfight-core

and move all core functionality to this crate, so that we have an engine library, using Macroquad and Hecs, that we can distribute for (internal) use.

This means that we will need a catchy name for this library (currently,

fishfight-core

), so we are asking for any good ideas you guys might have, in that regard!

All reusable code will, from now on, be put in this crate, in stead of

fishfight

. This means components like

Transform

and

PhysicsBody

, as well as core utility stuff like

crate::math

. Existing code will be moved over, gradually, as I/we work with the code base.

The aquarium 😄

Nice. That reminds me of a company name I was considering for a startup: Simulacrum

As we progress and the various systems are cleaned up (as outlined in the issue on github), we will focus on divisions between implementation details that are specific for our use case (fishfight) and more general, so that the more general systems can be added to core

Simulacra and Simulation (it's a book)

I'm all about the gnostic stuff, so Simulacrum is an awesome name

Also worth noting for people that this effectively a continuation of

yeah, this will probably replace the toolkit, as efforts go for my part, when FF is done

I was planning to transition to hecs there, when I was done with ff, any ways, but that would make them so similar that there is no need for two projects

And as such, this engine will gradually cover a series of niches. We’ve basically got ‘2D pixel Platformer engine’ nailed down. We’re gonna get into ‘2.5D pixel side-scroller’ and ‘top-down pixel’ before long. And RPG is also there already.

yeah, it is very easy to customize now, as we use hecs, so it will just be a matter of constructing a runner in the main method, according to use case, kind of similar to how amethyst did it

implementation will be done in systems, not states, though

or both, maybe, as you need states to transition between menus and gameplay, etc

Fun case of RPG niche engine here btw:

> Bonfire is ideal for building games from the following perspectives:

I like that kind of specificity. You know exactly what you’ve got to work with as a designer.

that looks good! We need to get lighting at some point (most likely requires control of input vars on shader level, in miniquad/macroquad, though)

So are you using macroquad as a basis for a custom engine?

yes, macroquad and hecs

Interesting

We should probably reassess how much we’ve got in common with @User’s at this point.

seems similar in some regards but we have a very specific asset loading strategy, which will also be the backbone of out-of-the-box mod support for games that use our library

as I mentioned in a pm to @User, I will spend the next few days to implement the mod loading, and that will probably be one of the core selling points of the library

So wait, this thing already has a level editor. Will that be turned into an actual game editor?

especially when we, some time in the future, also add support for mods that contain logic (scripts) and not just extensions via JSON data and assets, like what will come now in phase one

We plan to make this the way to edit entities, as well as maps, in the future, so yes, probably

for that we will need to do something better, ui-wise, though. Macroquad UI is simply too limited to use for such an application, imo

maybe keep the current as an internal map editor and make an extended version using a more native-like ui framework