Mudtato
The original and the best
I recently read Masters of Doom, which I found super inspiring. It’s probably the main reason I decided to commit to this project.
Some time ago I read a story written by Andy Gavin that talked about the process of developing the original Crash Bandicoot game. Ars Technica have just released another episode of their War Stories series featuring Andy who discusses and elaborates on the same story. Again, super inspiring.
All these stories about guys wrestling with the hardware and low level code gives me motivation to persevere with learning the ins and outs of something like WebGL. It’s an order of magnitude simpler than what those guys had to deal with!
Besides, I’m not in a hurry, and the satisfaction I’ll feel at the end will be worth it.
Today’s tangent brought to you by not having time to actually work on anything, again…
Too busy
Unfortunately I’ve been too busy today to make any progress on the game. Tragic.
I’ve been thinking about it, though. The design I’ve had in mind for the game world is mostly, well, arid. Dry, desert wasteland. However, this clashes with my goal of motivating players to explore the world. Jogging over dirt and sand can only stay interesting for so long.
I’m not going to go jamming in lush rainforests or enchanted fairy gardens, but I’m at least going to mix it up a bit with some shrubbery.
WebGL
WebGL is pretty great, but there’s quite a bit to learn. I’ve managed to display an image on a canvas, but it’s not where I want it to be, or even the right size… Definitely not as easy has Html Canvas 2D, and I estimate there will be a lot of learning to do before I can get even a simple prototype done with WebGL. There may even be actual mathematics required. Scary.
Meanwhile, PixiJS has all of the things, and it looks great. I’ll at least give it a decent go myself before I chuck in the towel and use something off the shelf. I think it’s in my best interest to understand how it works.
https://webgl2fundamentals.org/ -> That’s my reading material sorted for the next however many days.
Just doing it
I came across Photopea today. It’s a Photoshop clone that runs in the browser, written in javascript by one person. At first glance it’s a seemingly inhuman feat of engineering, but after looking into it it’s really quite simple, and it’s the same story behind most successes - just start creating something, bit by bit, don’t stop, and eventually there’ll be a result equivalent to the effort put in.
I’m sure if the creator of Photopea had said in the beginning “I’m going to build an almost feature complete clone of Photoshop that runs in the browser and is only 1.5mb of javascript” people might have laughed, or at least thought it’d soon become an abandoned project. Well, to the creator’s credit, he saw it through.
It’s this same attitude that I’ll need to bring to this project, Arid. I have a huge vision, and after putting it off for years because of a lack of confidence technically, and not thinking it’s a worthwhile project (I have a love hate relationship with games…), I’m finally committed.
I did a bit more thinking around death in the game. Perhaps if a player dies within a certain proximity of a settlement they’ll be revived at the nearest settlement. Venturing out into the world alone and far from others would therefore carry a big risk and would encourage preparation and forming a party. A player could be revived by a party member in this case - or they could just have their gear stolen and be left for dead.
I also like the idea of certain creatures destroying or consuming a downed player, preventing them from being revived. While I don’t want the game to punish players, I do want it to be brutal in its consequences for venturing into a hostile wasteland unprepared.
The Trap
There’s a classic trap that many people fall into when setting out to create something - doing it all themselves and building it from scratch.
And despite being aware of this trap, and falling into it before, I’m determined to build my own engine for this game.
I’ve been learning about WebGL and have decided it’s the way to go. There is pixi.js, which does look good, but I just prefer the idea that I will understand exactly what’s under the hood if I build my own, and can customise it to work best for the needs of my game.
So there’ll be a lot of work before the actual game part begins, but that’s all part of the process, and I enjoy the process.
In my travels today I played some Surviv.io and Zombs, and it made me realise that I need to put some more thought into my game design. Arid will be an open world game based on exploration, PvP and PvE. With that comes damage and death, and I really need to think hard about how I handle that. In the aforementioned games, death comes quickly and I didn’t feel invested in the game enough to really care.
I’d originally thought about stripping the player of their items and having them start again in the same place as all new players. However, with the size of the world that I want to achieve, and the emphasis on exploration, it could potentially ruin a player’s motivation to start again.
I’ll have to keep thinking about it…
You want a piece of meat, boy?
So I’ve managed to move a little sprite around on a canvas via mouse input. It’s not 100%, but it’s a start.
I’ll tidy it up and then get it working across multiple clients over the network.
However, this isn’t going to scale well, so I’ve been looking at libraries like Phaser for creating the game engine, or just using Pixi.js to manage the graphics side of things and building my own game engine around it. I’ll create a few more prototypes and ultimately settle on whichever works best.
Or, you know, create it all from scratch.