Intermission

Alrighty, so a bit late this post was by my standards, but life throws things at you. You know how that goes. That said, I wanted to at least talk about some of the things I have been working on!

The Python Discord Code Jam

Recently, the Python Discord released a qualifier for their latest code jam! I have never taken part in a code jam, so I felt it was the perfect time to amend that. I successfully submitted my qualifier and while I regret to inform that it was not hyper-optimized, it definitely did the job.

I’m excited to see what sorts of ideas my team and I can come up with for the code jam. It’d be neat to place really well in the contest, but since it is my first one I’m really looking for the learning experience.

A super secret Rust project

Yep, that is indeed a thing I am working on. It may or may not involve Bevy and an additional developer. Stay tuned ?

The media posting app

I still intend to try and Dockerize the Django application I have been working on within the past month and change. I only have some experience using Docker, so it’s gonna take a bit longer there. Once I have it in place though, I may have an easier time incorporating it into a Gitlab CI pipeline that I mentioned in my last post.

And that’s about it

Taking up multiple projects has certainly been an interesting experience for me, as I am still also trying to improve myself in other ways that aren’t just coding. There are even more coding-related plans that I have, but I’ll keep those under wraps because it’s harder to start them if I start talking about them.

Short post but we take those. Stay cool friends ?

The avoider game is complete! (enough)

For the anxious and the ravenously impatient, here is a link to the game. For more info, it can also be found in the Games and Experiments part of the website.

Whew! What an absolute experience it was getting this one out the door. I would say great strides were made in early March, with diminishing returns coming in towards the end of march and into April. I had hoped to have this done before my trip in mid-April, but sadly that was not the case. Thankfully I was able to still knock things out after and all is well!

My main goal here was to learn about Rust/Bevy while making something that seemed fun, no matter how basic and unoriginal it may be. I’ve found that waiting on the perfect idea is for people who never act on it, so I just went with my gut when starting production.

For me to consider this small project complete, the game needed to be fully functional with the ability to pause, resume, die, retry, and even win the game. Some of those features were vastly easier than others, but we got there.

Things I learned

While I am glad I finished this, it was definitely starting to get the rot of ignorant technical choices towards the end of development. This is fine. Making mistakes is a fact of life when doing complicated stuff. A lot of this stuff will echo what I have in the readme in the github repo for this game, but will go into a bit more detail.

Listeners and state changes

In Bevy, you can have systems listen for change of state and for events. These are two distinct things.

At the beginning, I thought the change of state was not something you can listen to. So, in some cases, when there was a change in application state I would also include an event that occurred alongside it. This did work, but it was inefficient. Once I figured out that change of application state could be listened to, I did not need to use events for those particular cases.

There is another distinguishing feature that events have however. They can carry data along with them. For example, there’s two ways the game can end. It can end with the player dying, or the win condition of the game being met. Depending on what causes the game to end, that is what the “end” screen will say.

  • If the player loses, the end screen will say something like “you died press these buttons to restart”
  • If the player wins, the end screen will say, and I know this may come as a surprise, it will say “you won”

So functionally, winning and losing is the same. This hits a bit too close to home but we’ll just not think about that for now. The only difference between the two is the string that is presented at the end state. Therefore, we can carry that string alongside the endgame event and just slap whatever we want on the end screen based on what occurred beforehand.

Here are some links for more technical info on events and state-based stuff. The latter is based on Bevy 0.10 which is the latest stable version as of writing.

Asset handling

Early on I wanted to just get my assets into the game without thinking about it too much. It turns out that people include loading screens in games for a reason. A more reasonable approach is to load up the assets by the asset server at the beginning and then pull upon them when the game is running.

What I did instead was pass the asset server into effectively any system that may or may not need to utilize an asset. That’s pretty goofy since passing it around everywhere is not only just a waste of performance if the game were scaled up, but also because it just created code clutter.

The solution to this, like I mentioned earlier, is next time to load the assets at the beginning, then refer to them using a resource.

I actually just don’t know how cargo works

When I read the Rust book, I may or may not have glossed over the cargo system since I figured it would be pretty straightforward. While in many regards it is simple to use when using other people’s libraries it’s a bit more intricate when you’re working with creating your own modules.

I’ve made it a point to learn more about the logic behind setting up my own modules, as this may also help with the architecture of future projects, too.

The biggest problem with this that I had was that I had to basically copy a function a couple of times because I could not get two files to share it. My code comment here kind of explains it some more. Definitely not one of my proudest moments but that’s why I’ll be reviewing how cargo and modules work.

Other things

The github repo readme has more points on things I should consider in the future. However, I think the above things are the things that stuck out to me the most, so I shall leave it at that for now.

And that’s about it

I’m looking forward to future projects. I have reason to believe my next stop will be the rapier physics engine. But first I’ll want to learn more about cargo and modules. ‘Till next time!