game dev – MNDevs.com

Below is an email interview I conducted with Erik Onarheim. Erik and others are working on an open source game engine named Excalibur.js.

1. Can you tell us a little bit of your background as a developer? When did you start? What was your first language? What is your current language of a choice?

I wrote my first programs in middle school in a BASIC dialect on the TI-81 graphing calculator. The one I remember most was drawing the Sierpiński triangle using a random plot method. I also taught myself some basic JavaScript with “view source”, copying scripts, and experimenting.

TypeScript (and JavaScript by extension 😉) has been my current language of choice for a few years. I find the type system to be wonderful and perfectly suited to wrangle the web. Today, almost anything can be done using JavaScript! The web is ubiquitous.

2. Where do you currently work and what is your position?

I’m a senior software developer at Renaissance Learning in Minneapolis; we build educational software that helps kids learn to read. I do a little bit of everything from front-end to server-side, databases, and DevOps. I spend a good amount of time mentoring and reviewing code.

3. Can you tell us about your current open source project, Excalibur.js?

Excalibur is an open source 2D game engine for the web. Our goal is to make it easy for people to make games. We want to make building a game approachable to both the new hobbyist and the professional developer.

Excalibur uses a film/theater metaphor: Actors, move around the screen and perform actions. Scenes are the stages (or levels) for actors to do things within. Last but not least, Cameras are used to view the action.

4. What made you want to begin developing your own game engine? Was the engine the result of building a game or the end objective from the beginning?

I’ve been interested in making video games since I started playing the original Nintendo, which was definitely a contributing factor to my software career and game dev hobby.

Excalibur started as a work presentation advocating for TypeScript. The presentation was meant to showcase the possibilities of TypeScript, so I built a small platformer to demonstrate. I figured that other folks could probably use what I had made, and Excalibur was born! That said, building a game engine is one of those classic developer traps; it’s easy to get stuck working on the engine and never actually make a game. I try to build small games on a regular basis with the team. Ludum Dare (http://ldjam.com/) has been a great way to do that!

5. What were the factors that led you to selecting Typescript for the project?

With HTML5 and the new canvas API around 2012, the web felt like the best platform to build games for the future, before that I was experimenting with a Java prototype of a game engine with a work friend. After working on some complex JavaScript apps for my job, TypeScript felt like a natural fit to get the best of the web and static types (like Java).

In that time, I was in the middle of a large mobile project written in JavaScript using Cordova and we were feeling the pain of a large JavaScript app. At the same time TypeScript 0.8.0 had just been released and I was very excited about the prospect of strongly-typed JavaScript for Excalibur.

6. What led you to the decision of open sourcing your project?

At the time most available game engines were commercial closed-source products. I wanted to build something that others could use to build games for free. The story has certainly changed in the last few years. Many game engines are now open source (or at least source open), and it’s a lot easier for hobbyists to gain access for free or low-cost.

7. Compared to your position as a Senior Software Engineer, how does being the lead contributor of an open source project differ from being the lead of a work project?

In many ways it’s similar: mentoring, designing, testing, and the imposter syndrome. I feel like being a maintainer has helped me in my career. Being part of a team, designing, planning, testing, working through conflict, shipping and supporting code. I think the best thing being a maintainer has taught me is patience and kindness are paramount when leading a team or a project.

Sometimes I catch myself thinking “what do I know about making video games or running a project or programming?” but then I look back at what I’ve accomplished with the team, the things I’ve built with them, and the things that I’ve learned. That realization helps. I recommend this post if anyone ever feels like a phony.

8. Do you have any clear idea of how many people have used Excalibur as the engine for their game?

If we base our estimate on GitHub stars, we’ve had hundreds of people try out the engine or at least take a serious look at it. We’ve had several people reach out to us directly over the years, mostly hobbyists like us. We had someone recently port one of their old Flash games to Excalibur, which was awesome!

9. How many people have contributed to the project? What is your process for accepting other’s code?

Around 45+ people have contributed with code and more than that have contributed by opening issues or fixing documentation. We are always looking for folks to help and contribute however they can, and we welcome any feedback on things that could be different or better!

Generally we encourage people to open an issue, get consensus on a course of action, write code, and finally open a PR for review and possible merge. We try to be the most inviting and friendly project out there, all are welcome. We have all of the specifics in our contributing document https://github.com/excaliburjs/Excalibur/blob/master/.github/CONTRIBUTING.md

10. How does Exaclibur.js compare to other HTML5 game engines? What are the pros and cons of it compared to Pixi, Phaser or any of the others?

Excalibur shares a lot of the same basic features as Phaser, melonjs, impactjs, playcanvas, easeljs, and others. Excalibur is written directly in TypeScript, but many others include TypeScript support including Phaser. The biggest pro for Excalibur in my mind is our focus on keeping things simple and TypeScript focused. The biggest area that we can improve is the developer onboarding and documentation experience. Excalibur has some okay docs, but Phaser definitely has a wealth of docs and community out there. Others, like Pixi and Three.js, are focused on visual rendering and are more low-level APIs for interacting with 2D or 3D canvases.

Excalibur focuses on 2D game development and building games in TypeScript that are easy to read, understand, and program. Excalibur has been a labor of love by a small team and it caters to the way that we want to build games. Most of us aren’t full-time game devs and so we’re learning as we go, which is why we tend to focus on trying to keep the API intuitive and not make assumptions about what our users may or may not know.

If you want to pick a game engine for the web, please try Excalibur, but don’t take my word for it, try other engines and libraries and see which of them makes you happy!

11. Throughout the project what were the hardest technical problems that you ended up solving? Were there any that you didn’t solve and in what way was the design of the engine impacted by that?

The most challenging thing we built was the physics system for collision. We spent a lot of time tweaking to make it useful and helpful. We built in a tree based spatial partitioning system, which is a fancy way of only checking for collisions if objects are close to each other making it very efficient.

We spend a lot of time thinking about and iterating on the APIs as we build games ourselves, which is why we haven’t reacted 1.0 yet. We’re trying to find the pain points. It might sound odd but the fact that much of the core team only has time to commit to one or two game jams a year means that we come across APIs we developed that we’ve forgotten how to use. API design is hard, and we often don’t get it right on the first try. It’s useful to see the engine with fresh eyes, and to get feedback from others on the team and the community to make Excalibur the best it can possibly be.

The next technical hurdle this year is to be happy with the APIs and the performance of the engine and have a release candidate for 1.0. Some of the hardest decisions will be identifying APIs to change significantly or drop all together.

12. As an engineer what are you most proud of in your Excalibur.js?

I’m very proud that we’ve continued the project for so long (8+ years) and built several games with it. I’m also especially proud of what we have been working on this year, a brand new graphics API, WebGL based rendering that will increase draw performance significantly, and the Entity-Component-System (https://en.wikipedia.org/wiki/Entity_component_system) support for more maintainable (and extensible) game code.

13. Would you say that being in Minnesota has helped or hindered your career in technology? How so?

I wouldn’t have the career I have without being in Minnesota. With the cold outside and my homebody tendencies, it meant I spent a lot of time indoors with the computer tinkering and programming. This is really when I really became passionate about computers and set me off down this path.

I was lucky and privileged enough to go to the University of Minnesota for computer science. Which by some lists, it is in the top 100 schools in the states for computer science (take that statement with a grain of salt). I got a great start, learned a ton, and met some great life-long friends. After university, I joined General Mills as a full-time developer after an internship, which was a great first job. It seems getting that first job/internship is the hardest part, and there are so many great places to start working in tech in Minnesota.

Additionally, there are so many good opportunities here to grow, it’s not just a fly-over state! We have so many local meet-ups and conferences, like Twin Cities Code Camp was where I gave my first talk about making HTML5 games. There is also MDC, NDC, MidwestJS, Open Source North, IGDA Twin Cities, and more. Folks should definitely check some of these out. Also, I recommend giving a conference talk a try at least once!

14. Where can everyone find more information about you and your project?

Thanks for interviewing me! You can find me on Twitter (@ErikOnarheim) and at https://erikonarheim.com, and on github. And more about Excalibur on Twitter (@excaliburjs) for news and releases. If you are new to development or experienced we do our best to be as friendly and inviting as possible.

Check out our website https://excaliburjs.com, it comes complete with samples (https://excaliburjs.com/samples) and a gallery (https://excaliburjs.com/gallery/) of some of the jam games we’ve made. We also have a Google Group for any questions https://groups.google.com/forum/#!forum/excaliburjs

Below is an email interview I conducted with Zachary Johnson. Please follow him and his company at the information below, and be sure to check out his game Joggernauts. Available now!

Can you tell us a little bit of your background as a developer? When did you start? What was your first language? What is your current language of a choice?

I’ve been a developer since I was a teenager. I used to make games in QBasic, and then I taught myself web development. Uncompiled, plain text scripts in languages like Batch Shell, QBasic, and JavaScript meant I could learn a lot from other people’s code.

Today I’m generally either doing application and UI dev in JavaScript or game dev in C#.

For those who don’t know what Joggernauts is, can you provide a description of the game and its unique qualities?

Joggernauts is a side scrolling game (like Mario) where one to four players – alien athletes that can’t stop running – must use a shared teleportation ability to solve color coded puzzles. It’s available for PC/Mac and Nintendo Switch. I’ve been told it ruins friendships. Just kidding. Maybe.

Where did the idea for Joggernauts come from?

Joggernauts has a very specific origin! I was playing the game BIT.Trip Runner with my friend Jesse. It’s a single player rhythm game, and we were taking turns trying to beat the levels. Joggernauts was the answer to the question of, “How could we both play this game together, multiplayer?” The idea for Joggernauts was that a team of players could run together in a line. The teleportation, switch-to-front, ability that players must use in Joggernauts was a way to make sure that nobody got bored running in the back.

From there, the idea for Joggernauts became about making a game that anybody could play with friends. It can be hard to have fun playing some multiplayer games with friends because of different player ability or experience levels. If you always lose, and your friend always wins, that can get old. We wanted to solve some of those problems with Joggernauts and make a truly cooperative party game.

When you set out to build the game, did you imagine the finished product to be a fun side project, or did you always know that you wanted to release a fully realized and highly polished game?

I did think it was an idea that could turn into a commercial product, but I think every new game idea needs to be proven out. There’s plenty of game ideas I’ve abandoned. Joggernauts started as a very rough demo with free placeholder art. I play tested it with folks from the Twin Cities game development community. I had never, ever had a response to any of my previous games like I did from demoing Joggernauts. Ultimately, it was the overwhelming positively response from people who actually try Joggernauts that kept me going through the finish line.

How many people worked on the game? What parts did each person work on?

Joggernauts was developed by the three owners of Space Mace. I was the programmer. Tommy Sunders (@supertommy64) was the artist. Robert Frost III (@heyfrostiiie) did sound and music. Tommy and I co-designed the game. In the last months of the project, we had help from some local contractors. Krista McCullough (@knm_xyz) helped with code and art production. Martin Grider (@livingtech) helped with code. Jason Pfitzer (@JasonPfitzer) helped with animation and art production. We also partnered with publisher Graffiti Games, their producer at the time Dave Proctor (@blankdave), and the QA team at Plastic Fern Studios.

What technologies were used to build the game? IE, IDE’s, languages, design tools, etc.

The game was prototyped, designed, tested, and pitched largely in the JavaScript game engine called Impact. Once we set a release date and platforms, we switched to Unity and C#. I use Visual Studio Code. Tommy uses Adobe Illustrator, PhotoShop, and After Effects. Robert used the FMOD middleware for game audio, but you’d have to ask him about his sound design and music composition tools. We used Git for version control.

How long from start to finish, did it take to complete the game? Was everyone working on it part time or full time?

We were a team of three very part-time people for the first three-ish years of design and development. At the end of that period we had secured our platforms and a publishing partner, and the three of us went full-time for the last 9 months of development. It was over four years from start to finish.

What tools did you use to manage your tasks and stay up to date with what everyone was working on?

We primarily used Slack for communication and Google Drive Docs and Sheets for documentation, design, and task management. We used DropBox for asset sharing. We tried Trello but bounced off of it. We used Monday.com to greatly help us with our first full production schedule.

One thing I’ve always found true for video games is prototyping is often the most important design tool, because it’s very hard to determine if something will be fun until you play it. Do you agree? How often do you prototype out game mechanics?

I always prototype and playtest my game ideas! I really like to see how other people engage with a prototype. I even started a regular public playtesting event during the development of Joggernauts so we could do it more often. Tommy actually joined the project because he liked the demo so much. We hadn’t worked together before Joggernauts. We asked Robert to join us because of the great work he had done on a different game prototype that Tommy had worked on. So prototyping and play testing isn’t just a way to design a better game, but it is also a way to build a team.

How much development time did it take to get to the simplest, playable version of your original concept? When you played that version for the first time, was the fun level what you were hoping for?

It took about a month to build a prototype I was willing to show to somebody else. I was very pleased with the response, as you have probably already read!

Throughout the project what were the hardest technical problems that you ended up solving? Were there any that you didn’t solve and in what way was the game impacted by that?

Joggernauts is not a technically complex game, however it’s design is very complex. There’s a tremendous amount of small tweaks and big evolutions that the game underwent from years of intensive public playtesting and solicitation of feedback from peers. Even then, I don’t think we totally cracked the difficulty curve.

How was the development process different when preparing to launch on Steam vs Switch?

We’d been building for console from the beginning, so the Unity port to Switch was painless. Steam was maybe more difficult because we had to support graphics settings and keyboards. It’s way easier to patch and release updates on Steam. Also, Nintendo did their own QA process on our game, so we had to allow enough time before our release date to pass that.

Do you feel there is a higher level of prestige within the developer/gamer community from releasing on the Switch because it is a Nintendo console?

I think any console release comes with a degree of prestige. It was also certainly a dream of all of us to make a game for Nintendo. I got a Nintendo Seal of Quality tattoo after our launch!

How much time as a developer do you need to devote to maintaining the game now that it is live and published? Do distributor changes require that you update things periodically?

Our game was still a full-time job for at least a few months after launch. There are bug fixes, patches from player feedback, and ports to other languages and platforms. After that though, it’s totally up to you whether more content updates make sense for your game. There aren’t any update requirements from game platforms, with the exception of maybe Apple OS X where code signing recently became a bigger issue.

Where can everyone find more information about you, your game and your company?

Thanks for interviewing me! Find me on Twitter (@zacharyjohnson) and find Space Mace on Twitter (@SpaceMaceGames), or visit our website: https://spacemacegames.com