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
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.