How do I structure a web project i'd like to create?

Hi, I'm new to Rust but have been coding for a couple of years now.

I love how much I'm learning and have given myself a year to complete a project.

Essentially I'd like to create a website where my friends can log on and play a game with me that I create. The game will be super SUPER simple visually (think board game board made in ms paint simple).

the objective would be to code it all in Rust (as much as possible). for players to log on create a profile and play with me.

I know this won't be easy, especially with the networking with other players. But I figure a year of work will get me quite far and I'd learn so much even if I didn't quite get there.

I'm thinking of using Axum to create the site and Macroquad to make the game, but tbh I've only ever coded scripts in Python really and those were all to help with work (excel, scraping etc) and I've never created something like this before so I wouldn't know where to start! Which Is cool but also makes it hard for me to plan this out.

what components would a project like this need to work? How would I structure it and what things would I need to learn how to build to launch something like this?

Basically, I'm not asking how to code everything I'm asking what parts would I need to build so that I can start to plan what I need to learn and how it all fits together.

Thank you so much if you've stayed long enough to read my ramblings. any help and any book recommendations would be also be appreciated (I'm currently working my way through "the Book" and have "hands-on rust" to complete afterward as well.

Thanks again it's nice to finally write something here and not just read!

Cheers,

Chris

Disclaimer: I am an independent game developer and studio owner making games in Rust. My opinions below are informed by 2 decades in indie game dev and web-based SaaS experience. They are my own opinions and not necessarily a reflection of the state of the art on the subject matter.


Axum is a very appealing HTTP server, and seems like a good choice to start with. It's kinda sorta "NodeJS Express-flavored" or "Python Flask-flavored", which a lot of devs will appreciate.

For the game, bevy is a good option. It contains a lot of foundational tools that you will want as a game dev. But even with smaller projects, it doesn't really have everything you will need out of the box. For instance, the collision detection included in the base crate set is rudimentary. Many will likely try using a 2D physics engine, but it really only makes sense to use a physics engine for physical interactions. (The kinds of things you see in a physics sandbox where objects collide and interact in a chaotic but realistic manner!) For what is essentially a digital board game, you might be perfectly served by the simple built-in sprite collision.

Macroquad does a lot for the I/O aspect of a game (video, audio, input) but almost all of the pieces of a functional "game engine" are either marked experimental or are entirely missing. Even something as basic as a state machine to manage various states of gameplay (e.g. scene management):

                            +-----------------------------------+
                            |                                   |
                            V                                   |
[Loading] --> [Intro] --> [Title screen] --> [Start game] --> [End game]
                             ^     ^            ^   |      
                             |     |            |   +--> [Pause game]
                             |     |            |           |   ^
                             |     +------------+-----------+   |
                             |                                  V
                             +--> [Options Menu]         [In-game options]
                                      ^
                                      |
                                      +--> [Display Submenu]
                                      |
                                      +--> [Audio Submenu]

And transitions between them (cross fades and so on). This diagram is simplified. There are probably a lot of other states to consider, like a character select screen, maybe a login screen for associating an account ID or whatever you will be using for storing game state in your database (even if it's just a high-score table).

As well as the aforementioned collision detection there are animation state machines, tile map loading, sprite atlases, and dozens of utilities like pathfinding, ray casting, tweens aka easings, particle emitters, etc. etc. The list is practically endless. But these are things that you may want to use at some point. Even still, plenty of games have been made with macroquad.

For multiplayer, there is still a lot of ongoing research to deal with synchronization issues and cheating. For the former, a protocol-based solution like rollback networking could do the trick. ggrs and backroll fall into this category. For the latter, good old central authority servers are still the most common solution, but peer-to-peer models also exist (cf. RACS and Cheat-Proof Playout for Centralized and Distributed Online Games). The benefit of a peer-to-peer model is that you don't have to run a copy of the game on a server in a headless mode to compare against what the players say they are doing.

I think I've given a decent number of items that you would need to learn for making a game. But for a web service you will have a lot of other considerations. What does your database look like? Is the app a "SPA" or just a single HTML document with the game embedded in it and "no-frills", or is it somewhere in between? What does your web stack look like; is it all Rust and WASM (maybe yew?) or is built on React or Angular or Vue? Are you going to manage the servers in Digital Ocean, or AWS, or GCE? Maybe you want some redundancy, and you want to think about Kubernetes or at least Docker Swarm?

Or, to paraphrase Richard Feynman:

Nearly everything is really interesting if you go into it deeply enough.


And now for some real advice. For your first project, do something REALLY small. Throw out the online multiplayer. Throw out the web app and all of its infrastructure. Focus on creating a little game in 1 month. Not a year. Just a month. Learn how to make a game. Once you've done that, then learn how to make a web app in 1 month. Something simple again, but still relevant to your actual goal; it has a login page, it has a database where users can edit their profile and view other profiles. Stuff like that. Learn how to manage servers and define database schemas and create-and-restore backups!

Then make a new game with some multiplayer functionality. It doesn't need a web app at this stage. Just get something working where you can connect to a hosting player's server and interact in the game. 1 month. Maybe 2. :slight_smile: If you are lucky, the design of your first game might be salvageable to add multiplayer to it. But in all likelihood, it won't be a good fit because you just learned how to make your first game. You will have made all kinds of mistakes, and some of those mistakes will still be there, baked in. Start fresh for the multiplayer game. Apply what you learned in the first one and make new mistakes!

Finally, after you have taught yourself all of the necessary pieces in isolation, put it all together and spend the rest of the year making your web app, service, and multiplayer game. Again, your first three projects probably will not be reusable for the whole thing. You'll be better off rewriting it and using what you learned from the initial experiments.

3 Likes

Mate,

Thank you so much for your long reply, and please accept my apologies for the lateness of my reply I've been out of home for work these past few days. This has helped me so much and I really appreciate the time you took to write this.

I'm hoping with how simple this game will be I should be able to get away with some jagged multiplayer however I fully intend to do exactly as you suggested and work on a few smaller projects before I take on this beast where I attempt to connect it all together. Like you said, code a simple game, code a super simple site/web app and maybe code a super simple chat app.

The terms you've used like "scene management" have helped me and the resources you've shared like RACS are awesome. you've properly energised me.

Thanks again I'll be asking many questions on this forum in the future I know so I'm sure we'll cross paths again! In the meantime, if you ever find yourself in London, I owe you a pint or coffee.

Cheers,

Chris

1 Like

No problem! There was about a year where I made one new game every single month in my spare time just to practice and to learn new things about game design and game programming. My favorites are still the shorter game jams (24 to 72 hours) which tends to focus your creativity and prevents a project scope from growing out of control. And I've had the opposite experience where I could not possibly complete a game on a realistic timescale because its scope was too big for one developer. I have had to can more than a few projects for that reason!

Absolutely! I'll be interested in hearing and seeing more as you make progress. And if I see any other questions you might have, I'll give it my best to answer.

1 Like