What do I say?

It’s been a good while since I made a post. Lots has happened, mostly good things. I found a job and as a result, my “extracurricular” activities have taken more of a back seat.

I find myself wanting to come back to publicly writing things down. For what reason, I don’t know. I don’t write code quite as much outside of work, but that’s normal. However, I have been drawing recently and dropping the occasional masterpiece on my pixel art page.

So like the title suggests, what do I say?

I think for now, I’ll say things about my art path and anything else that comes to mind. Well, I’ll try to. I think it’s good to document things you do. It slows time down a little. In a good way. I enjoy looking back at the things I’ve done and it’d be a shame to lose out on that going forward.

As a start, I recently completed the 250 box challenge on Drawabox. What an absolute project that was! I started on the next lesson from there and I can already tell that 250 boxes is in fact just skimming the surface. The texture exercise in particular has reminded me that getting what you see onto paper is incredibly difficult.

Anyway that’s about it. Here’s to hoping I can say some more stuff later!

Low times

It’s been a bit of a tough period since my last post. I had been dealing with some work stuff and thankfully that’s over, but it’s been really difficult to create on my free time.

I started on a small Rust program recently to learn a bit more about how Cargo works. In addition, the tool was supposed to help me with some of my other hobbies. After some days of spending time on it, I noticed that it was increasingly harder to press my fingers on the keyboard and make the code do stuff. I did learn more about Cargo, but I just couldn’t be bothered. I think it’s temporary, but we’ll see. I’m thinking of greatly down-scaling the project to make things easier. I may have also recently ran out of coffee but surely that can’t be related.

Pixel art has been more of a consistent interest for me at least. Even though I am still having a hard time producing stuff there too, it’s at least because it’s novel and I don’t have it figured out yet, and not because I’m just like ugh. It’s hard to explain, but it may be because I regularly code at my normal day job. It’s much more difficult to work on code stuff on my free time when I’m also spending 5 days a week programming at my job.

I don’t really have much of a point to the post. I think sometimes it’s good to reflect on accomplishments when you’re down. I’ve done a lot of stuff the past couple months! That’s neat. We take those. It’s easy to beat yourself up when you want to push yourself at low times, but honestly it’s not worth it. People who do that to themselves end up pushing themselves away from their interests.

I think what helps too is that I don’t plan to make money with what I do or make on my free time. There doesn’t need to be good enough writing, good enough art, good enough whatever. I finish and submit whatever I think is presentable. The void I’m filling with all this stuff I am doing is a creative one. I’ve kinda deprived myself of a creative outlet for long enough, so the fact that I have many of them now is worth its own celebration.

For anyone reading, thanks and stay cool ?

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!

Starting a blog

This is my first post and a test to see how this website framework works. So far it’s been pretty neat with only a few snags here and there. I’ve been working on learning Rust and making games with the Bevy framework. It’s actually been a nice experience and I’m hoping to stick to a 1-game-a-month schedule. March is looking pretty good with a game I’m making that was originally supposed to be about *avoiding* bad guys but I could not resist adding a mechanic to also *destroy* the bad guys.

Currently, the annihilation works a little too efficiently and deletes the bad guys from existence with no trace of their previous existence. I’m working on trying to get an explosion sprite sheet I made to show an explosion occur when an enemy gets killed. Turns out it’s harder than I thought, due to my lack of knowledge in handling game assets in general. For the curious, here is the Github repository.

I’ve also been learning pixel art with Aseprite as a side-effort to at least come up with my own sprites for my games. I don’t expect to be good at it any time soon but that’s okay. It’s another avenue of creation if I don’t feel like coding.

Anyway, that’s all I got for now. This site may undergo lots of changes cosmetically and functionally, but for now it seems to work. Once I have a better workflow, I can hopefully start working on more in-depth and interesting blog posts. And with that, I am going to test out code blocks by writing the following:

fn main () {
    println!("Have an Awesome Day!")
}