Project 18: Video Game Play Tracker

I've been tracking the video games I play for the last few years now. It started out as a move to help me remember what I actually played over the course of a year and how now become something of a habit, as well as a good way for me to be more mindful about how and what I play.

Thus far I've been tracking what I've played in a Google sheet (actually 3 of them at this point). This works pretty well for the most part and it has a lot of nice "analytics" features (by which I mean it has nice pivot tables). I'm finding though that the Google sheet doesn't scale as well as it could and it's a little limited in terms of visualization options (especially 3 years into tracking).

At the same time I've been feeling a bit behind on some practical development skills. I'm not practicing as much as I'd like and when I do I'm messing with my behemoth PhD system.  (A story for another day.) I also don't play with as many dev tools and services as I'd like to.

Combining those things along with spending the last 4 months teaching novice Java programmers and I've decided to give myself *yet another* project. Generally my goal is to: make the Game Tracker work, make it work with Google Sheets and take advantage of anything that seems fancy and cool. Also get a little practice in working with a good git workflow and taking advantage of the tools GitHub provides. And most of all not to let any of this get in the way of the other things I need to be doing.

The goal here is to keep it small and keep it simple. For Phase I, I'd like to get the basics set up: a text menu system to track games and play sessions and save and loading to file. I'll check in next on May 15, 2018.

(And if you find yourself wondering what happened to those games he was talking about, I'll get back to those, but this (right now) seems like it's going to be more compatible as a project that I get to work on after all my other work is done for the day.)

Project 16: Covert Action in Space: Update 2

I've been working on my Covert Action in Space project and reached the point where I wanted to be able to see a graph of the spaces I'm generating. Particularly, when I was working on my first system, it was difficult to get a feeling for how the spaces work (or if they worked). At first I had been thinking that I’d look and find a simple algorithm to draw a graph and then implement that in something simple like Processing. Fortunately, poor google-fu prevented me from finding a good algorithm and instead I found GraphViz.

I'm not sure I want to work here, but I'd look for their industrial secrets.

Despite that tweet, I managed to keep my wits about me and realize that I don’t need to create my own graphing system, I just want to see a graph of the space layout. So instead of spending time learning a graphing algorithm and dealing with all of the problems that’s likely to create, now I just need to output a simple text file and let the magic happen.

GraphViz is great. It’s capable of doing a lot of stuff of which I only need it to do a little bit. To output, I need to make a list of all room connections and put it in GraphViz’s dot format. Internally I’m keeping this information in a map so that each entry has all of the rooms that a room connects to. This produces duplicates in the list, but using the strict keyword GraphViz automatically ignores those.

The code to generate the dot file works out to be quite simple.

And the dot file for the graph up top. Again I'm not particularly stressing GraphViz.

As I said, this makes it really easy to look at how spaces are connected and how those spaces work. I’m really glad I was able to get this working without needing to spend too much time on it.

The next job from here is to start laying out an actual floor plan based on the given space. I have a rough plan, basically starting with a default shape for each room and then expanding them to fit together. I can probably come up with something more complex, but as with the space generation, I’d like to start simple.

Project 16: Covert Action in Space: Update 1

I spent quite a bit of time working on my first approach to procedurally generating spaces. I based a lot of what I did on [this paper] and ended up with a system that worked, but that ended up pretty complicated. It had a system for creating an arbitrary hierarchy of spaces, as well as an arbitrary rules engine, which provided systems for determining how rooms were connected to the outside and each other.

I had already finished that work when I first posted about the project and I thought I'd keep working with that system. I realized, though, that solution was overbuilt and over complicated. So I ended up spending a quick evening rewriting it. The arbitrary hierarchy was very difficult to maintain and creating rules that abstractly described space was frustrating, so I dropped all of that and went back to figure out what I needed to make a minimal viable product.

If my goal is to play with guard AI, then I need space for the guards to guard, furniture to play hide and seek in, graphics to see what's going on and some AI. Plus possibly an interface to play.

The new system was a little messy, but thanks to a timely beer with a friend who had just been reading Uncle Bob, I came out with a nice clean system. I now have:

• A model which describes how to make a space:
• Model rooms which include a room name and a probability that the room should be on the space. 
• A space that includes:
• A list of rooms and a map 
• A constructor that builds a space based on a given model 

The first question I had was would it still be interesting. And I think (at least for limited test situations) it is. Using a basic model of a Hall (with probability 1.0), Office (0.75), Storage Room (0.6), Lounge (0.5) and Bathroom (0.25), it has provided an interesting set of rooms and connections that, I think, could each provide an interesting encounter in a game.

At this point, I’m just producing the text outputs of the system, but I think the above sampling produces something “interesting”. My evaluation for “interesting” right now is: Can I imagine how an interaction between my spy and a bad guy would go down in that space. For the samples above I think I can, and I think with more models, I can expand the interest of the space.

My system has a known bug right now in that it isn’t guaranteed to produce a fully connected graph of rooms. I think that’s a quick thing that I should fix in the near future. Other than that my next step is to put together a quick graph viewer to show how the rooms connect. Once that’s finished then it’s on to expanding the graphs to physical space.

Project 16: Covert Action in Space

Sid Meyer has a rule, the Covert Action Rule. The Covert Action Rule basically says don’t make Covert Action.

So the next big thing I want to make is basically a recreation of Covert Action. Covert Action in Space.

In covert action you play a super spy (or super agent … or super counter-agent … or something). Each month you’re given a mission and some basic clues. Then you have to stop the bad guys from doing whatever they’re doing. If you succeed you get a clue about the current mastermind plotting the crimes. Once you’ve figured out who and where the mastermind is you can grab them and wrap up that crime spree. Then some other mastermind starts up again the next month.

Now, I’m trying to finish a PhD, so it’s a really stupid time to take up making a game, but that’s where the Covert Action Rule comes in. Basically the point behind the Covert Action Rule is that it’s hard for the player to remember what they’re doing when they have to keep switching between generally unrelated minigames, so make sure that your player always knows what they’re supposed to be doing (XCOM also falls into this territory).

My thought is that given limited time and attention, making a collection of interesting minigames, seems like a good idea. I can work on one minigame when I have time and I don’t have to worry too much about making the whole thing hang together. It should be good practice getting a game made without worrying too much about making the game good.

As for the “in Space” part. I have a sci-fi world sitting around in my head, with a few stories I’d been meaning to write (and a few I’ve managed to put up here). It seemed like a good way to modernize a game that had fallen into abandonware and give it an interesting spin. Rather than having to fight 1990s terrorist across Europe, you could fight space terrorist across the Terran Empire.

The original game had four main minigames; one where you infiltrate people’s offices, stealing their information and possibly arresting them, one where you drive through the city either trying to capture someone or avoiding your own capture, one where you have to swap chips out to trace a car or bug a landline, and one where you have to decrypt messages doing a simple substitution cypher.

I think there are a lot of fun things that could be done after to stretch the game and make it a little more playable than the original. Before that however I want build the original four minigames and get a skeleton basically. Of the four, I’d like to start with the infiltration minigame, and especially with a little bit of fun procedurally generating offices (possibly to do different things) and building up a guard AI.

Due to a mishearing, I accidentally created the mascot for this project. The Flurpin.

I’ve started a bit over the last few months and I have a rough system together that takes requirements for buildings and is able to generate a procedural room graph, that connects all the rooms, but doesn’t actually build a floor plan yet. My next short term goal is to finish creating the floorplans from the graphs. Given that I still have a PhD to finish and this is mostly a “watching TV with the laptop out” activity, I’m hoping to wrap up this the floor plan generation by October 15, 2017.

Project 4: Snake Version 0.3.1 - now with a little less crashing.

Version 0.3.1 of the snake game fixes a problem where pressing the 't' key to give yourself points before the game starts caused the game to crash. All the cheat keys (and the control swap key) now only work while the game is playing.

All the other features introduced in version 0.3.0 remain unchanged.

You can download it here:

The Windows Versions (32-bit, and 64-bit)

The Mac OS X Version

The Linux Versions (32-bit and 64-bit)

Project 4: Snake Version 0.3.0 (Almost Undetectably New!)

The Snake game has still been holding my attention, so I've put together the newest update. This new version however is primarily changes to the design and organization of the game.

Does this mean you won't be able to tell the difference from version 0.2.0? Not entirely. The new structure has made it easier for me to switch things in and out and make things a little easier.

The biggest change is that now the controls are modelled after those implemented in Nibbles. This means that when you're heading in any direction you can now only turn to the side rather than back on yourself. However if you liked the original controls, all you have to do is press 'k' to switch between the two controls.

Furthermore if you want to make things easier or harder on yourself there are some cheats available:

• Press 't' to add a point to your score, this moves the target and is just like you hit the target on your own.
• Press 'y' to add a level. This levels you up, speeding up the game.
• Press 'u' to turn off collisions, so you can go on forever without worrying about running into yourself. Press 'u' again to turn them back on again.

That's pretty much the update for this time. Lots of changes that mean more to me than you, but it should make it a lot easier to do the things I'm thinking for the future. Speaking of which Version 0.4.0 will be along in a little while and should bring a GUI and different kinds of worlds to play.

But for now you can download Version 0.3.0 below:

Edit: See the Patched Version 0.3.1

• The Windows Versions (32-bit, and 64-bit)
• The Mac OS X Version Edit: There seems to be a problem with the Mac OS X app. I will investigate as soon as I can.
• The Linux Versions (32-bit and 64-bit)

Project 4: A Further Surprise Snake Update (Version 0.2.0)

So it seems I still have a lot of procrastinating to do. I've managed to turn out another version of Snake. (This time version 0.2.0).

This version introduces:

* Awful Sound Effects - it's weird old beeps, that kinda appealed to me
* Mute - press 'M' to turn off the awful sound effects (this doesn't preserve between games yet)
* Scaling Snake Colour - now as the snake grows it fades to grey towards the end of it's tail. This makes it easier to see which way you're going (especially when coming back from pause).

Please play and let me know in the comments if you run into any problems or bugs or any thoughts at all really.

You can get the game from these links:

• The Windows 32-bit version and the Windows 64-bit version
• The Mac OSX version
• The Linux 32-bit version and the Linux 64-bit version

Thanks as always!

Project 4: A Surprise Update on the Snake (Version 0.1.0)

Again, my skills in procrastination have allowed me to get things done. This time, now that I don't have it as an active project, I managed to put out a revision of the Snake game.

This version introduces a couple of new features:

• Pausing! Now you can press 'p' to stop the game whenever you want. To resume the game just press any of the arrow keys and start going again. 
• Bouncing Scores! I'm sure I'm the only person who cares, but now when you hit a target the score bounces up and down a little bit. It's not amazing animation, but it's something.
• Proper key handling. This doesn't change the game at all, but I was able to apply a lot of the things I've learned about Processing.org and realized that the tutorial I'd followed way back in the beginning had a strange way of handling key presses (relying on the main loop of the program). Now I've updated it to use proper event handling. 

You can download the update:

• The Windows Versions (32-bit, and 64-bit)
• The Mac OS X Version
• The Linux Versions (32-bit and 64-bit)

If you'd care to beta test this for me I'd really appreciate it. Leave me your thoughts in the comment section.

Project 4: Snake: Update and Wrap-up

It may have taken me nearly a year to do a few afternoon's worth of programming, but the first version of my Snake game is finally done. (Spoilers: You can play it using the links at the bottom of the article.)

This was quite a bit of fun to put together. One of the nice things about programming a game (especially one this simple) is that the results are immediately visible. It's also nice to have small targets to hit that are fairly easily achieved.

The game plays pretty much like any instance of snake you may have run across in the past. I did choose to have the edges of the world wrap because I was entertained by the math, but I also enjoy that it does cause you to think a little extra since the snake is not always apparent as adjacent to you. Right now the game speeds up for levels 1 - 10, but the game doesn't end until you reach level 33.

For the record though you can technically win the game, however I'm not sure how possible that is in reality. I've found the responsiveness with my Mac Book Pro to be insufficient at the higher levels, but with a different key board it may be easier. It's also somewhat difficult because there's no boarder around the snake and so it's very difficult to see where the snake is at any given point in time.

I'm pleased with the level and score markers that pop up. It would be nice to have them fade in or out, or for the scores to bounce a little. I decided to stop where I got to and if I'm able to put those in as extras in a later version. Additionally in later versions I'd like to add some game modes and manage difficulty better than I am right now.

I'd really appreciate some help testing out this version of the game. If you have a little time I'd like to know:

• if/how it works on different platforms (links are below)
• if there are any bugs
• is it fun? What could make it more fun?

Comments in the comment section would be appreciated.

For now it needs to be downloaded, it's not really worth making it embeddable.

• The Windows Versions (32-bit, and 64-bit)
• The Mac OS X Version
• The Linux Versions (32-bit and 64-bit)

Control the snake with your arrow keys. You can quit with the 'q' key and win with the 'w' key. From the game over screen you can start playing again by hitting the space bar.

These should all run with the included files. Processing has an automatic generator and I've found that the Windows and Mac versions seem to work for me. I haven't had time to test it on Linux yet.

Thanks for your support. I'll do another version but for now it's on to other things!

Projects 4 & 5 Deadline Update

So I've dropped well past the deadlines I gave myself for both the Snake project and the SNES coaster project. This has been due to a combined effect of actually getting things done at work, having some catastrophic computer issues and not getting excited enough and getting things done.

It's a coaster (or it will be)

On the SNES coaster project, I have managed to get excited enough to at least start making prototypes (as you can see in the picture). I still have a bit of work to do figuring out how I'd like them to work (in particular they need a backing for added table protection, plus reinforcement of the beads) and then I need to actually make a few and test them out as coasters. Ideally this should all happen in the next week so I'm giving this project a new deadline of November 24, 2012.

I've made less progress with the Snake project but am planning to jump back on it soon. I haven't actually tackled any of the items I discussed last time and given schedules for all the things that need to be done, I think I won't have too much time to focus on it. I'm giving this project a new deadline of January 1, 2013.

Project 4 : Snake : Update

The deadline for the first phase of the Snake project was September 1, 2012. By that point I had hoped to have a basic version of the game up and running. Unfortunately, I wasn't quite able to finish all that I'd hoped to do in the given time period.

Snake. Version 0.1 - it's almost a game.

What I did manage to get done was all the basic parts of the game except for the actual snake. I have a dot that goes around the world and can hit another dot that gives the player a point. This is mostly the point of snake, but right now my snake can't grow a tail.

Building the game in Processing.org was interesting. Processing is designed for non-expert programmers to be able to develop animations and interactions. It based on Java, but has a limited set of  the java utility libraries (although it does allow for other libraries to be added). The java basis is convenient because that's the language I've done most of my development in so far, however not having things such as queues makes things (such as the tail of the snake) harder to implement.

Even though I haven't finished the tail of the snake, it's interesting to note that the game already has the feeling of snake. The controls have a slight delay (because the movement of the snake is not linked to key presses) which feels very similar to most of the other implementations I've played in the past. I actually find this somewhat frustrating, since it causes you to have less control than you might. In the implementation I finished a while ago (and then deleted somehow) I implemented the control differently (I think I had the snake move on the key press regardless of its speed) and this made the game much more controllable and less frustrating.

Since I didn't get everything done in the last phase, I'm going to start my next phase by finishing getting the snake's tail running. I also want to implement the move-on-key-press control system and a way to switch between the two so there are traditional and "comfortable" modes. I also want to put in some of the "game" functionality, including a start screen, a pause screen and an on screen score / level system.

It's come back into the semester and sadly I still have one class left to complete in my PhD, so this can't be a high priority for the next few months. I don't think it will take a lot of time to finish but I want to do a good job so I can have it in a state where other folks can play it, so the balance of all that I'll end this phase on October 14, 2012.

Project 4 : Snake

As I have mentioned here before, one of the goals I have is to design and make video games. I don't know that I mean to do it as a career (said the perpetual student) but  it would be a fun hobby.

I don't have experience in games programming (baring some assignments during my bachelor's degree) so I need to start actually doing something to start getting some experience (you have to start your 10 000 hours somewhere).

I figured to give myself an achievable start I'd though I'd tackle something with not too many moving parts. As such, I thought I'd implement Snake. For the uninitiated, in basic snake you play a snake, made up of squares and you eat dots which make you longer and you try not to crash into things (either the wall or yourself.)

Emulation of the Snake I remember best on the TI-83.

I like snake for a number of reasons. The first as I mentioned is that it's relatively easy to program and a simple implementation can be put together in a day or an afternoon (even if you don't really know what you're doing). It is also easily extendible (it's not too much extra work to get to tron bikes or to caterpillar) and still has enough game play aspects to introduce interesting ideas.

This is not a terribly novel thing to do. There is a site at snakegame.net which has an archive of some of the more interesting implementations which come in a variety of flavors. There's also a cool version Snakes on a Cartesian Plane which plays with a lot of different game play concepts and ideas.

It's punny and an exciting experiment.

A friend of mine, who happens to be experienced in the way of game design, mentioned a developer who always implements snake as a way to get familiar with a new platform. I feel like this is a good idea and I'm planning to follow that as well as I start teaching myself how to make games.

The first stage I'd like to finish is to implement a vary basic, limited graphics version of snake using Processing.org. I actually did most of this a while ago but somehow lost the project on my computer so need to start again. This should be fairly quick (as I said maybe an afternoon of work) but I'm going to give myself a deadline of September 1, 2012 to finish.

Project 2 : The Ogre Manager

One of my fondest memories is receiving Ogre Battle 64 for my birthday (a long, long time ago). It's gone on to be both one of my favorite games of all time, and also one of the games I have the strongest associations with. Every year when the days get short and the weather gets cold and snowy, my first thought is to put Ogre Battle in the N64* and spend the afternoon pitting my army against the morally ambiguous other guys.

From GameFAQs - user Count Dackula

One of the things that's a little unusual about Ogre Battle, is that while it may look like your usual 90s RPG with swords and magic, you don't actually get to control anything. You take the role of the organizing general, setting up units out of your soldiers and then deploying them to the battle field with orders to take over a strong point or defend a town. Once the game starts they march where you tell them and fight the enemies according to their own internal mechanics and you just get to sit back and watch.**

Your units (in Blue) fight the "Bad" Guys (in Red). You sit and watch.

From GameFAQs - user Storm Shadow

The fun of Ogre Battle comes in putting together all the different character's available to you (some you train up from recruit soldiers, some are given to you by the story and some you pick up from the wild) into units that fight well together, then level them up. Like many strategic rpgs (and as I understand Ogre Battle shares developers with it's cousin series Tactics Ogre which basically spawned the tactical/strategic rpg) the challenge in the game comes from leveling the right units up at the right time. In particular, you have to be careful that a unit has the correct alignment (lawful, neutral or chaotic) and that your units don't become over leveled.

The game tells you what each character's level is, but doesn't give you the total for the unit. As a result I started to keep track for myself, using a sketch book a pencil and my high school Casio not-quite-graphing calculator.

The stats for a character. Sadly I can't find a screen cap of the unit info.

From GameFAQs - user Storm Shadow

After a while I started to realize that the unit I left to defend my base sometimes wasn't strong enough to hold its ground.*** Realizing that I also needed to keep track how much damage each unit was dealing, so that I could always leave the unit most likely to win its fights at home, I started to keep track of that too.

Around this time the Computer Scientist in me started to think that keeping track of this on paper was maybe not the most efficient way to do things. In addition to my mitigating my ability to add calculation errors and screw up putting the numbers down in the right places, I thought it would be nice to be able to graph my progress and maybe keep track of a bit more information. So I started bringing my laptop to game time and keeping track of the statistics in Excel.

One set of unit data for one of my play-throughs.

So, having upgraded myself technologically, I kept on playing. In addition to being able to keep track of each of the characters in a unit, both their level and their attacking strength, I was able to keep track of their alignment (which I could have done before, but now we have a whole spreadsheet to play with right?). However, I wasn't exactly happy with this set up for two different reasons.

The first reason was technical. While the spread sheet kept track of the unit at any point in time (before each mission) it didn't keep the history of the changes. I started to keep a new spread sheet for each mission, but without doing more work than I was really willing to do it meant that I couldn't really graph my progress. Doing this isn't essential to the game or anything very important, but it's still something that would be fun to track.

The other reason was more artistic. As you can see in the screen-shots I've included, there's a very strong esthetic to the game. Everything is very medieval in style and switching from that to the ... polish ... of excel is rather jarring (as you may have noticed) in a way that keeping my information on paper wasn't.

Enter: Ogre Manager, a program I'm creating to solve these two problems. It's not an essential thing, in fact I'd be nearly as happy to go back to tracking all this on paper, but it also struck me as a good chance to practice a whole bunch of things that I've let languish far too much.

The Notes panel from Ogre Manager. It shows who should defend the base, who needs leveling and which units should be grouped together. (But not into in game Legions, those are a terrible idea.)

In short, the vast majority of the programming I do is command-line style stuff and as such I don't get much practice working on GUIs. Ogre Manager seems like a good chance to practice that, in a situation where there's not a huge penalty for not getting everything right. Secondly it would be nice to be able to make a program with a graphical look and feel that matches the game. Whether this is in the form of a look and feel for Java Swing, or Java FX, or custom environment, it will be an adventure trying to put this together. Thirdly this seems like the kind of program that would make an excellent Android app, which is another area in which I'd like to have more experience.

Right now I have development mapped out into 4 phases. The first phase is to finish a Java-standard look and feel program that keeps track of all the information I want to track, which as the screen shots show, has been started. The second phase is to implement graphs and other visualizations of the data. The third phase is to create the Ogre Battlely look and feel and finally the fourth phase is to create the Android app.

Time to go make something.



* In fact, Ogre Battle doesn't really come out of my N64.

** Or clutch the controller in impotent panic as your unit gets wiped off the face of the earth.

*** One of the mechanics of the game is that after a battle is resolved, the losing unit (the one who dealt the least damage) is pushed back on the battle map. The distance it goes is based on how much damage it received. When your base defense unit gets pushed then the enemy can beat you by just walking right into your base.