It’s been a while since I published a Rust post, let alone any kind of blog post to be honest.
What I wanted to talk to you all about is my understanding and continuous, never ending learning path of Rust. The language is beautiful and the community is a god send of helpers and kindness that rivals other communities where they laugh you out the door for the stupid and simple questions.
Plainly put: In Rust there are no stupid questions. You just have to be willing to learn and they are willing to teach.
Rust is a language of complexity built on top of simplicity. What do I mean? The compiler will tell you, in plain English, exactly what is wrong and why it will not compile and even show you where you have made mistakes.
This you already know.
You also know that the power of C, the ability to get right down to the metal is the core aspect that attracts a lot of people, well at least it’s what attracted me to the language – but most of all it was the safety net of English compilation errors that were easy enough to solve on my own.
I have been working on my agb (Adventure Game Builder) library which, to most is simple, to me is a complicated “real world library” for learning Rust. As it comes a long further in development I thought I would share some concepts and ideas that have been implemented in it.
Worlds Have Rooms and Rooms Have Stuff
The game builder engine is built mostly for text based games. There is no rendering engine for fancy graphics and there’s no complicated systems in place. The most complicated is probably the world building.
The game you build can consist of multiple worlds or a single world. Each world consists pf rooms that can contain items, monsters and relationships with other rooms.
The interesting aspect is that instead of passing around a reference to a room, I clone it. The room you enter, the current room is a cloned instance of the room in the vector of rooms that makes up the world.
Rooms can contain relationships (up to four) with other rooms. The relationship is defined by name and direction of the exit.
Rooms do not have to have relationships, but if they do it makes it easier to say: “go east” and then you’re in the next room.
Building Worlds Requires Understanding Lifetimes
One of the things that always confuses me and I am sure confuses a lot of Rust developers is the concept of lifetimes and borrowing and who owns what and what owns who.
It can get downright confusing, especially when you don’t understand memory management at a C level.
While I might not have to allocate and deallocate memory in this language, I still have to be careful to understand that everything is immutable and that once its moved, you can’t move it again and the logic process has to be carefully thought out. I mean after all this isn’t PHP or Java.
Stop Thinking In OO
That’s even harder for me to do. I think of structs as classes that contain specific set of data and traits as interfaces that get implemented, generally for a struct.
The most complicated thing I have run into is thinking of things in terms of abstracted objects, I mean it’s been drilled into my head all these years. Abstract objects that can communicate with each other but keep the logic separate and decoupled such that it might be re-used.
Sure, some of those ideas work in Rust, but the full-blown idea of OO does not. That’s hard to get away from.
I will continue to develop and document my concept of this library that I am building and share more of it with you guys.
At the time of this writing I haven’t started a GitHub repository. Even though the library is very far along and I have started using it to build an actual game.
I feel there’s a lot to learn still and I am not the type who likes to learn in the public eye. The eye of judgement and harshness in the OSS community these days seems to be rather ridiculous.
For now I will continue to “develop in secret” while sharing concepts and ideas with you guys.