<![CDATA[Daniel J. Petersen's Devblog]> 2015-08-16T18:37:05-04:00 http://danieljosephpetersen.com/ Octopress <![CDATA[Still Working on the GUI]> 2015-06-05T20:13:01-04:00 http://danieljosephpetersen.com/still-working-on-the-gui Work continues on the GUI system for It Always Ends In Nuclear War. In my last post I talked about how I was working on an automatic layout system so that I don’t have to worry about manually positioning GUI items on the screen. This was surprisingly hard to do, but I did come up with something that I’m happy with. It’s not the greatest thing in the world as I only have so much free time to do this, but it should definitely help me out in the future.

At the most basic level, I’m thinking of each GUI component as a rectangle that takes up space on the screen. The layout system just manipulates rectangles for me by positioning and sizing them based on properties that I define for the rectangles. So if for whatever reason I want a GUI component to span half of its container in width, and all of its container in height (a container the size of the screen is always the top most container), be anchored to the left edge of its container with an offset of however many pixels, be centered vertically, as well as have constraints on the size (min/max width and height), I can do that really easily. The cool thing is that each GUI component can have other GUI components as children, allowing me to embed and use these position properties inside other GUI components.

I’m going to be working on the GUI system until it’s finished. I very much want to be done with this task and start work on the actual game again, but I think patience always pays off in the end. It should be worth it to have a good base so that I can quickly create / iterate on the GUI screens. In terms of components, at the moment I have a

I think that’s a pretty good list of things, but I still need to build out a tab container, dropdown list, input box for text, a list view, numeric spinner, and a color picker. I also want some way of making certain components scrollable. I have some vague ideas on how to go about making the components scrollable, but I’m not really sure how I’m going to do it yet.

I’m also trying to pick out color schemes for the GUI. I am not an artist, so I’m going to be going with plain colors / shapes instead of using premade images as a lot of games do. I’m thinking something simple like white text on a semi transparent background as shown here looks pretty good.

<![CDATA[Three Day Weekend]> 2015-05-23T10:28:24-04:00 http://danieljosephpetersen.com/three-day-weekend I went to sleep at 7 PM last night, and woke up this morning at 9.30. I’ve got a three day weekend, I’ve got 14 hours of solid rest, and I’m ready to get shit done on It Always Ends In Nuclear War.

The biggest thing holding me back has been lack of a good GUI library. A lot of the game will come through interacting with the GUI, so it has to be easy and quick for me to iterate by adding / moving components around. It also has to look half-way decent to the end user. I’ve looked into third party GUI libraries in the past, and it’s been rough. I wasn’t sold on anything that I saw, so I opted to see how it would be making my own GUI from scratch.

It’s been okay. I’ve lovingly titled the GUI system I’ve been making SubGUI. I’ve got a button widget, radio button widget, a navbar, a progress bar, dialogue box, message box (dialogue box being a popup window where you click okay to dissmiss, messagebox being an area of the screen where messages appear / fade away after a certain amount of time), and an initial version of a slider. I’ve basically been making widgets as I needed. I’ve run into two main problems, though.

The first was blurry text. I narrowed it down to using antialiasing. Apparently if I had antialiasing turned on, the text also gets smoothed out, which is pretty terrible. I solved that problem by drawing the text on a RenderTexture off screen instead of directly to the window. The text still doesn’t seem as crisp as it does in a web browser, but I feel like it’s crisp enough, and if I spend some more time on it I’m sure it’s a solvable problem.

The other thing of concern has been how to handle the layout, which I had been doing manually. Each widget has an onResize method, and I define how it positions itself / sizes itself there. This works, but it’s a huge pain in the ass, and I don’t want to keep going down this route.

The way I see it, I have two options. I can either look into third party libraries once again, or I can try my hand at seeing if I can come up with something that automatically lays out my components in a reasonable way.

The path of least resistence is to look into third party libraries / frameworks, which I’ve been doing the past week or two. It’s been rough. I don’t want to deal with working in another language, so that means only C++ libraries / frameworks. I’ve considered in one way or another qt, wxFrameworks, gwen, imgui, myGUI, crazy eddies, gtk, using chromium to build the GUI with web tools (html, css, js), guichan, otterUI, SFGUI, and turbo badger. Out of all of them I liked imgui the most, but I wasn’t sold on any of them.

I’ve decided that I’m going to go ahead and do the stupid thing, which is to make a layout engine and continue to create my own GUI widgets. I started to implement it on Thursday, and I think it’s reasonable. I’ve got a design for the layout API, a decent idea on how it should behave, and three days to make it happen. I’m actually hoping to finish the layout manager early, and work on adding more components to the framework, but I’ll be happy enough if I come out of this weekend having something which does automatic layout in a reasonable fashion.

<![CDATA[Risk 2.0]> 2015-04-04T12:42:40-04:00 http://danieljosephpetersen.com/risk-2-dot-0 Late last Saturday I decided to check out Typescript, which is a programming language which takes Javascript and adds static typing, classes, and a few other much needed features. I’m really liking it, it’s so much more of a joy to work with compared to regular Javascript. Javascript gets a lot of hate, and while I think a lot of that hate is unwarranted, it definitely can be improved upon, and there’s no doubt in my mind that Typescript is an improvement.

So I played around with Typescript and ended up making a clone of the board game Risk.

I’m hosting it here – http://www.danieljosephpetersen.com/risk/
The code for it is here – https://github.com/DanielJPetersen/Risk

I have no idea what the proper project structure is for a Typescript project, nor do I know how to properly do version control with it. I suspect you’re not supposed to commit the .SLN file, but I can’t say that this project is important enough, or that I’m motivated enough to find out right now.

But yeah. Feature wise it’s complete, although I made a few sacrifices such as a lackluster UI, and I opted to allow infinite moves per turn. I think in the official version you can attack an unlimited amount of times a turn, but only move an army to a friendly territory once per turn.

This concession was made entirely for the AI, which I still need to finish. I imagine it won’t ever be good, but I think it’ll be all right once I finish up the code for making the AI capture a continent if it determines it has the numbers to do so, and spreading its armies better across continent chokepoints. There’s also one bug that I’ve encountered and need to squash, where occasionally territories won’t change owners after an attack. I’ve looked into it and I have absolutely no idea why that’s happening.

I’m thinking I’ll spend a few hours over the next week on finishing that up. This weekend, though, I’m going to continue to work on my eternal struggle, It Always Ends In Nuclear War. I think I have to occasionally take a break from working on It Always Ends In Nuclear War and do these smaller projects, or I’m going to lose my mind.

<![CDATA[It Always Ends in Nuclear War Update 3.21.15]> 2015-03-21T13:46:00-04:00 http://danieljosephpetersen.com/it-always-ends-in-nuclear-war-update-3-dot-21-dot-15 I was supposed to post an update last Sunday on what I accomplished that weekend on It Always Ends In Nuclear War, but I didn’t end up accomplishing much. I spent all Saturday and Sunday debugging various errors with the game that had popped up, which is harder to talk about than shiny new features. I mostly worked on fixing issues / crashes due to incorrect syncing of data between the province view screen (pictured below) and the actual game data.

I don’t expect this screen to look anything like this when the game is done, but it has to look like something for now and I’m not sure where it’ll end up. In any case, I’ve worked out all the issues and the game is once again solid as a rock in terms of bugs / crashes. I have no one but myself to blame for the issues, though. I’m making my own GUI system for this game and it’s a learn as you go process.

I also spent a little bit of time last weekend stress testing units / pathfinding and I’m pretty happy with the results.

That’s a few hundred units auto exploring the map. This is subject to change, but I currently envision the game ticking along at a solid rate similar to the Europa Universalis series, so it’s pretty important that the time between turns is almost non-existent.

Last night I built another GUI widget for the game – We now have progress bars! Try to contain your excitement.

It might be a bit hard to see with the embedded screenshot. At the moment I’m using it to countdown time until the next game tick occurs (aka the next ‘turn’), as well as to show the progress of things being produced by a province.

The remainder of this weekend I’m going to attempt to actually hook up the province growth algorithm that I have planned. I want the number of births per 1000 people to roughly approximate the rate that populations have grown through history. I’m going to have a rudimentary model of disease and a food/starvation system to keep populations from growing indefinitely. In Civilization, population grows on a stairs sort of system, where it’s flat for a long period of time and then it bumps up instantly when you fill up your food bars. I want the population in this to grow in a more linear fashion, until you start developing technologies to eliminate starvation / disease.

<![CDATA[Now With Comments. . .]> 2015-03-13T19:21:34-04:00 http://danieljosephpetersen.com/now-with-comments Just a small update to the website – People can now comment on articles thanks to Disqus.

I’m hoping to get a lot of work done this weekend on It Always Ends In Nuclear War. Assuming all goes well, I plan on posting a small progress update on Sunday.

<![CDATA[Ruby Is a Mess on Windows]> 2015-03-07T23:17:49-05:00 http://danieljosephpetersen.com/ruby-is-a-mess-on-windows If you’re wondering why I haven’t updated this website in a while, it’s because this blog is using Octopress, which requires Ruby and quite a few gems in order to work. I reformatted my computer a month or two ago, which means that I needed to reinstall my Ruby enviornment. I suspect it’s because I’m on Windows, but I’ve run into quite a few issues trying to get everything up and running, and I haven’t had the heart to fix them all until now. Seriously, Ruby on Windows is an absolute mess. I hope I never make the mistake of doing another personal project with Ruby again, because this is unacceptable.

For comparison, I checked out the most popular non-ruby static site generator out there which is a Python library called Pelican. I don’t even remotely like Python, but it was an absolute breeze to get up and running compared to Octopress with Ruby. I like the default look/layout a lot better on Octopress, so I decided to stick with the current setup for now, but I’m going to have to switch this blog over to something else eventually.

Who cares about that though. Let’s talk about the game that I’m making, It Always Ends In Nuclear War.

It’s been slow going, but I’ve been getting at least a few hours of work in every week, and I have super high hopes for this thing. The subtitle of this blog is “documenting my struggle to make a videogame”, and it really is an absolute fucking struggle. I feel like the code behind it is good, but there’s just so much to do, and if I’m being perfectly honest I have no idea how to design a video game. It feels debilitating knowing that it’s all on me to make this thing a reality. I feel like I’d be a lot better off personally if I had never decided to try to make a game, but I think I’ve reached a point where I not only have to finish it, but where I know that I can in fact finish it, and that it’s going to be good. It’s a very nice and sobering thought to me.

When it’s closer to being complete I’ll get around to posting about how it actually plays, but for now I just wanted to post this little update.

<![CDATA[Linux!]> 2015-01-11T15:30:31-05:00 http://danieljosephpetersen.com/linux I worked a bit today on the code for getting armies (units) working, and then got bored of that and decided to get the game up and running on Linux. Cross platform libraries are crazy – It basically worked out of the box.

The low FPS is from the screenshot program freezing everything.

<![CDATA[It's the Little Things Which Matter]> 2015-01-01T11:02:42-05:00 http://danieljosephpetersen.com/its-the-little-things-which-matter Happy new year! Let’s get to it.

The Civilization series used to have a flaw in that the minimap would reveal exactly where you were on the map. It wasn’t a huge deal, but it could be abused in some situations. For example, if you spawned near the top of the map, you’d be able to see that and plan accordingly. Scouts would be sent south, settlers would be sent south, and no time would be wasted exploring the north of the map. I’m not sure what version of Civilization fixed this, but it was fixed by having the minimap zoom in to fit the area explored.

I’d like to have that same need for exploration in IAEINW. You should have to explore or look at the terrain type to figure out where you are on the map. Up until today, however, you were able to abuse the sides of the map to figure out where you were in the world. Check out this old screenshot to see what I mean.

A few months back I sort of fixed it by only drawing a side of the map if a player discovered a tile on that edge of the map, but this wasn’t perfect. The entire side was still drawn, so you could gauge exactly how large the map was and where you were in it once you discovered one edge. I’ve been wanting to fix this for a while now, and today I finally got around to it. I’m now only drawing the edges of the map between the furthest explored reaches of the edge. Check it out to see what I mean

There are more important things I could be working on, but it’s the little things that make me happy.

<![CDATA[Everybody Loves Pathfinding]> 2014-12-29T03:12:24-05:00 http://danieljosephpetersen.com/everybody-loves-pathfinding I’m still working on It Always Ends In Nuclear War, which I suppose can be described as my attempt at a 4x civilization-building game. Randomly generated map of the world, small group of people founding a city at the dawn of civilization, expanding your territory, meeting other civilizations, making alliances, fighting wars, discovering technology… That type of thing.

I admittedly don’t have much progress to show at the moment, but I am putting in a great deal of time and effort. I think the problem is that I have incredibly high standards, and I’m never quite happy with what I come up with for the game. I want to produce something that is not only fun, but a unique take on the genre. I want to produce something that looks good graphically. It also has to be something that I can create in a reasonable amount of time.

I feel confident that I can program whatever design I come up with, but coming up with a good design is challenging. I’m working on this project by myself, so I’m very much working in a bubble. Creating something that is not a cookie cutter copy of the popular titles in the genre is hard. Doing it without having someone to talk to about the ideas is harder. I’ve settled on a few different designs in the past, prototyped them out, and hated them. I’m keeping at it, and I have confidence I’ll get there eventually, but it’s just frustrating. Frustrating and time consuming.

Graphically I like the direction I’m headed, but there’s definitely something not quite right about it. I’m about as far from an artist as one can possibly get, so I think what I’ve done so far is pretty good, but like I said, it’s still not there yet. As you can see, the current thinking is that the entire game is going to have a textureless look, possibly even going as far as to have no sprites or external images used at all. This serves a dual purpose - It takes some pressure off of me having to somehow get high quality art assets, and I also think it gives off a unique stylistic vibe.

One of the design decisions that I’ve settled on is that the game will not be turn based. It’s going to tick along at a solid rate, similar to how the game Europa Universalis works. Another design decision that I’ve settled on is that there are going to be armies, settlers, and ships roaming around the map. This provides a bit of a challenge in regard to pathfinding. I want the game to be playable on a modest computer, and given how large the maps are (84,000 tiles!), and given how many units could possibly be present on the map at a time, pathfinding needs to be trivial from a performance point of view.

I implemented a pathfinding algorithm known as a* (pronounced a-star) forever ago, and it miraculously still works with It Always Ends In Nuclear War after all the changes I’ve made to the code (check out the above screen; purple tiles would be the path), but I’m going to have to improve the system further if I don’t want it to grind the game to a hault.

It’d be great if there were two search modes – an accurate mode, which found a path on the actual map the player sees, and a simplified mode, which was essentially finding a path on a representation of the map on a smaller grid (because there’s worse performance for larger search areas). In fact, I already have a smaller representation of the grid coded up in memory. The game was initially more akin to a clone of the game Civilization II, and looked like this zoomed out:

I described in this post how I went about taking the old maps, which were about 5,000 tiles in total, and transforming them into the new maps, which are 84,000 tiles in total. It should be pretty trivial to keep the old map in memory, perform our pathfinding on it, and then convert the tiles into tiles on the larger map. This would be useful for if a unit needs to plot a path far from where it’s currently located.

This would even allow me to precompute and/or cache some common paths, which is the approach I took in the game Sins of a Hex Empire. There I stored the path to every possible location you could travel to from any given hex. Generating a map took slightly longer because it had to precompute all the paths, but it allowed me to have a better AI since I could brute force more stuff, and it had no wait time between turns.

You can see this working here. It shows the number of turns it would take from the topleft most tile to reach any other given tile. This was done and saved for each tile. Then to find a path, you’d just start at the goal and travel backwards, with the next tile being the lowest number. Truth be told it was overkill for the game, but I think it might be worthwhile for IAEINW. It wouldn’t be a good idea or perhaps even feasible to do with 84,000 tiles, but it might be reasonable for the simplified map.

That’s all for now. Hopefully I’ll have some actual progress to report soon.

<![CDATA[On the Importance of Free Time]> 2014-11-06T22:34:45-05:00 http://danieljosephpetersen.com/on-the-importance-of-free-time The most valuable skill that I know is programming. It’s paying the bills through an awesome job, and it’s filling my spare time through personal projects that I enjoy working on and articles that I enjoy reading. I have no idea where I’d be right now if it wasn’t for programming, but there’s no doubt in my mind that I’d be worse off.

It’s a skill that I never would have picked up had I not had an absurd amount of freetime somewhere around 2012. I was going through school to become a Stenographer (I went on a pretty decent rant about Stenography two posts down), and the school only met for two five hour days a week. They expected you to practice in your spare time, but truth be told, I never felt the need to. Stenography came naturally to me, and 10 hours a week was more than enough for me to graduate half a year earlier than expected. I had a part time job at Staples, but that didn’t eat up too much of my time either. I began looking for things to do with this free time and decided to take up programming, I’m not even quite sure why. I guess I had a vague idea that I wanted to make create things for the computer.

Learning it was hard. I remember buying huge books, reading them slowly, and then rereading chapters which I didn’t quite get on the first pass. I remember working on a lot of small projects where I bit off more than I could chew and churned out some awful code. I don’t consider myself a particularly good programmer, and I guess it’s funny how that works out – I was unnaturally good at Stenography, something that I thought I’d do for a career but it turns out I’m never going to have a valid use for in life, but I very much struggled with programming, the thing my actual career requires I be good at.

I’m very lucky that I had that free time in 2012. I would not be where I am right now without it. I would have been able to put in the time it required for me to reach a certain level of competency. I would not have even known that programming is something that I enjoy, something that is valuable, indeed more valuable than anything else that I had known prior to that.

And there’s the point. I feel like you need free time in order to figure out who you are and what it is you want to do with your life. Hell, you need free time to figure out what it is you even want to do with your free time. I feel like most people don’t have the luxury of free time. They’re working paycheck to paycheck to survive, or they’re putting in too many hours for school on a major that they picked on a whim.

I remember being interested in learning how to program in 2010. I was in college at the time, and thought I’d sign up for an intro to programming course and see what it was like. There wasn’t any at my school. But I did find a course on making basic websites, I think it was an intro to HTML or some other nonsense. I came out of that class knowing less about how to make a website than I had when I came in. The lectures they had didn’t explain much or give any context to anything. What they did teach was how to copy website code from an ancient HTML book, and the code wasn’t even good. The book had websites which were constructed with tables and frames, it probably came straight out of 1996.

And there’s the other point. You are the only person you can rely on to learn what you want to learn. Yes, you’ll need to use guides and resources provided by others, but it’s really up to you to research that what you’re learning is good practice and the proper way to do whatever it is you want to do. And to tie it back into the previous point, you need free time in order to do this. I have no doubt in my mind that I would have came out miles ahead had I put in my own time and research into learning how to make websites instead of essentially taking a gamble and signing up for a course hoping that whoever was the instructor knew what they were talking about.

<![CDATA[The Looming Indie Crash?]> 2014-11-03T20:53:51-05:00 http://danieljosephpetersen.com/the-looming-indie-crash I just read a blog post from Cliff Harris, the man behind games like Democracy 3, Gratuitous Space Battles, and Gratuitous Tank Battles. This is going to be a response to that post.

To preface this, I respect Cliff quite a lot. I probably value what he says more than anyone else in the industry, and if there was one person that I’d want to model my career after, it’d be him.

With that being said, I think I disagree with him on this. I don’t know that a crash is incoming. People want to make games. They’re going to do it as a hobby, or part time, or they’re going to risk everything and take the chance at going full time indie. They’re going to do all this whether or not they make money. And statistically, they won’t make money, but it doesn’t matter. They’re going to continue making their games, because they love games.

Not only do they love games, but they love their games. Objectively their games are shit, but it’s hard to judge the value of your own work. You tend to either think it’s a lot better than it actually is, or you tend to think it’s a lot worse than it actually is.

I’m making a video game. I’m going to sell this game. I’m not expecting to make any money from it. I’m not expecting anyone to even care. I’ve read countless post mortems at this point detailing how they made 23 dollars their first week, if even that. But I’m still going to do it, because to me, my game is awesome.

There’s a reason why the games industry is able to pay programmers a lower salary than they would earn in other software fields. There’s a reason why they can work these guys longer hours than they’d be worked in other software fields. People love games. People want to play games. People just want to work on games, and they’ll do it whether or not it makes sense financially.

I’m not sure I understand his Unity comment. I don’t personally use Unity, but I think it’s a good business decision to do so. You’re offloading a lot of tedious work that you would otherwise have to do yourself. It’s a tried and true engine which you can rapidly prototype with. I’d even go so far to say that it’s borderline irresponsible to not use an engine like Unity or Unreal 4 if you’re not already an established dev with an engine under your belt like Cliff is.

We’re probably moving into something more akin to the music industry. There are so many unnamed and unprofitable bands out there, but it doesn’t matter. People will continue to form bands, and most of these bands won’t make it financially. Some people (most? all?) just have a deep seated desire to create.

<![CDATA[Programming and Stenography]> 2014-10-31T00:00:00-04:00 http://danieljosephpetersen.com/programming-and-stenography Before I got into programming I was interning and on track to be a professional stenographer. It’s a stenographers job to transcribe spoken word into written form, usually for courtrooms, conferences, TV captioning, or to help out the deaf community.

In order to be able to keep up with how fast people are able to talk, Stenographers type on specially designed machines like the one above. These machines allow people to reach speeds of 300+ words per minute. You have to be able to write at a staggering 225 words a minute with at least 99.9% accuracy in order to even be eligible for work. To put this into perspective, 110 words per minute is about as fast as the most people can hope to reach on a regular keyboard setup.

I think people see these stats and start imagining all the different scenarios and uses cases for being able to type at 225+ words per minute. To give an example, I watched a presentation and read a Hacker News thread a few days about an open source program which is best explained as Microsoft Word for stenography machines. It’ll translate the strokes from a stenography machine into English and it’ll also allow you, with the help of an attachment you’ll need to buy, to turn a regular keyboard into a stenography machine. Stenography can now reach the common man!

A lot of people seemed generally optimistic about the idea of stenography creeping into everyday life, or at least other professions. One person asked, “If Plover can effectively make Steno keyboards understandable by our OS of choice… Should we start teaching our kids this thing before they ever get hooked into qwerty?”

And the answer is no.

Stenography is in no way shape or form suitable for everyday use. The talk I linked to above was pushing the idea of using stenography for programming, which is in my opinion is an awful idea. I cannot hammer home this point home enough – no one should seriously consider it.

This is the stenography keyboard. Notice anything unusual? There are only 21 keys on there, yet there are 26 letters in the alphabet. And it’s actually more unusual than that, because there are a few letters which are on both the left and right sides.

QWERTY is pretty straight forward to learn. There’s a key for every letter in the alphabet. You press a key and it appears on your screen. Simple. And yet I still see people struggling to type above 40 Words Per Minute.

With stenography machines, the keyboard is separated into two halves. On the left half there are only 9 keys, but each letter of the alphabet can be written with those 9 keys because it’s context sensitive. The letter “t” by itself would be the letter t, but if it’s next to a “k”, it might become the letter d.

You’re not so much typing letters as much as you’re typing sounds. So the word “car”, for example would be written “kar”, or the word “talk” would be written “tauk”. You’re also not typing letters individually. The entire word is considered as a whole, and the goal is to press as many letters of a word as you possibly can at the same time. So for the word “tauk” you’d press T, A, U, and K at the same time. Sometimes you can get the entire word in one stroke, but some words you need to come back for a second, third, or god forbid forth stroke.

Because it’s all phonetics based, you run into conflicts like “sell” and “cell”, so you still need a way to write a c, but that’s the gist of it.

Worth mentioning is that there are only 4 vowel keys on the machine. A, O, E, and U are the vowels that are on there, and if you press one of those keys individually, you’d write a short vowel of that key. If you wanted to write a short I, you’d press E and U together. You would write long vowel sounds by combining different vowels together. So for example, if you wanted to write a long e sound, you’d write aoe, long U sound would be aou, long a sound would be ai (or aeu depending on how you look at it), long o is oe, and long i is all the vowels together at once.

You can see that combining letters together to represent more complex strings is a big part of stenography. The real secret behind it is that they take this concept to the extreme. People use what they call briefs, which is combining commonly said words together into unique key strokes. “T S” combined together might form “it is” for example. And because speed is the only thing people really care about, the concept is taken to an insane degree. People try to abbreviate everything. Entire sentences written in one stroke.

What does all of this mean? For starters, it can be hard to read what you’ve actually written. The word dime, for example, you’d see raw as “TKAOEUPL”. TK for D, AOEU for long I, and PL for M.

It means that everyone is writing in their own language unique to them as an individual. Sure, you might learn the same theory as another person, but that theory gets warped and manipulated into an abomination of its former self thanks to the necessity of using briefs to achieve the desired speed.

It means that you have to go through a painstaking process of defining your own dictionary so that the machine can translate your strokes into english. This will take years. I was at it for two years, and while I was able to write at around 240-50 words per minute, I still had a daunting number of briefs and phrases that I was adding to the dictionary on a daily basis.

It means that speed is the only thing that people care about. At high speeds people are advised to just write something down, -anything- down in the heat of the moment, because you can decipher it later on. Which of course means having to actually go through what you’ve written and make sure everything is properly translated into english, because you’re going to make mistakes when you’re writing that fast. A misstroke might be obvious, or it might be a mistroke which forms another word or phrase. You won’t be looking for just an underlined red word, you’ll be checking every word written to make sure it’s the word or phrase you meant to type, decoding everything you’ve written based on the context it was written in. Sure, you’ll write write at 225 words per minute, but the aftermath is time consuming. Definitely more so than writing at 110 words per minute and not making any mistakes, which is something I’m confidently able to do with a regular QWERTY setup.

It means stripping syllables off of words in order to get the word written in fewer keystrokes, which of course adds to it being harder to translate later.

To expand on the last two thoughts, your writing will be vague. You can type exactly what you want to appear on screen with a QWERTY keyboard, and there will be no ambiguity about it. You can certainly type the exact thing you want on a stenographic keyboard, curly brackets with proper spacing and all if programming, but you’ll need to be unreasonably good to do so.

It means that it’s a complex system which is time consuming to learn. They tell you it’ll take two years to learn, but I’ve met people that were at the school for 4+ years and unable to advance. It doesn’t appear to be something which everyone is able to grasp.

It means changing your very way of thinking. I think anyone who reaches the state of being able to write at 225 words per minute has to have their way of thinking shift slightly. Stenography is now engrained in my brain, and every word, every single phrase you can possibly utter is permanently associated with a hand motion. It does not add any value, and it does not go away.

I’m quite frankly not even sure why people want to program at 225 words per minute. The bottleneck in programming, for me at least, is how fast I can think, how fast I can design and structure the code, and how fast I can solve problems. How fast I can type has never been a bottleneck. Stenography requires a certain portion of your brain power, so your thinking is going to be bogged down by adding that layer of abstraction between you and your writing.

Given that, I wouldn’t be surprised if stenography actually hindered programming. I think it’s very telling that the person leading the Plover project has had a hard time learning how to program. That extra layer of abstraction is distracting from the actual goal, writing code.

I’ve heard the idea that stenography might be good in terms of preventing arthritis or repetitive stress injuries, but I think that varies depending on the person. My hands have not been the same since I took up stenography. There are professional stenographers that I’ve spoken to who complain of horrible hand pain. I personally don’t have any problem typing all day on a regular keyboard, but a day of stenography takes a toll on my hands.

I think at the end of the day, the Plover guys are trying to solve the wrong problem. Stenography is a dying field. I don’t wish anyone to lose their livelihood, but realistically speaking, the job should not exist once text to speech technology advances far enough. I’m not claiming that the field will be replaced by it, but I also don’t love the idea of people having to learn such an inane and archaic system.

<![CDATA[The Destruction of My PC, and the Coming Code Bootcamp Destruction?]> 2014-10-24T00:00:00-04:00 http://danieljosephpetersen.com/the-destruction-of-my-pc-and-the-coming-code-bootcamp-destruction About two weeks ago my desktop (video card?) decided that it was done with life. I was jamming away working on It Always Ends In Nuclear War when I was greeted with a bluescreen of death. I started my computer back up and the resolution was keyed in at 800 x 600 with a scattering of red pixels on the display. I decided that the PC was haunted and that it was time to go all out and get a new PC. I just finished building it yesterday, and I’m pretty excited.

  • ASUS Z97-A ATX DDR3 2600 LGA 1150 Motherboards Z97-A
  • EVGA GeForce GTX 780Ti 3GB GDDR5 384-Bit Dual-Link DVI-I DVI-D HDMI DP SLI Graphics Card 03G-P4-2888-KR
  • Ballistix Sport 8GB DDR3-1600 (PC3-12800) CL9 Desktop Memory Module
  • Ballistix Sport 8GB DDR3-1600 (PC3-12800) CL9 Desktop Memory Module
  • Core i7-4790 3.6 GHz 1150 Boxed Processor
  • Hyper 212 EVO Universal CPU Cooler
  • GXII 750 Watt ATX Power Supply
  • MX100 512GB SATA III 6.0Gb/s 2.5” Internal Solid State Drive CT512MX100SS

I’m pretty damn happy with it. Its destroyed every game I’ve thrown at it, and it compiles It Always Ends In Nuclear War soooooooooooooooo damn fast. I couldn’t really work on the game until I had my desktop in order, but now I can get back to work full speed ahead.

In other news, the author of Learn Python The Hard Way and Learn Ruby The Hard Way is going to be posting a series of articles criticizing coding schools. I attended Dev Bootcamp in early 2014, so this is particularly interesting to me. For what it’s worth, I’m glad I attended Dev Bootcamp. Mostly because it was a cool experience, but I also think I learned some valuable things from it, both programming wise and about life in general. That being said, I don’t particularly think coding schools are a great investment if you’re new to programming, and I wouldn’t say that I learned to program from Dev Bootcamp. Don’t get me wrong, it definitely helped, especially on the web dev front, but I’ll be very interested to see what Zed Shaw has to say.

<![CDATA[New Website?]> 2014-10-13T00:00:00-04:00 http://danieljosephpetersen.com/new-website I’ve been thinking tonight about what my future plans are in terms of this blog. I enjoy posting on it, and want to do so more often, but perhaps more than that, I also want to add some features to this website (and in extension, It Always End’s In Nuclear War’s future website) that I think would be pretty awesome to have.

Unfortunately, they’re features that aren’t really suited to Wordpress. Wordpress is awesome and I have no complaints with it, but I do think it’d be a challenge to accomplish what I want to do with Wordpress.

I also find myself wanting to brush up on my Ruby skills, which are getting rusty at this point. I’m therefore thinking that I’m going to spend some time redoing the website, probably building it out with Ruby on Rails and switching over to Digital Oceans (sorry Bluehost!)… Or not. I’m not committed to this idea yet, it really depends on how much work it turns out to be. I suspect it’ll be very doable, but that might just be me being naive.

I mainly want to have the website closely linked with It Always Ends In Nuclear War. For example, I’ve been keeping a gallery of every screenshot I’ve ever taken of the game, but it’s hosted on Dropbox, which isn’t really ideal. Those screenshots should be hosted on this website. I also think it’d be cool to continue documenting the game in this manner, even after I release it. I’m thinking aloud here, but It Always Ends In Nuclear War should have a screenshot button built in, which will automatically save the image to your PC, but also automatically upload it to this website for everyone to see. And we could go further than that. People in the Civilization Community post playthroughs of their games on community forums, and they’re actually a really fascinating thing to read. They go through painstaking detail to take screenshots as they progress through their game, and keep notes so that they remember what their thought process was during that point in the game. The game could provide a nice and official avenue to pursue something along those lines and have it posted here. Along that same manner of thought, there could be a centralized place to share saved games. You could tie in the documentation of the progress feature with the save game sharing, so that each picture is accompanied with a saved game.

I literally came up with that idea out of the blue while writing this. I’m not saying I’m going to do that, but I think there are a lot of really cool unexplored possibilities, and I want to have my options open in case I decide to pursue them. First thing first, transferring this blog off of Wordpress…

<![CDATA[Domain Names]> 2014-10-04T00:00:00-04:00 http://danieljosephpetersen.com/domain-names I’ve had www.it-always-ends-in-nuclear-war.com and www.italwaysendsinnuclearwar.com registered for a while now, but I’ve finally gotten around to routing them to this website. I don’t think this particularly matters at this point, but it’s nice to know that I have the name. I’m going to eventually break it out into its own website, but that’s not going to happen for a good while.

<![CDATA[It Always Ends in Nuclear War Update 6]> 2014-09-28T00:00:00-04:00 http://danieljosephpetersen.com/it-always-ends-in-nuclear-war-update-6 It Always Ends In Nuclear War is a game I’m making which aims to simulate human history, allowing you to guide a people from the dawn of civilization into modern times. You can find the previous post about it here, or click here to view a gallery of almost every screenshot I’ve taken during development (currently 715 screenshots!).

Creeping slowly toward playability…

<![CDATA[I'll Be Damned if I Can't Do That]> 2014-09-19T00:00:00-04:00 http://danieljosephpetersen.com/ill-be-damned-if-i-cant-do-that I moved into a new apartment a few weeks ago, and I haven’t yet bothered to get a computer desk. Truth be told, I’m not sure if I’m going to even bother getting one. My current setup has me situated on the couch, with my desktop monitor on a small table in front of me. This is a pretty good setup, but it’s not very practical to use a mouse with. I mainly use my PC for programming nowadays, and there’s not too much of a need for a mouse, so I decided to get a keyboard which had a trackpad attached to it.

It’s not what I’d call a good keyboard, but it’s pretty good for my use case. Problem is, I use the F5-F7 keys as hotkeys for programming, and this keyboard has media keys in their place. You can press the F keys, but you’ll have to press and hold the FN key first, which is annoying to say the least. I hopped onto Logitech’s website and downloaded their software which lets you control how the keyboard works. I didn’t see an option to disable the media keys, or switch the FN toggle. After a bit of googling I found a forum post by a Logitech help staff saying that you can’t do what I want to do.

That can’t be true now can it? I think the coolest thing about programming is being able to make the computer do whatever you want. I’m happy to report I have my Fkeys back by writing a short script which will convert a media key into it’s prospective F key upon press. It took 3 minutes.

<![CDATA[It Always Ends in Nuclear War Update 5]> 2014-09-14T00:00:00-04:00 http://danieljosephpetersen.com/it-always-ends-in-nuclear-war-update-5 It Always Ends In Nuclear War is a game I’m making which aims to simulate human history, allowing you to guide a people from the dawn of civilization into modern times. You can find the previous post about it here, or click here to view a gallery of almost every screenshot I’ve taken during development (currently 682 screenshots!).

I recently moved into a new apartment, which took up a bit of my free time, but I’m all settled now and back to working on this game in my spare time. I’ve started a system in which I assign myself weekly tasks, and it seems to be a good mechanism to keep myself motivated and on track. These are pretty specific tasks that I think I can reasonably accomplish in a given week (ie: This week one of my tasks was to finish a basic version of a dialog box gui widget).

I’m going to be experimenting with a milestone system, too, which I think will also help out with keeping me motivated and on track. The current thinking is that at the beginning of every month, I’ll create an overview of features which I’d like to be completed at the end of the month, and I’ll designate this with a version number. This month I’m hoping to have a very basic version of the game playable, which I’m going to be designating alpha 0.1. Here’s the list of features for this month.

The past week or two I’ve been working on creating some simple GUI widgets, and a general structure for which to manage the game’s gui system. The widgets are going to be pretty ugly for a while, because I don’t particularly care about that at the moment, but code wise I think the system I came up with makes a lot of sense, and will be easy enough to work with.

I think that’s about all for now.

<![CDATA[It Always Ends in Nuclear War Update 4]> 2014-08-29T00:00:00-04:00 http://danieljosephpetersen.com/it-always-ends-in-nuclear-war-update-4 I’ve made a very rough and hastily put together general overview of what It Always Ends In Nuclear War is going to be. It’s just a general overview with all nitty gritty details stripped away.

<![CDATA[It Always Ends in Nuclear War Update 3]> 2014-07-29T00:00:00-04:00 http://danieljosephpetersen.com/it-always-ends-in-nuclear-war-update-3 It Always Ends In Nuclear War is a game I’m making which aims to simulate human history through the ages, allowing you to guide a people from the dawn of civilization into modern times. You can find the last post about it here, or click here to view a gallery of almost every screenshot I’ve taken during development (currently 615 screenshots!).

The gamedev community at large has this thing called Screenshot Saturday. I participated in it this week with these two screens.

In other news, the game was mentioned on Rock Paper Shotgun. How fucking cool is that? It honestly made my day, and I’m still coming down from it.

In actual development news, I’d say that I’ve been working on tile type generation (ie: adding deserts / ice / forests to the world instead of it consisting of just ocean and grassland) the past few weeks. It was like two solid weeks of failure, followed by something I was semi happy with (the screens in the last update), followed again with something that I’m happy enough with for now but need to eventually improve (the above screens).

I’m now working on finishing up the game design. It’s been a huge struggle to come up with a design that I’m happy with. I feel like I’m capable of programming whatever design I come up with, but coming up with the actual design has seemed hopeless at times. To give some perspective, at one point I decided to move onto a new project because I couldn’t come up with anything I liked. And that’s with a design document filled with about 4,000 lines of ideas.

Which makes it all the more satisfying that I think I’ve finally come up with something which will be interesting and worthwhile. I’ve had a general idea of what I wanted to do for a few months now, but it’s been an abstract idea in my mind until tonight. The design still needs a bit of polish before I post about how it’ll play. I’m hoping next update I’ll get into it, most likely with some screens of a super early prototype being played. I can’t guarantee that anyone else will enjoy what the game will be, but I think it’s cool and that’s good enough for me.