sparky-game / sparky Goto Github PK

Describe your issue

The weapon's model position in the 3D world space coordinate system only gets adjusted each frame by the camera's position. The problem is that it doesn't take into account where the camera's looking at; so whenever the camera looks around, the weapon's model gets lost out of the camera's viewport.

Steps to reproduce

1. Launch the game in offline mode.
2. Rotate the camera with the mouse.
3. Notice how the weapon's model doesn't stay static in the same position.

What was the expected result?

The weapon's model should always stay in the same position, as it's attached somehow to the camera.

Put here any screenshots or videos (optional)

No response

Describe the feature

Create basic unit tests for the sk_darray module with the Carbon library.

Why should it be implemented? (optional)

To start using the Carbon library, and start testing some core components of the game.

Do you think there is any alternative? (optional)

No response

Additional context (optional)

No response

Describe the feature

Create a basic yet modern product website so users and visitors have a nicer and a more complete experience.

The source code must be hosted under docs/www and, for now, published through GitHub Pages.

Why should it be implemented? (optional)

Every product has to have a website, so users can see what is all about.

Do you think there is any alternative? (optional)

Yes, but in this case I'll stick with Docusaurus.

Additional context (optional)

No response

Describe the feature

Create basic unit tests for the sk_rngbuf module with the Carbon library.

Why should it be implemented? (optional)

To start using the Carbon library, and start testing some core components of the game.

Do you think there is any alternative? (optional)

No response

Additional context (optional)

No response

Describe the feature

Right now the help panel looks kinda plain, maybe it'd be cooler to print it using different colors... or maybe not 🤔

Why should it be implemented? (optional)

To make a better impression to the end user.

Do you think there is any alternative? (optional)

Keep it without colors is always an option :)

Additional context (optional)

No response

https://www.youtube.com/watch?v=_k4TaZmSteY

Spec

https://github.com/sparky-game/skap-spec

This can be used for the release version of the game. So, every time that we interact with an asset, we need to do different things whether we are in debug mode or not:

• Debug :: load assets from original files (.e.g. assets/icon.png, assets/models/7mm.glb, etc.).
• Release :: load assets from Asset Pack (i.e. assets.skap), so they are pre-loaded in the way that the game uses them, no need to load them again (i.e. no need to call LoadModel("..."), just read the bytes from the Asset Pack and store them as a Model struct).

Header

[4 bytes] Signature -> "SKAP" (char signature[4])
[1 byte] Format version -> 1 (u8 fmt_ver)
[8 bytes] Build version -> 202405201829 (u64 build_ver)

static u64 concat_num(u64 x, u64 y) {
  u64 n = 10;
  while (y >= n) n *= 10;
  return n * x + y;
}

static u64 compute_build_ver(void) {
  time_t t = time(0);
  struct tm *t_spec = localtime(&t);
  u64 t_spec_arr[] = {
    t_spec->tm_mon + 1,
    t_spec->tm_mday,
    t_spec->tm_hour,
    t_spec->tm_min
  };
  u64 build_ver = t_spec->tm_year + 1900;
  for (size_t i = 0; i < 4; ++i) {
    if (t_spec_arr[i] < 10) build_ver *= 10;
    build_ver = concat_num(build_ver, t_spec_arr[i]);
  }
  return build_ver;
}

u64 build_ver = compute_build_ver();
printf("build_ver => %lld\n", build_ver);

Index

Types of assets:

• Images (LoadImage(...))
• Textures (LoadTexture(...))
• Sounds (LoadSound(...))
• Music (LoadMusic(...))
• Models (LoadModel(...))
• Shaders (???)

Blob

The rest of binary data contained in a *.skap file appart from the Header and the Index.

Components

skap tool (serialization)

Asset Pack bundler tool, it ends up creating the assets.skap file.

sk_assetpack module (deserialization)

Asset Pack loader code, it loads the Header and the Index right away, then it retrieves data from the binary blob when requested.

Describe the feature

Add a new CLI option to Sparky, -g, --gui, to open up a GUI launcher to start offline, online to a specific server IP, or start the server. All logging messages must appear in a section in the GUI.

I think a very interesting candidate to do so is the egui crate for the Rust programming language. So, the GUI launcher must be a Rust crate that builds a static library, which needs to be linked to the final executable with the rest of the game by the Makefile.

Why should it be implemented? (optional)

It gives the user the option to launch the game in a visual way, without the need of opening up a terminal to play.

Do you think there is any alternative? (optional)

Sure. But I think doing it in Rust is a good oportunity of learning the language in a practical way. Also, it's nice to mix multiple languages in a project (Rust integrates very well with C code, so it's the perfect candidate).
Also, I did not want to do anything appart from the game itself in Raylib, so egui looks interesting enough.

Additional context (optional)

The Minecraft Launcher is one of the most classic pieces of software of this kind (until the complete rewrite in 2017 that made it horrible 😃). These are the legacy versions, to serve as inspiration.

First option:

Second option:

Third option:

Fourth option:

Describe the feature

Like in the Linux kernel, when executing make menuconfig a ncurses menu should open and it'll present all options declared in config.mk in a prettier form.

Why should it be implemented? (optional)

More convenient way to edit build system configuration options.

Do you think there is any alternative? (optional)

No response

Additional context (optional)