Not sure how to introduce this blog or myself, but here goes:
I go by Tangent, or Rose, and I’m a programmer with interests in video game design, web services, motorcycles, the furry fandom, and probably a bunch of other stuff. This blog is where I will be sharing ideas, mostly of the variety that have not been turned into a successful project. I am starting it to declutter my notes and various books of ideas that I cannot continue, but I am sure there will be more to write about.
In addition to my primary goal of sharing ideas related to video game design, web services, and any other area of programming, I sometimes write short stories or attempt to write novels. These will be shared here as well.
That’s it for now, hopefully you find something of note or worth from reading things here in the future.
(This post has been imported from an old blog of mine.)
The One Hour Game Jam is a weekly game jam, of one hour. I participated in #64 long time ago (though I did not get anywhere), and more recently, #152. The submission period is for the entire week, so if you can’t make the official hour, you can still participate. There’s also a Discord server for it, and weekly livestreams during the official hour and playing the games after.
Breakable Objects (#152)
Long story short, this one was a big success for me. I took about 2 hours to make the game* and a couple hours over the next couple days polishing it and adding quality of life features. I made a simple asteroid-dodging game, Asteroid Dodge. Newtonian physics, the number of asteroids increases every second, and your score is based on how quickly you travel between randomly created waypoints. Everything is circles and lines, inspired by a realistic air traffic control project I had just started (see Endless ATC, a game similar to what I’m aiming for).
My biggest success and failure was the same thing: Deciding to make a version-checking library during a game jam. I knew very quickly that I was going to be rapidly iterating on the idea (even once published), and I wanted to be able to notify players. I’d done this for SCP Clicker some time ago, but that was hardcoded for it only, and I needed something for any game project going forward. It was a success because I made something I’m happy with, a failure because it took too much time away from the game itself.
I’m very glad to have managed to get my game shown on the livestream, even though it required making them wait and was the last thing shown (whoops!). I was able to watch people have their first impression and read comments from stream viewers, and thus noticed bugs and improvements to be made. Also, the original score was based on velocity alone, which made it feel like there was no goal. What I had when the jam was over was pretty crap, but I also knew exactly what to do to make it a finished (albeit small) game.
Walls (#153)
Or, as is relevant to here: Ambition Destruction. I spent the first 20 minutes thinking of an idea, ultimately deciding to make a clicker/incremental-type game about being contracted to build Trump’s “great wall”. After struggling through some GUI code and realizing I needed to make a vector map of the southern border of the US for what I was imagining, wasting another 20 minutes, I realized this idea was waaay too ambitious for the timeframe and my knowledge, and did something simpler: click to place bricks on a wall. After working on the graphics of building a brick wall for the last 20 minutes, I realized even this was too ambitious, as it required me to code something I hadn’t done before, and figure out how to do incremental upgrades (something I’ve only done very limited experimentation with so far).
Ultimately, I never submitted anything for this jam. A couple days after those two failures, I had another idea based on the player being a firewall, that slowly morphed into the player running an ISP, building out a network (how does this relate to the theme? well eventually you’d put in firewalls when there was too much traffic). I still want to finish that idea someday, but even after working on the plans for a while without coding it, I realized that I would again need to code some things I am unfamiliar with, and I believe it too ambitious to work on right now.
Lessons Learned
Some of these became much more apparent the second time around, but all of these are relevant to both weeks:
Use libraries that are simple, or that you have used recently. The second week, I struggled a lot using Pop.Box, an alpha-stage GUI library. I hadn’t worked with it in a very long time, so I ended up spending way too much time looking into the code or documentation to remember how to use it. If I had been using it more recently (or, let’s be honest here, if it was a better library), I wouldn’t have had nearly as much trouble and wasted time there. I could also say don’t use alpha-stage libraries, but as far as I am currently aware, there isn’t a good general-purpose UI library for LÖVE just yet. (To the point where I am developing my own..twice now.)
Do not create new components. By that, I mean any aspect of code that is something you are unfamiliar with. In the simplest case, this could be something like the algorithm I made for Walls to generate a brick wall from a number (how many bricks it has). That’s a very simple piece of code (once done!) but took way too much time. Likewise, you really shouldn’t go make a version-checking library during your one tiny little freaking hour for the whole project. I got away with that once, only because I was given more time and had made something very similar to it before.
Strip your idea to less than the minimum, or abandon it immediately. This lesson applies a lot more strictly here than in general, but one concept that I hear is core to game design in general is to fail faster, that is, to go as quickly as you can from an idea to realizing the idea won’t work, so that you don’t waste time on it. This is especially true when you only have an hour to go from nothing to finished. Both times I spent too long thinking about ideas, and while I managed to pull something off the first time, both times I was too ambitious initially.
* Half an hour thinking of ideas, half an hour coding it, half an hour making a version-checking library for it, half an hour setting up a page on Itch.io and building it.
(This post has been imported from an old blog of mine.)
For years I’ve been thinking about a rocket construction and flight game. Think 2D Kerbal Space Program, but with part design as well as craft design, and some SciFi aspects to it.
Just started on the project again and ran into a problem with the physics library I’m using (box2d), so for kicks I decided to calculate how many shapes I might need to try to make a planetoid have a variable surface instead of being circular.
Basically, a grandiose expansion of the concepts of KSP while simultaneously stepping backwards by making it 2-dimensional instead of within a 3D universe. I am a bit more realistic with my expectations than I previously was, so I know I’m not going to achieve it for a very long time, if ever, but it still is fun to think about or poke around with code or draw out some ideas from time to time.
This post has been removed because it was promoting a pop-psychology concept without sufficient research or thought, and I consider that idea bullshit.
(This post has been imported from an old blog of mine, and updated March 2018. It is November 2021 at the time of this edit, and this information is still accurate, up to date, and relevant.)
I made a post a while back about how to check if a user’s password is secure from the programmer’s perspective, but looking at it now, I realized I don’t cover a key concept, and I’ve learned about an additional measure that I really should have had on the list.
How to store passwords?
The number 1 most important thing to do is to NEVER store passwords. Instead, you use an algorithm to store a hash generated from a password. Why? In case you get hacked. If your database is downloaded, and it has user passwords, even if you repair any damage or stop the hack, the passwords are out there! But if you use hashes instead, they can’t be used to login.
How you hash matters though. If you use something like MD5, that’s trivial to crack these days. SHA-1 is a bit more secure, but still has been destroyed in usefulness for security. Which algorithm(s) should you be using?
bcrypt: The current de-facto algorithm for password hashing. It can be changed the strength of the algorithm to create stronger hashes even if computers get faster.
scrypt: Builds upon bcrypt by focusing on calculations that are harder to do on specialized hardware. It also can be changed to create stronger hashes, but the factor used to do this is exponential.
Argon2*: Won the Password Hashing Competition in 2015**, the only reason it’s not on the top of this list is that it is relatively new and not as proven as scrypt/bcrypt. (The biggest weakness with bcrypt at the moment is that it can be relatively effectively attacked with GPUs/FPGAs/ASICs, which scrypt and Argon2 protect against by increasing how much memory is required to compute a password hash.)
PBKDF2: Wasn’t actually intended to be used for security, but is rather slow, which makes for a good hash algorithm. (A big part of hash security is using a slow algorithm.)
It is most often recommended to use bcrypt as it is the most tested and known secure algorithm. It will probably be replaced by scrypt when scrypt has been more thoroughly tested and if vulnerabilities are found in bcrypt. PBKDF2 should really only be used if for some reason you can’t use the other two. If you want to use something else, don’t.
* Was added in March 2018 after some further research into the subject. ** I found a couple of sources claiming it was in 2015, but also one that said 2013. I’m not sure which is correct.
What kind of passwords should be allowed?
This was the whole point of the other post, and the first three items are almost identical:
Must not contain more than 6 occurrences of the same character.
Must be at least 12 characters long.
Must not be equal to or contain your username, your email address, the site’s name, the site’s URL, and associated keywords (like, your actual name on sites that store that info; or “Honda” on a motorcycle forum).
Must not be equal to the 10,000* most common passwords.
The change is to say you should have 12 character or longer passwords, and the addition is checking against the most commonly used passwords. The first measure is because computers are always getting better at cracking passwords, and cheaper. The second is because the first two rules don’t completely stop you from using commonly known passwords like password1234567890 or qwertyuiop1234.
* I say 10,000, but the list really should be just whatever most common passwords list you can get. This is something I need to research further myself.
Sources and Further Reading
These primarily relate to Argon2 since that is what I most recently researched when editing this post.
libsodium is a library for doing cryptography that I would trust with this kind of thing. I haven’t looked too much at it myself, but I pass the recommendation along from experts I trust.
