Yes to all

radio room

They say one of the best things you can do is say yes to all kinds of plans. I’ve been doing that for the past month recently and my results say… yes you should. For the most part. But definitely not all the time.

To give some context, I spent the past week and change visiting family and doing the things that comes with visiting family. In that time frame, I had two interviews, a Python code jam to work on (with a video I made for the team’s presentation), and my personal projects.

It was absolutely one of the most productive and fun weeks I’ve had in a good while. That being said, it came at the cost of saying no to a few things in the process because I was just so incredibly busy, whether with code or with enjoying family time. That’s when began to I understand the limits of saying yes to everything, and these limits are not necessarily bad.

The way I see it, you’re going to be saying no to plans regardless of the approach you take. If you’re someone who typically says no to new things, you are denying yourself life experience. If you say yes to everything till you’re full, then saying no to things feels bad, but it’s because you’ve been saying yes to everything else. And that’s good.

That all being said, it’s easy to take the approach of saying yes to everything and then realizing it isn’t physically possible to follow up on all the things because of poor planning. Yeah, try not to be That Guy. I was pretty good at not being That Guy but sometimes certain things slipped through, whether through poor planning or other reasons. That’s part of the learning process though. How much can you handle at once? It’s hard to say ’till you try.

One thing that’s hugely important too, is to occasionally take a break from saying yes to everything. Reflect on it. What yeses did you enjoy? Which ones weren’t worth it? That’s where I am now, and that’s also why I have the time now to write this post.

So in return for a late (by my standards) post, you get some wisdom in addition to the reason for the lateness! We call that a win I think.

That’s about it anyhow. Thanks for reading!

Basically a devlog

I said I would do a post once a week and doggonit I’m doing it! I realized yesterday that almost seven days passed since the last post and my first reaction was “wow, how do actual professional writers do it?” Time itself decided it was time to be next week and here I am, at the mercy of it.

Jokes aside, it has been an absolute learning experience with Python and Django. Much like when I was learning Bevy, there was an initial phase of “this is confusing and has so many moving parts; how does any human function while working on this?” and then over time I started to think “Okay I want to do these things, so I just need to change this, and this, and this, oh and I gotta remember that. Why doesn’t this work? Oh yeah duh because of this.”

That’s essentially the sound of growth. Anyway, here are the things I recently accomplished so far with creating a sample media posting app in Python and Django:

  • Basic login/logout system
  • Making posts with images
  • Making comments on posts
  • Deleting your own posts
  • Seeing all listed users
  • Seeing user profiles
  • Editing own user profile

Here are the features I plan to add as well:

  • Following users and see only their posts
  • Making reactions on posts (ideally with ajax)
  • Full email authentication
  • Making things look nicer using bootstrap’s layout system
  • Automated testing

There are some additional nice-to-haves like lazy loading and real-time post updates, but we shall see on those. I ideally want to have those things but it won’t be the end of the world if I decide to move on to a newer project by the time I finish adding the things I definitely want to have.

One thing I want to do as well is construct a local Gitlab CI pipeline for the project. This effectively falls under the very broad category of “Automated Testing” that I listed above. The pipeline would ideally run my automated tests, then deploy to some local web server that I have. I’d be using my assortment of raspberry pis for this endeavor. I also want to use the Django unit testing framework as well as Selenium for product level testing. Therefore, “Automated Testing” will most likely take the most time out of the remaining tasks.

Anyway that’s about it. I hope to have at least have the remaining core features done by next week so that I can talk more about them. Thanks for reading and don’t do anything I wouldn’t do!

Pixel art, its community, and my findings

I never was a huge creative. I made my attempts but it was easy to go back to old habits. Within the past few months I’ve been doing pixel art and it was kind of an accident. I started out with trying to make a game with Rust and Bevy (see Games and Experiments, namely the Avoider Game) and then realized that in addition to programming, pixel art is actually pretty neat.

After just trying to get some basics down for the sake of making something that looked functionable, I started to jump down the rabbit holes and eventually I could only think…

huh.

Now I’ve got a gallery and I can’t stop! This revelation made me realize that I had deprived myself of a creative outlet for quite some time. While I have tried creative endeavors in the past and didn’t care for them as much, I didn’t give myself the opportunity to continue looking. Thankfully, I’ve found a method of expression that wasn’t just typing at people or sending sick Rocket League clips.

Another surprise I’ve run into is that the community is pretty supportive. I’ve done some posting on twitter myself and it’s nice to see people sharing and liking each other’s work. Plus, hang around there long enough and you start to see the same people after a while; it feels like a wholesome little neighborhood of sorts.

I’ve also joined a pixel art discord that has a variety of channels, including one where you can post your work for feedback. In my time spent there, people have been surprisingly helpful as well.

Initially, my subconscious perception of the art community as an outsider seemed like it was a difficult-to-penetrate sphere where only the highly skilled dwell. That could not be further from the truth. People in the community understand the amount of work that goes into something that actually looks good and all the difficulties that you inevitably find along the way. Plus, looking at the work of others helps to inspire yourself. A little bit of support goes a long way when you want your favorite artists will keep making more stuff.

Overall, it’s just nice to be heard. If I make something, really enjoy how it came out, and others feel the same, it’s really validating. Sometimes I’ll make things that I’m not exactly excited about and some people people may still enjoy it nonetheless. Much like in the “real world,” people can still like what you do in spite of, or because of, your blemishes. I’m learning how much better it is to put your ego to the side and just create, instead of being afraid and doing nothing. As long as the process and the rewards after are worth it, That’s what matters. If you share your experiences or creations, there will be like-minded people out there that would like to see what you’re doing, or at the very least, help make it better.

‘Till next time. Make good choices.

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!

Messing around with pixel art

A considerable step up from my last attempt

I’ve been enjoying pixel art more and more these days. It gives me a way to think without having to access the part of my mind that’s usually active when coding. Plus, you can sit down for an hour or two (or more) and usually have a finished product by the end. Is it something I’ll continue doing? Hopefully. I could use more creative outlets.

I decided to pick up Twitter to get more involved with the pixel art community ’cause why not, and I saw things that would make lots of aspiring artists quit on the spot. People make some insane stuff. One artist I’ve particularly enjoyed is Joseph Hyde. Call me basic but I’m a bit of a sucker for the landscapes honestly. Definitely worth checking out.

There’s also a twitter account called Pixel Dailies that posts a topic every day and people can make pixel art based on the topic. I like that they’re pretty open interpretation of the topics and they actually feature (by retweeting) the best works they find. Given my lack of experience, my submissions have been pretty juvenile so far; needless to say none of them have been featured yet. I’ll take my time with it. It turns out other people have been doing this for far longer than I have.

On the topic of my game, I’ve been slacking a bit on it, though it isn’t without any good news; my job does hackathons every quarter so I’ve been putting some work into a neat little side project with Bevy Rust. That’ll be a little extra something I hope to host on the site too. It’ll involve fancy sand.

One thing I know for sure is that in two weeks I’ll be taking a week-long trip to Colorado, speaking of sick landscapes. Knowing that, I want to have my projects in a complete state before I go. I highly suspect that whatever is incomplete when I get back won’t get done. I may try to mess around with pixel art during the trip though since that’s easier to pick up and put down.

Anyhow, that’s about it. ‘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!")
}