I decided to take a break from my usual programming and wandered the internet, I tried breaking away from any programming related videos. I was looking for something light, I don’t know maybe a web dev conference.
This post is based off a youtube video I stumbled on, it’s entitled “The Early Days of Id Software – John Romero @ WeAreDevelopers Conference 2017“. You know, I didn’t know who John Romero was and I played both DOOM and QUAKE back in the early 90s. John was rockin’ the long hair, it was super long, looked super cool though. I wish they would invite more people like John over to Web Dev Conferences.
I was a good couple minutes in and it was refreshing to hear some good old school programming and software development. So I was in for a ride, perhaps it was the nostalgia, no it was definitely the nostalgia. I mean it’s about this guy named John Romero and he puts together a team of gifted programmers and they build something amazing. That’s just awesome.
John, in the video provides a list of software principles as he tells his story. These were way too good not to grab for my own use so here it is:
Software Principles
1. No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code. (Large teams require more planning though.)
2. It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults (for input data) upon load failure.
3. Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.
4. Great tools help make great games. Spend as much time on tools as possible.
5. We are our own best testing team and should never allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly before checking in your code.
6. As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.
7. Use a development system that is superior to your target.
8. Write your code for this game only – not for a future game. You’re going to be writing new code later because you’ll be smarter.
9. Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.
10. Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task and get feedback and advice. Do not treat game programming like each coder is a black box. The project could go off the rails and cause delays.
11. Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.
Extra advice:
1. Only program for a few minutes and test code immediately. Try not to code for even as long as 30 minutes. This is will help to avoid debugging because you will catch bugs sooner, and won’t have as wide an area of code to look through for the bug.
Is that timeless software wisdom or what? Yeah, this is a super short post – just wanted to mix up my topics a bit more. Stay tuned for more Javascript.