I’m sharing out StreamWords with people. Hopefully people will enjoy it. We have fun playing it on stream. Things I’ve learned about StreamWords.
I want to include a tournament mode. Set it to 10, 20, or 30 words, and let it run. People get points for guessing the word, but also getting the letters as well. This means if someone guesses letters, they can still get points and no one falls too far behind. Guessing the word is still the most points, but it also rewards playing. It also helps account for latency.
Latency is an issue. On platforms with added latency, like Twitch, I’d have to account for this in some other way (letting people go to the site to play, but that means people can’t play while watching stream. It’s a challenge.
It’s filling, and i like it. I also had some coffee with honey.
It’s busy. 😩
]]>But maybe I should. I should try to come up with basic quesitons I ask myself each day.
Coffee. I like coffee. With honey.
My desire to cook. I enjoy cooking, and I enjoy exploring new recipes, and making things up as I go along. I come up with some tasty things, and it’s always enjoyable when I find a new mixture of foods that just taste good.
I’m working on a few things.
First, I’m streaming most days. I give it little thought. I should.
I’m at a cross between working on streaming tools and building games. I’d like to do one or the other.
World of Warcraft TBC Classic in preperation for Wrath of the Lich King.
No Man’s Sky.
PUBG.
Fortnite.
These are the big games I’m playing at the moment.
I’m trying. I monitor what I eat, and I aim for more protein and more vegetables than anything else. I try to incorporate more vegan meals than not.
]]>A word guessing game build for streamers. (admin) Inspired by Wordle, this game was built with YouNow chat in mind. It’s simple to setup, and designed so that streamers can play. It’s mean to be a small, think client, allowing streamers to decide how they want to use it. It supports English at the moment, ensuring that players cannot just spam the chat with random letters.
]]>This was annoying, but easily resolved.
You can easily disable this in PowerShell by running this command:
Set-PSReadlineOption -BellStyle NoneHowever, what you probably want is to disable this every time you open up PowerShell. Doing this is simple. In PowerShell, type
notepad $profile
This will most likely ask you to create a file. Create the file, and then enter the above Set-PSRReadlineOption command into the file. Save it, and close it. Now, new PowerShell windows that pop open won't make that annoying beep.
You can find out more about these profiles over on MSDN.
]]>PowerShell works with objects rather than plain text. While this might seem odd, it's also pretty powerful. So, if you run the ls command, it will return a bunch of objects that have fields (Members). You can figure out what this is easily by running ls | get-member.
PS C:\Users\jason_000> ls | get-member...Name Property string Name {get;}Parent Property System.IO.DirectoryInfo Parent {get;}Root Property System.IO.DirectoryInfo Root {get;}BaseName ScriptProperty System.Object BaseName {get=$this.Name;}...
So, I've cut out a lot of information, because you get a lot of members you can work with, but you get the idea. But what this means is if you just want all the names, you can run (ls).name. That will return a list of just the name members of the objects that would get returned normally.
Get-History is history.
$$
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.]]>
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.
]]>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=0Pragma: no-cacheExpires: 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.
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.
]]>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!
]]>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.
]]>