Daniel Petersen's Blog

Documenting my struggle to make a videogame, amongst other nonsense


Home Projects

Prototyping

Posted on 2016-03-27

It’s been about four months since my last post, so what have I been up to? Well, the day job takes up most of my mental energy, but I’m still working on It Always Ends In Nuclear War when I can. When I last posted about it, I was close to a working prototype for the game. I did in fact complete the prototype, which is really cool (!), but I wasn’t happy with how it turned out, which is not so cool. There were a few design flaws which I think made it more tedious than fun to play. I suppose that’s why we do prototypes.

I’ve gone through like four major designs with this game, and I’m hoping that my next go round will be the last one. If not, I’ll continue trying until I get things right. Each time I go through this process I gain more experience and more of an idea on what I need to do to accomplish what I want. I’ll eventually get it right.


Goodbye Windows

Posted on 2015-11-29

I’ve been using Windows almost all of my life. I remember the first computer my family got had Windows 3.1, which booted up to either DOS or a GUI version of Windows depending on what you chose on startup. I can’t remember ever having a real issue with Windows, it just worked and it did everything I wanted it to.

Honestly, I like Windows. It’s a modern marvel in my mind. I’ve read that even back in the XP days it was more than 50 million lines of code, which is mind boggling to me. I don’t know how large it is today, but I think it’s safe to say that its grown a bit. I think that the more I program, the more I appreciate complex systems which work reliably.

With all that being said, I’m going to be switching to Linux (specifically, Linux Mint) and using it exclusively for the foreseeable future. I could say that it’s because Microsoft has been doing some questionable things with regards to user privacy in Windows 10. I could say that their update process is also in need of an overhaul, as it takes hours to patch a Windows 7 install to be up to date.

I actually couldn’t even update my Windows 7 install to Windows 10. I got the notification icon saying that I’m eligible to upgrade, but I was greeted with an error when I went to install it. I consider myself pretty technical, but none of the fixes that I tried solved the error, and short of reformatting I saw no way of fixing the issue.

That all played a role in this decision, sure, but it wasn’t the catalyst. I like Windows 7, and I’d have stuck with it if I could have. Unfortunately, I got a notification out of the blue saying that my product key is invalid. I’m not entirely sure why – I bought Windows 7 in 2010 and I’ve been using it ever since. It had been a good 7 or so months since I last reformatted my computer, so it was really just out of the blue.

I was going to reformat and see if that fixed it, and failing that I was going to call Microsoft up to try and see why my key was now invalid. I then had a realization that I’m essentially asking a monolithic faceless corporation for permission to use my own computer, and have been since Windows XP. I can kind of understand that kind of security for a regular program, but for the entire operating system? It didn’t sit right with me, and it doesn’t have to be that way. There exists another operating system, another modern marvel if you will, and it won’t ever tell me I don’t have permission to use my own computer.

I’ve been using Linux on my laptop for a good year now, and it’s been a mostly pleasant experience once I got used to it. Program compatability is the only real hurdle to cross, but thanks to the internet it’s not such a big deal nowadays as lot of programs are moving online. I was worried about Visual Studio, and I was worried about games. I found a Visual Studio replacement in the form of CLion, which I’ve found to be a suitable replacement to Visual Studio. As for games, I’m going to be missing out on a lot, but I don’t play as many games as I used to, and my steam account has more Linux games that I can reasonably play anyway. With any luck less destractions will mean that I’ll get more work done on It Always Ends In Nuclear War.

We’ll see how this goes. I’ve been using Linux exclusively for more than a week now and, well, it does everything that I want it to.


Still Working on the Gui

Posted on 2015-06-05

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.


Three Day Weekend

Posted on 2015-05-23

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.


Risk 2.0

Posted on 2015-04-04

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 – Link
The code for it is here – Link

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.


It Always Ends in Nuclear War Update 3.21.15

Posted on 2015-03-21

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.


Ruby Is a Mess on Windows

Posted on 2015-03-07

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.


Linux!

Posted on 2015-01-11

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.


It's the Little Things Which Matter

Posted on 2015-01-01

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.


Everybody Loves Pathfinding

Posted on 2014-12-29

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.

Previous Page Next Page


Copyright © - Daniel J. Petersen