DEV Community: ThousandthStar

Rust devlog: Part 4

ThousandthStar — Fri, 25 Nov 2022 14:50:56 +0000

Hello! Welcome to the fourth part of my devlog where I develop my multiplayer turn-based game. I previously didn't have a name, but I have decided to name it 8bit Duels! I think this fits the theme pretty nicely. Anyways, on with the devlog!

Refactoring

This devlog is all about refactoring, and how I made my code cleaner. I did this by creating a workspace shared between the client and the server. This allows me to directly serialize and deserialize packets into ClientMessage and ServerMessage enum variants. One reason I adore Rust is because you can pass parameters to some enums. This is great in my case, as I need to send some data between the client and the server. These changes were suggested by a user in the Rust gamedev Discord server (link to their website).

This refactoring was done over most of the networking code, so I won't show everything here. The code is on Github here if you want to check it out (stars are greatly appreciated).

The main thing is that I now need less logic to handle packets. Before, I was creating some raw JSON in the client and putting a packet-type value in the object. I was then matching that value on the server-side, and vice-versa. This is an extremely bad practice, and it resulted in longer tedious code, since I needed to also get the other variables in the packets by their name in the JSON object. Now, I've just created a shared common package along with the client and server packages. It contains these simple API packets:

#[derive(Serialize, Deserialize, Debug)]
pub enum ServerMessage {
    // 1st param: whether or not the player is player_1
    StartGame(bool),
    StartTurn,
    // 1st param: the `CardEntity` to spawn
    SpawnCard(CardEntity),
    /*
    1st param: the initial x position
    2nd param: the initial y position
    3rd param: the final   x position
    4th param: the final   y position
    */
    MoveTroop(i32, i32, i32, i32),
    AttackTroop(i32, i32, i32, i32),
}

#[derive(Serialize, Deserialize, Debug)]
pub enum ClientMessage {
    Deck(Vec<Card>),
    MoveTroop(i32, i32, i32, i32),
    AttackTroop(i32, i32, i32, i32),
}

Using serde_json, a great JSON library, I can just serialize and deserialize packets into enum variants. These are handled like so on the client (I removed, the logic, since it's very straightforward):

if let Some(message) = guard.pop_front() {
        match message {
            ServerMessage::StartGame(is_player_1) => {
                // Starting the game
            }
            ServerMessage::SpawnCard(card_entity) => {
                // Spawning troops
            }
            ServerMessage::MoveTroop(start_x, start_y, end_x, end_y) => {
                // Moving troops
            }
            ServerMessage::AttackTroop(start_x, start_y, end_x, end_y) => {
                // Attacking troops
            }
            _ => {}
        }
    }

On the server, we have something similar, but with ClientMessage instead.

Conclusion

If you made it this far, thanks again for reading! This devlog was pretty short since there wasn't much to explain. I do plan on finishing this game as soon as possible, but I am very busy at the moment, so progress is very slow. With that, I hope you enjoyed and are somewhat hoping to try out my game in the future. See you next time!

Special thanks to the user who helped me improve my code. Hints on grammar and best practices are always greatly appreciated.

Rust devlog: Part 3

ThousandthStar — Sun, 09 Oct 2022 00:53:09 +0000

Hello Readers! Welcome to the third devlog on this series where I code a multiplayer turn-based strategy game! If you haven't read the three previous posts, go check them out! This week, I created a simple and exciting selecting system for my troops. Without further ado, let's get into it. Hope you enjoy!

Troop selecting

In the last devlog, I talk about how I implemented the spawning mechanism in my game. Essentially, placing some troops on the board. This went very well and is now fully functional. However, we still need to be able to select those troops and move them. This is what it looks like after this week:

Here the skeleton is not clearly distinguishable, so I'll make sure to change some colors for next time.

The code for this was actually quite long, so I'll simply sum it up for you. Essentially, we spawn on every board tile two entities, one for movement interactions and one for attack interactions. These both have their own separate components named MoveInteraction and AttackInteraction. They are always invisible, except when the SelectedCardEntity resource (which is an Option<CardEntity>) contains an entity. When that happens, if they are close enough to that entity, we show them. Pretty simple, right? Well, this took around about 200 lines of code. However, I think the result is definitely worth it.

Meme of the week

Conclusion

In conclusion, this was a very short devlog for this week, and it's a bit late. Normally, I would post on Friday, but I think I'll start doing it on the weekends. I may even only post every other week, since I don't have enough progress to show for after a week.

In addition, the code is now on Github for everyone to see! You can find it at here

Finally, I would like to say thank you if you read this post all the way. This was a short one. Also, since it's currently Hacktober, I would really enjoy getting into open source contributions. If you have a project (ideally Rust) that needs contributions, leave a link in the comments and I'll check it out!

Rust devlog: Part 2

ThousandthStar — Sat, 01 Oct 2022 20:00:13 +0000

Hello readers! This is my progress for week 2 of coding my multiplayer game with Rust and Bevy. This post is a bit late, and should’ve been out yesterday, but I wasn't able to make it in time. Anyways, here is my progress this week. As a reminder, this is only a side project, and I don't work on it for extended periods of time, so progress is slow.

In this post, we will cover three things:

Asset loading: how I load the sprites for my game and access them throughout the code.
Spawning troops: how I send the packets required to place troops on the board, which needs to be slightly different for each client.
Game art progress: my two new sprites for the game.

In this post, I will also show an image of how the game looks at the moment so you can give feedback in the comments, and maybe even come up with a name for the game (it still doesn't have one). Without further ado, let's get into it!

Asset loading

I have decided that all my character sprites will be 8x pixel art tiles. The best way to handle that is to put them all in a sprite sheet and use Bevy's TextureAtlas struct and store it in a resource (Res) for our systems to use. This is done as such in the game/card.rs file:

// game/card.rs

pub(crate) struct CardSprites(
    pub(crate) Handle<TextureAtlas>,
    pub(crate) HashMap<String, usize>,
);

fn load_card_sprites(
    mut commands: Commands,
    asset_server: Res<AssetServer>,
    mut texture_atlases: ResMut<Assets<TextureAtlas>>,
) {
    let sprite_sheet = asset_server.load("sprite_sheet.png");
    let atlas: TextureAtlas = TextureAtlas::from_grid(sprite_sheet, Vec2::splat(8.), 1, 1);

    let atlas_handle = texture_atlases.add(atlas);
    let mut card_sprite_map = HashMap::new();
    card_sprite_map.insert("skeleton".to_string(), 0);

    commands.insert_resource(CardSprites(atlas_handle, card_sprite_map));
}

Here, we load the sprite_sheet.png file, which is in our assets folder. We tell Bevy to parse it as a grid of 8x8 tiles. This gives us a TextureAtlas, from which we store a Handle (sort of reference struct for Bevy) into our CardSprites resource. This resource also contains a map that allows us to get the index of a character's texture with its name. This makes it very simple to add more characters later on. In other systems that need to access these sprites, we can just add Res<CardSprites> to the function arguments. That is very helpful, as we will see later on.

Spawning troops

Now for the interesting part. We can finally start putting some stuff on the game board! To do this, we first have to go into the server side and code a way for it to send spawning packets to the clients.

// net/packets.rs

pub fn spawn_troop(card: &Card, x_pos: i32, y_pos: i32, flip_board: bool) -> Packet {
        let mut json: Value = serde_json::from_str(
            r#"
            {
                "packet-type": "spawn-card"        
            }
        "#,
        )
        .unwrap();
        if let Value::Object(ref mut map) = json {
            let card_entity = CardEntity::new(
                card,
                if flip_board { 4 - x_pos } else { x_pos },
                if flip_board { 8 - y_pos } else { y_pos },
            );
            map.insert(
                "troop".to_string(),
                serde_json::to_value(&card_entity).unwrap(),
            );
        }
        Packet { data: json }
    }
}

This is mostly some simple JSON object creation. However, notice there is an argument called flip_board. If it is set to true, this boolean makes it so we flip the x and y positions of the troop on the board (it's a 5x9 board, that's why there's the 4 and the 8). This is necessary to insure that both clients see their perspective of the game. Here is what the handling of this packet looks like on the client side:

// net/packet_handler.rs

"spawn-card" => {
    if !matches!(packet["troop"].clone(), Value::Null) {
        let result =
            serde_json::from_value::<CardEntity>(packet["troop"].clone());
        if result.is_ok() {
            let card_entity = result.unwrap();
            let mut sprite = TextureAtlasSprite::new(
                card_sprites
                    .1
                    .get(&card_entity.card.get_name())
                    .unwrap()
                    .clone(),
            );
            sprite.custom_size = Some(Vec2::splat(tile_size.0 * 0.8));

            commands
                .spawn_bundle(SpriteSheetBundle {
                    sprite,
                    texture_atlas: card_sprites.0.clone(),
                    transform: Transform::from_xyz(0., 0., 500.),
                    ..Default::default()
                })
                .insert(card_entity);
        }
    }
}

Note: we need to add card_sprites: Res<CardSprites>, to the function arguments so that we can access the sprites we loaded earlier.

Here, we get the troop data from the packet if it exists. This returns a CardEntity (if you don't know what this is, go check out the the week 1 devlog) that we can use to spawn the new troop. Here, it is placed at the (0, 0) coordinates. This is because we have another simple system that takes care of positioning the entities. This is what is looks like if we spawn a skeleton at (0, 0).

Game art progress

This week, I drew two very simple sprites that I'll hopefully using by next week for character interactions. The blue tile is for movement and the red one is for attack.

Meme of the week

It's that time again!

Once again, if you made it this far, thank you so much for reading. Leave your thoughts and suggestions in the comments. As for me, I'm out, and I hope to have some good progress to show for next week!

Rust devlog: Part 1

ThousandthStar — Sat, 24 Sep 2022 02:58:49 +0000

Hello readers! Welcome to the week 1 devlog of my multiplayer game using Rust and the Bevy game engine. In this post, I will talk about my progress for the first week. This isn't the beginning of the project, but rather my first devlog. Without further ado, let's get into it!

Please note that you are more than welcome to comment on my code. Hints on how to make it more efficient, performant, etc. are greatly appreciated.

Packet handling and bug fixes

I have just started the networking between the client and the server, and I already have had to fix two small but impactful and hard to find bugs (one was hiding in plain sight but I was too stupid to see it). But first, we have to take a look at how the networking in managed on both the client and server side. They both make use of threads to read and write to each other via TCP. They also use the std::sync::Mutex class wrapped in a std::sync::Arc to safely manage mutable references to the packet queues (more on them later).

Client-side

Related files:

client/src/net/mod.rs
client/src/net/input.rs
client/src/net/out.rs
client/src/net/packet_handler.rs

Because of how the Bevy engine works, to get our packets to be read by the game, we need to pass them as resources to our App (Bevy uses the ECS architectural pattern). These resources can then be used by the systems that run on every time the game updates. These resources typically are tuple structs, because Bevy needs every different resource to be a different struct. We use a VecDeque object to make a queue for the packets, because it allows us to push data to the end of the queue, and then pop the front of it. Hence, we declare the queues as

// mod.rs
pub(crate) struct QueueIn(pub(crate) Arc<Mutex<VecDeque<String>>>);
pub(crate) struct QueueOut(pub(crate) Arc<Mutex<VecDeque<String>>>);

These create a way for our handle_packets to process and write packets.

// packet_handler.rs
fn handle_packets(
    mut queue_in: ResMut<QueueIn>,
    mut queue_out: ResMut<QueueOut>,
    mut commands: Commands,
    mut state: ResMut<State<GameState>>,
) {
    let mut guard = queue_in.0.lock().unwrap();

    if !guard.is_empty() {
        let packet_to_read = guard.pop_front().unwrap();
        let packet: Value =
            serde_json::from_str::<Value>(packet_to_read.as_str()).unwrap_or(Value::Null);

        if matches!(packet, Value::Object(_)) {

            if let Value::String(string) = packet["packet-type"].clone() {
                match string.as_str() {
                    "server-start-game" => {
                        state.set(GameState::Playing);
                    }
                    "none" => {
                        println!("bad packet from the server!")
                    }
                    &_ => {}
                }
            }
        }
    }
    drop(guard);
}

Here, we get the first packet (which is a String read from the TcpStream) in the queue and deserialize it using the serde_json crate. This parses it into a Value object, which represents JSON data. We then get the "packet-type" field from the JSON object, and if it exists, we use a simple match statement to handle the packet. You can also see that in the declaration of the function (functions represent systems in Bevy) that we tell Bevy to get the QueueIn and QueueOut resources, which is where the packets are located. We also need to drop() the MutexGuard (which gives us control over the queue) at the end of the function to let the rest of the code access it.

To read the packets from the server and to send the packets to it, we have too very basic threads that are spawned in input.rs and out.rs:

//input.rs
pub(crate) fn spawn_input_thread(
    queue_in_ref: Arc<Mutex<VecDeque<String>>>,
    mut reader: BufReader<TcpStream>,
) {
    thread::spawn(move || {
        let mut buffer: [u8; 1024] = [0; 1024];
        let mut received_data: usize;
        loop {
            received_data = reader.read(&mut buffer).unwrap_or(0);
            if received_data > 0 {
                if let Ok(string) = std::str::from_utf8_mut(&mut buffer) {
                    let mut guard = queue_in_ref.lock().unwrap();
                    guard.push_back(string.replace("\0", "").to_string());
                    drop(guard);
                    buffer = [0; 1024];
                } else {
                    println!("Got an invalid UTF-8 packet!")
                }
            } else {
                break;
            }
        }
    });
}

We are using a 1024 character buffer, which should be more than enough for the packets we will receive. One thing to note, and which caused a lot of headaches, is that we need to remove every \0 (whitespace) character. This happens because the buffer is always larger than the packet, which causes it to add unnecessary characters to the end of the String. This causes serde_json to fail to parse the packet.

// out.rs
pub(crate) fn spawn_output_thread(queue_out_ref: Arc<Mutex<VecDeque<String>>>, mut stream: TcpStream){
    thread::spawn(move || {
        loop{
            let mut guard = queue_out_ref.lock().unwrap();
            if guard.is_empty() {drop(guard); continue;}

            if stream.write(guard.pop_front().unwrap().as_bytes()).is_err(){
                panic!("Error Writing to the server!");
            }
            drop(guard);
        }
    });
}

Server-side.

On the server side, we use a similar technique with the packet queues. However, here, they are managed by a Game struct which owns and operates on them (a Game represents a duel between two players). There isn't much to see here, since it's more of a simplified version of the client side, and we don't use Bevy for the server.

Common protocol

I haven't started coding the gameplay yet, but I've established a way to communicate the Card (or Troop, haven't decided on the name) data over the network. On both the client and the server, we have a game module, which contains the file card.rs. In this file, we define the structs that represent our Card data:

// card.rs
#[derive(Serialize, Deserialize, Clone, Debug)]
pub struct Card {
    name: String,
    type_: CardType,
    hp: f32,
    attack: f32,
    cost: i32,
    abilities: Vec<CardAbility>,
}

#[derive(Serialize, Deserialize, Clone, Debug)]
enum CardType {
    TROOP,
    SPELL,
    BUILDING,
}

#[derive(Serialize, Deserialize, Clone, Debug)]
pub struct CardEntity{
    card: Card,
    current_hp: i32,
} 

#[derive(Serialize, Deserialize, Clone, Debug)]
enum CardAbility {
    ProduceGold(i32),
}

As you can see, we have two Card structs and two enums. The Card struct defines the troops' stats, including their abilities, which are defined in the CardAbility enum (more abilities will be added later). This will be useful when we need to code the game logic and check a troop's properties. The CardType struct does not yet serve a specific purpose, but I still included it. Finally, the CardEntity struct represents a troop that is on the game board. It needs an additional hp (health points) property.

That concludes the brief coding progress progress made during this week.

Game art progress

I've finally decided on my color palette, and made this simple 8x skeleton pixel art, which I hope will be in the game at some point. I'm truly a beginner when it comes to art, however.

Meme of the week

It's time for the meme of the week:

Conclusion

If you made it this far, thank you very much for reading. This has been the week #1 of my multiplayer game devlog. I hope to continue this series and post updates every week.

Rust devlog: Intro

ThousandthStar — Sat, 17 Sep 2022 19:23:59 +0000

Hello readers! This is a short post introducing my first blog series, where I will document my process creating a multiplayer turn-based game. The game is not named yet.

Below is what I'll explore in this post:

What I'm making: in this section, I'll tell a bit more about what kind of game I'm making as well as what are my expectations and goals for this project.
Language and tools: I will cover the technology stack behind my game. This includes the programming language and the game engine as well as how the game will work. I will also cover the code editor I'm using.
My schedule: I'll explain briefly what my expectations are regarding post frequency.
The content. I'll detail what my posts will include.

Without any further ado, let's get started!

What I'm making

I'm making a multiplayer turn-based game. The game is inspired by chess, because you will be able to move your troops across the board, but it is more heavily inspired by Clash Mini, a game from Supercell (link to the clash website). With this project, I aim to learn more about game development. I also hope to discover the wonderful (or rather awful) world of networking and all the bugs that will come with it. There is no deadline for the game, as progress is very slow and inconsistent. In the end, I hope to make the code open source, depending on how proud of it I am 😅.

What I'm using

I'm using Rust for this project, along with the Bevy game engine (an amazing open source ECS game engine that you can find here). I am currently coding a server from scratch using, you guessed it, Rust. Currently, there is only one server for all the clients, but this game is more of a proof-of-concept than a game I consider will actually get a player base. However, things are subject to change in the future. To edit code, I use Vim (which I've just started using but already adore) with Rust-Analyzer and coc.nvim, which are a must for Rust development.

My schedule

As mentioned before, progress on the game is very slow, as it is only a side project and is not on my list of priorities. I do plan on making a post per week regarding the game, though this is subject to change. These posts will come during the weekend, but the schedule is subject to change and I may of course miss some weekly posts. This is more of a way to document my game development experience instead of a serious content series. However, I will appreciate any comments and interaction if you, the reader, is interested.

My content

In my weekly posts, I plan to cover my weekly progress on my game, as well as a dive into some of the code. I will also show small sneak peaks in the form of images or videos. Finally, I will try to include a programming related meme that I made in each of my posts. I usually also post these on Reddit here. This is this post's one:

That about wraps up my first ever blog post! Let me know in the comments if you have any suggestions. Anyways, thank you for reading, and I will see you in the next one!

DEV Community: ThousandthStar

Rust devlog: Part 4

Refactoring

Conclusion

Rust devlog: Part 3

Troop selecting

Meme of the week

Conclusion

Rust devlog: Part 2

Asset loading

Spawning troops

Game art progress

Meme of the week

Rust devlog: Part 1

Packet handling and bug fixes

Client-side

Related files:

Server-side.

Common protocol

Game art progress

Meme of the week

Conclusion

Links:

Rust devlog: Intro

Below is what I'll explore in this post:

What I'm making

What I'm using

My schedule

My content