January 15, 2019

Web Development, Head First

When I first thought of the prospect of making my own company, I quickly realized that I needed to have some sort of online presence (read: website).

This idea was a little bit scary for me. I had no idea how to make a website, let alone host one. So, I'm going to tell you how I did it, and also show you some problems I faced.

Step 1: Skipping most people's Step 1

Okay, here's the deal: I pretty much knew the basics of HTML and CSS, meaning I understood a lot more than other people starting out with Web Development.

With that being said, I started looking at basic examples of building out a website with plain ol' HTML and CSS.

...After being disillusioned by that, I turned to the template market after I heard someone on StackOverflow saying that's how he learned Web Dev (Don't do this. People on StackOverflow at its worst are entitled pricks). This was a little annoying as I needed to find a template that I could sort of see being my website.

I eventually found a theme called Dopetrope created by HTML5UP (as seen on the footer), and downloaded it hoping to play around with it.

Step 2: Learning how other people's web designs work

This was the longest and most frustrating part of this process: Understanding it. Now, this may be that Dopetrope isn't that good or that I'm pretty clueless, but regardless of the Why the process was annoying. Figuring out how to change fonts or other information took a little bit of time for each.

After sometime I got it to look like this.

Step 3: Making the site functional

That right there is pretty much it. I had no links working, the font wasn't changed, and that background is butt ugly.

One of the more important things I did at this time was to separate the blog and the website.

Back then I assumed that the blog was going to be apart of the website. You might think that decoupling the two is a bad thing, and I could argue as well. However, for me being as bad of a Web Dev as I am, scrapping the prospect turned out to be a good idea.

I also had to figure out how to present my games. I decided early on that it was going to be on the front page (Cubytes is the green box, there's more information on it if the picture were to be scrolled down), but the actual page itself I had no idea.

However, Dopetrope actually gives you a sort of blog post type template, so I ripped that, leaned it down, added the content I wanted, and called it a day.

Step 4: Launching the Site 

Once I pretty much had a working website, I decided that it was time to publish it to the Internet. By this time I had already got the blog up and running, so all I did there was change the domain to blog.sledgehogsoftware.com and everything seemly was good to go. I uploaded the site to DreamHost, made sure everything was fine, and launched it.

Turns out it's not that simple. I ran into DNS problems, and that took me two days to fix (Eventually I abandoned Google Domain's DNS in favor of Dreamhost's).

The next set of problems were lack of https and the font simply not working.

https was easy to add as Let's Encrypt makes it easy and 100% free... but forcing https is another thing in itself that I still haven't figured out. For now it'll be fine.

The font issue opened up another can of worms. The problem turned out to be in my stitched together CSS file, in which I had no hope of fixing it. So, I did the most obvious thing and restarted the CSS file, and had it looking roughly where it was originally with a proper font.

Problem Solved!

Step 5: It seems good enough

Now, the website seems to be in good enough shape for me to leave on the internet. Over the next couple of days I might make some small adjustments to certain backend/SEO elements, but that'll be it.


January 1, 2019

Cubytes Devlog #002

As 2018 left and 2019 came, Cubytes received some tweaks and thoughts to the core game added to it recently.

The Story of Cubytes

Looking back on the previously released Alphas, there really wasn't any sense of story. The closest thing that came to a story was the Block Tutorial popups... which are really just textbox tutorials that have no kind of overarching narrative.

To make it clear, there is a planned Story (though I'm a little murky on an ending) with a planned narrator. You can see this in the C++ version of Cubytes, he's the guy that tells you to press Enter. The narrator will guide you and deliver important tidbits about the game as well as replace the Block Tutorial. The narrator will (of course) be voiced and have subtitles, just so that you can understand what he is saying without any sound.

The Story will be delivered by...


Distortions are features placed in the levels that serve as a hub-like experience inside of Story Mode. In them, you are transported to a simple place where you can save your game and hear audio samples of the Narrator.

The 'save your game' feature of Distortions comes as a change, as this will be the only place to Save. Think of distortions as bonfires of Dark Souls, but with an added sense of being (the narrator) other than to restock and prepare for the next levels.

Refactored Save Games

The Save Game functionality has been given a technical makeover this update. Previously it was written based of a Godot class called ConfigFile. At the time it seemed okay to write it as such, but as development went on for Alpha 7 it was apparent that the approach was flawed in a number of ways.

The ConfigFile class was designed as primarily an open tweak file for certain settings and information that can affect a Godot application.

Therefore, the file does not support encryption or even any sort of file obfuscation, which the File class does out of the box.

Collecting variables in a File class is much easier than a ConfigFile.

In a ConfigFile, you need to have the section and key of the variable. This is easy enough, but for some reason I could never find a way to directly plug in the results from the ConfigFile. The only way I could use the information is to assign it to a variable, and then plug in said variable into whatever I wanted. That might've not been a good example, so here's some code.

vsync = config.get_value("window", "v-sync")
fullscreen = config.get_value("window", "fullscreen")
resolution = config.get_value("window", "resolution")
master_slider = config.get_value("audio", "master_volume")
music_slider = config.get_value("audio", "music_volume")
sfx_slider = config.get_value("audio", "sfx_volume")
background_particles = config.get_value("gameplay", "background_particles")
show_fps = config.get_value("gameplay", "show_fps")

_on_resolution_changed(resolution.x, resolution.y)

While there's no syntax highlighting on that (stupid SyntaxHighlighter not working. and me not knowing how to install js libraries...) you can clearly see the variables getting some values from a ConfigFile, and then assigning it to certain UI elements.

With File, this intermediate step is removed and saving player information on my end became much more easier.