Older blog entries for superuser (starting at number 52)

Lessons from id Software co-founder John Romero

From John Romero’s GDC ’16 talk.

No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code.

It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.

Keep your code absolutely simple. Keep looking at your functions and figure out how you simplify further.

Great tools help make great games. Spend as much time on tools as possible.

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.

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 code base and ensure an unstable foundation.

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.

Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.

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

Programming is a creative art form based in logic. Every programmer is different and will code differently. It’s the output that matters.

Syndicated 2017-02-26 01:34:47 from JasonLotito

Devember 2016 – Day 10 and 11 – Router Builder Start

More cleanup today, but more importantly, started working on the Router Builder. This is the magic part of it all. The part that makes it possible to create routers and merge together commands without actually having to write any code. So it’s getting close to be even more fun.

Happy to say as well that the build stuff I built up yesterday on Devember 10 worked on my Windows machine without issue. So I can successfully run this on both my Windows and Mac without issue. So that’s a plus.

Note: spending an hour working on this might not seem like much, but what I’m able to accomplish is still encouraging.

• GitHub Commit for Day 10
• GitHub Commit for Day 11

Syndicated 2016-12-11 23:23:42 from JasonLotito

Devember 2016 – Day 8 and 9 – Chrome Caches AJAX Response

I didn’t blog yesterday here, but I did tweet, and I did write code.  It was late, but I still got stuff done.

Today was an interesting day.  I’m still coding, but I came across an interesting bug I’d like to share.

So, in the code I have now, depending on the request’s Accept header, it will return either HTML or JSON.  It’s the same endpoint, but depending on the request made, it will return different results.  The result is the same information, just presented differently.  One way for humans, another for computers.

Now, in Firefox and Safari, this works just fine.  If you go to the page, everything loads up as you’d expect.  If you go back in the browser, and then go forward again, the page that is displayed is the same page you’d expect to see.  The HTML result.

But in Chrome, it doesn’t work like this.  Here is what happens in my case.

First, you make a request to a page /foo/bar.  This request has a header entry:

Accept: text/html

The page loads an HTML page which has JavaScript.  This JavaScript makes a request to the same page /foo/bar, except this time, the Accept header is different.

Accept: application/json

In this case, it’s the same URL, but different requests.  This second request returns JSON as expected.

Now, you click the Back button, and go back a page.  Then you click the Forward button, and instead of seeing the HTML page as you’d expect, you see the JSON result.

Now, even though Chrome has this bug, you can work around it.  When you return the JSON response, you can just send back a response that includes the following headers.

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: Thu, 18 Nov 1971 01:00:00 GMT

This will prevent the AJAX response from being cached, meaning the last cached item will be the HTML page.

How else can you use this?

So, in thinking about this, I was wondering how else I could use this.  After all, if I make a request to the same URL behind the scene and cache it, I can change what’s cached in the browser.  Is there ever a case where you’d want to change what was cached without showing the user right away? I don’t know.  But it’s interesting.  And it would only work on Chrome.

Syndicated 2016-12-09 23:24:09 from JasonLotito

Devember 2016 – Day 7

Busy night, I had to help on call people in the middle of my coding, so
it delayed things. Still, I put in my hour. Later than I wanted, but
here it is. Started adding Router stuff. Learning about React in the
process. Yay!

Day 7 is here on GitHub.

Syndicated 2016-12-08 05:51:27 from JasonLotito

Devember 2016 – Day 6

So, adding in react after the fact was a pain. But it’s mostly working.
I still need to fix actually clicking on the links, but the basics of
React is up and running. Still a lot more work to be done, but still
making progress.

Syndicated 2016-12-07 05:08:35 from JasonLotito

Devember 2016 – Day 5

Another day has gone by.  Another video.  And more code. I learned that the recordings are difficult or impossible to see on screens smaller than an ultrawide, so this means they are mostly useless.  I need to come up with a solution to that if I mean to keep streaming.

From my commit:

So, didn't really think about it before, but decided to add
configuration injection into our commands.  This seems to have worked
out well and I'm happy with the results.  The command defines the
configuration and where it expects it, and the application provides the
external configuration in the appropriate location and it automatically
gets injected.

We also now can display route details.  This still needs more work, but
we are doing well and progressing.

Syndicated 2016-12-06 04:52:29 from JasonLotito

Devember 2016 – Day 4

Day four is done. Got the UI up today, though it’s very basic.  Decided that the API builder should, obviously, not worry about HTML output.  It should be focused on outputting results as if it’s an API, not acting as a template.  That being said, nothing prevents that from happening.  HTTP is, effectively, and API.  But the focus is on data in a format like JSON.

I streamed it once again so you can follow along with the thought process.

I think tomorrow I’ll continue with the UI, building out a system that allows you to compose commands together.

Syndicated 2016-12-05 01:03:42 from JasonLotito

Devember 2016 – Day 3

Day three is done. Not much done today.  Cleanup and work on the output functionality.  I streamed it once again so you can follow along with the thought process.

Added a TODO.md file, which I think is handy in terms of keeping track of my thoughts, on what has been done, and what needs to be done.  I think tomorrow I’m going to work a bit on a UI that is built using this system.  Still not sure of a name.  Still, three days down.  Let’s keep it going.

Syndicated 2016-12-03 22:53:56 from JasonLotito

Devember 2016 – Day 2

Day two is complete. Continued work on the stuff I was doing yesterday.  Streamed it live to no one. That’s fine.  Overall, I’m happy with the progress I’ve made tonight.  Handled outputs, both from defining the API along with the context of the request.

I think tomorrow I might want to tackle parallel commands.  So, if I wanted to fetch multiple pieces of data at once, I could do that.  Maybe I can do something more real tomorrow, such as have something that requests someones Twitter and GitHub feed at the same time.  I could do that.

Syndicated 2016-12-03 04:10:05 from JasonLotito

Devember 2016 – Day 1

Day one is complete. I’m working on something completely different, but it’s started.

I want to build a system where APIs can be built using Node.js in a way that allows you to piece together different methods.  I realize there are systems out there like this, but I couldn’t find anything that meets my goals.  Besides, I wanted to build it.  Today was a longer day.  More than an hour, mostly because I didn’t want to leave it in a half state.  I can continue tomorrow where I left off with a working system and clear next steps.

I live streamed the entire session using Twitch.  There was one point where I was dealing with an error that I could not figure out.  Here is the moment I discover the very simple error. At some level, it’s fairly embarrassing to have that live on video.  But things like that do happen.

Most of this is being designed as I go along.  I’m not so concerned about performance at the moment.  Mostly it’s about getting it working.

Syndicated 2016-12-02 04:29:51 from JasonLotito