The Fire Mage: A Vanilla JS Game Engine
The game engine in action, with the proof-of-concept game "The Fire Mage"
Several months back, I wrote about making a video game engine in vanilla JavaScript (with a Ruby on Rails backend) as part of a coding bootcamp project. Since then, I've deployed a working demo of the engine on Heroku and have been working to clean up the code. But long-term, my goal has been to make this an open source project--and now, I turn to you, my beloved Dev.to community, for help making this happen!
In this post, I want to review some of the work I've done on the codebase, what I think needs to happen to make it properly open-source (especially re: documentation), and seek feedback on other things to cover/include/do as part of the process.
Currently, I'm just focusing on refactoring and documenting the frontend repo.
I'd love to hear your experiences and share resources about making a good open source project, so please contribute in the comments! :)
What I've Been Doing
I finally contributed to an open source project! Special thanks to Brittany Walker for her wonderful project, EmojiScreen, that helped me get my first pull request to an open source repo approved! Read more about the project on her blog here.
I started taking notes on goals, a changelog, and a contribution guide. I know good open source projects must have all three! However, I know I have a lot of work to do editing/cleaning up the notes, as well as finalizing a style for the changelog and contribution guide.
I began refactoring code to follow a container-component-style pattern. Inspired by the file structures from some of my React projects, the first changes I began making to the codebase were to move classes to their own files, and start creating containers to render them--essentially treating them as components! This has gone a long way toward breaking up the extra-long files with classes and helper methods, but has also become difficult to manage the necessary imports. I'd love to get community feedback on this overall strategy, or about designing project file structures generally!
I created a few initial issues for the frontend's GitHub repo. I picked a few of the most glaring issues with the engine right now, and made a few GitHub issues to help steer contributors toward them. However, I could use advice on both choosing which issues to focus on and how to structure GitHub issues to help contributors!
I've deployed a working demo of the engine! I'm gonna keep shamelessly plugging this, so deal with it. (Or just go play it already!) <3
What I'd Like To Accomplish
I want the code to be modular enough to be easily reused to make a new video game. Right now the engine is more-or-less hardcoded with its proof-of-concept game, so breaking the code into smaller, reusable parts is the top priority--and eventually, how to load/run a script to initialize a game scenario.
I want to keep all of the game engine's frontend code entirely in vanilla JavaScript, and write/refactor it according to best practices. This project began as an ascetic quest to dive deep into vanilla JavaScript's DOM manipulation, and though I've learned a lot since then, I'm still just as interested in writing vanilla JS!
I want to refine the interface so that it feels like playing a real-time strategy game like Warcraft II, its main inspiration. This includes making the page/game container's interface more computer-game-like, adding a File and Help menu, displaying more in-game text and art, and eventually adding music and sound effects.
I want to familiarize myself with working communally on an open source project! I know I have a lot to learn, and this wonderful community has proven it's a great place to get a lot of friendly wisdom. <3
What I'd Like Help With Right Now
I need help with the content and structure of the contribution guide, changelog, and GitHub issues! What are some of the best examples and formats for each that you've seen? What do you feel must absolutely be included in each?
I'd like general advice on open-sourcing a project. What things am I not thinking about? What do you wish you had known when creating your first open source project?
I'd like guidance on how to open discussions about high-level goals. One example is the component-container pattern I'm currently refactoring with--how would I go about proposing and getting feedback on it, before committing any changes to the master?
Playtesting! I'd love to get more people playing with (and breaking) the engine. :)
Links to The Fire Mage
- Frontend Repo on GitHub: https://github.com/isalevine/the-fire-mage-frontend
- Frontend Demo on Heroku: https://the-fire-mage.herokuapp.com/
- Frontend Readme: https://github.com/isalevine/the-fire-mage-frontend/blob/master/README.md
- Frontend Refactoring Notes/Goals: https://github.com/isalevine/the-fire-mage-frontend/blob/master/REFACTOR_NOTES.md
- Frontend Changelog (draft): https://github.com/isalevine/the-fire-mage-frontend/blob/master/CHANGELOG.md
- Frontend Contribution Guide (draft): https://github.com/isalevine/the-fire-mage-frontend/blob/master/CONTRIBUTION_GUIDE.md
- Backend Repo on GitHub: https://github.com/isalevine/the-fire-mage-backend
Thanks Dev.to community! <3
Oldest comments (11)
I was building my own open-source video game a few years ago. Feels like yesterday. Work and babies took hold so I have yet to return to its completion.
github.com/omenking/swap-n-pop
I think open-source works when you think "how am I going to build a team who wants to work on this?" Instead of "how do I choose the right technology".
When I built mine it was originally Coffeescript designed to run in the web-browser backed by Rails and then morphed into Typescript with Electron backed by Phoenix (Elixir). I would suggest not to set hard rules.
What helped was having a Discord and doing outreach to social communities about my progress. In short-time I had a team of 7 doing various things where they could to build the game.
It was important to set milestones and then reach those goals and ship them, to create a pattern of trust that the project is going to meet its end goal. If I had no updates for a week people thought the project was dead, over and over again.
If you're building a game with an online component you'll need to ensure the game is deterministic. Anyone who has made any headway with online games knows this truth, and so until you've done so you may have poor quality contributors.
Test code is another large importance. It helps people from stepping on other people's toes.
Documenting how to get the game working end-to-end is the most important.
Thank you so much for sharing your experience! It’s a lot of good stuff to digest—I’m sure I’ll keep coming back to this and bugging you again and again… ;)
First question: any recommendations for testing in a vanilla JavaScript frontend? A little poking around indicates that using Jest is the most painless route, but…I like a challenge? Is purely-vanilla-JS testing (at my level) even possible?
Also: for getting the game going end-to-end in different environments, is that something I can easily mock on a single computer with some virtual machines? (The last time I used a virtual machine was trying to get my Windows games onto my first Linux laptop…)
Thanks again Andrew!! :)
Here's a few thoughts in no particular order :
Try not to do everything at once. The heart of development is continuous refining. There is no bad ways of doing, some are just better than others.
Copy from the big projects. There are so much large scale project on github that nail things right or set the standards.
Don't sweat it. Your few first projects aren't going to be perfect. You learn most from failure, so fail faster.
Keep coding. No matter what other will say (including me), keep doing what you love. Being right by being the same as everyone else is boring.
Thank you very much for your thoughts, Guillaume! I definitely love the fail faster mentality—it was something I used to try to teach my middle school students. Good to be reminded of it now. :)
I’m curious, are there any big projects you think I should look at?
You should check Webpack. It's the biggest, well maintain project I can think of.
I'm not an expert at coding but I really want to be good at a Vanilla JavaScript. Also I used to love Warcraft II, StarCraft, rts games. I'll look for how I can contribute. This may also be a good engine for the tower defense game I've always wanted to make.
I appreciate that Brian, and I’m glad you enjoyed those games too!! As I clean up the code, I definitely invite feedback on how to make the vanilla JS more readable and usable…and also well-documented, lol.
A tower defense game would be an AWESOME direction to take this—I’d love to contribute to that expansion. :)
This might be a good fit for the #devjournal tag.
Thanks Jason, took your advice and added it!
ISA! You're absolutely killing it, and this is an amazing step!
I don't have too much to contribute at this time, but you know I'll be following the project.
What I'd add is if you're developing your contributing guidelines, consider adding in a code of conduct as well. Only thing is if you add a code of conduct, have a plan for enforcement as well. Not sure if this template would be applicable, but it's one I've used in the past to develop a CoC for events geekfeminism.wikia.org/wiki/Commun...
Awww thank you Aspen!! Good call on the code of conduct, and that’s a great recommendation.
Does enforcement involve calling you in to send stern emails on my behalf? :P