Not much of an update

03.22.2016

It's been a while since I posted anything, and my last post was just so chock full of news (good and bad) that I just had to let it sit out on the internet and simmer for a while.

Life has been busy lately and I've been trying to reorganize my hobbies. I haven't really been sure of how I want to spend my free time. Some of my hobbies have gone more to the wayside - boardgaming and painting, for example. I still enjoy them, but not to the extent that I did a year or two ago. I could chalk it up to being lazy, but I've been catching up on my TV/DVD watching over the past couple of weeks. I think there's a good chance that modern shows have reached the point to where it's nigh impossible to wait until a show has ended it's run and then binge-watch everything. There's just too many things to watch. There are a handful of shows currently airing that I stay a season behind while watching (Arrow, Flash, Big Bang Theory) and others that I've yet to start (Better Call Saul, Homeland, a couple more that I've forgotten). Not sure when/if I'll get caught up. There's a bit of a lull in new DVD movie releases so that may be my window to catch up.

Jerry and I are still playing Grand Theft Auto 5. Part of me still wants to play around with making a sandbox style video game. There's a YouTube tutorial series that looks pretty good on making such a game. I do better when playing around with Unity if I have a good tutorial to follow along with that I can hack along the way. I skimmed the first video without trying to program along with it and it seemed like a good video, and hopefully video series. Now it's on my list of things to try.

As I finally don't feel like an idiot at work, I'm more apt to try a little programming for fun. It's hard to get my brain in the right groove, switching from PHP/web programming at work and then C#/game programming for fun. To be honest, when I'm struggling at work my brain makes me feel guilty for switching gears. Maybe now I can freely switch.

My last boardgame idea is still simmering in the back of my head. About once a month I'll grab a notebook and make 4 or 5 pages of notes. The next month I'll go back and see how much still makes sense. Amazing how something that seems so cool and innovative when initially spewing forth turns to crap a month later.

Permalink game dev random

The Return of Joe Frag

12.05.2014

After a long lull I've been thinking of board game design again, specifically the much thought about Joe Frag rules that I can never feel like I'm making any real progress on. This past week my brain finally got on a little but of a creative streak and I was able to organize my thoughts about a few logic puzzles in my rules.

In my past notes for this little tactical skirmish game with a GI Joe flavor, I had scribbled a handful of characteristics and traits for the players to have. The problem was I had these attributes ripe with flavor for the game but I didn't know what purpose they were really serving other than, being many months removed from originally making them up, to overly complicate the game.

This was bad. My goal here was to make a simple game, unlike the slightly convoluted and parts rich Zombie Mall. Simple. Simple is important. I looked at the chart shown above with weapons. My goal with this chart was to make combat dependent on the weapon being used. Ok, that sounds simple enough. To give the weapons a variety, to where no one weapon was overall superior to another, each weapon (type) has a sweet spot as far as range is concerned where it is most useful. In this way a player can customize, within reason, how far away they want to be when they attack. The range titles (Short, Med, etc) are for modifiers that may be available later in the game, so that Medium Range for a Pistol vs a Heavy Machine Gun isn't the same, but an add-on that modifies a weapon for Medium Range could be applicable for both.

Once again I'm using a 10-sided die, with 0 equating to zero instead of 10. When a player rolls, they're trying to roll the To Hit number or higher. Most weapons have a higher chance of hitting at Melee Range than Extreme Range, which is to be expected. The Sniper Rifle is different, though. I'm still playing with those stats.

After I looked again at the weapon chart I found I liked the way it worked. I think it was the last thing I put a lot of thought into. But now I had player stats and no real idea what to use them for. I starting paring down what I had been scribbling off and on, then tossing around ideas of what these stats would equate to within the game. On my first pass I had an attacker rolling dice and the defender rolling dice. This didn't work, as it felt like the attacker was being penalized by having to first see if they hit the target (using the weapon's To Hit stat as the minimum to roll) then somehow beat a defensive die roll by the target to see how much damage was being dealt. This was not simple. This was convoluted. Instead I needed simple. A simple player, for now, has 5 stats:

• Health: Basically hit points. Players will start with 10. When it gets to 0 the player is out of the game.
• Movement Points: Similar to Zombie Mall movement, 1 movement point can move through 1 clear/open space. Unlike Zombie Mall this is not a die roll but the actual number of movement points available per turn. This makes movement less random and more tacticallish.
• Attack (Cooler name to be made up later). When attacking, the number to add to your rolled result. Since rolling higher is better, this helps you hit the target.
• Defense (An even cooler name to be made up later). When you have been attacked, this number is deducted from the damage dealt. Damage dealt isn't a die roll, it's a static number (The HMG does 7 points damage in the chart, for example). If the damage dealt is greater than the Defense number, the remainder is deducted from Health.

Fairly simple. There are modifiers for attacking and defending, the intricate details are still being figured out but I've got a good handle on how they work.

Player turns will be based on a player normally controlling multiple units with a pool of actions available for those units. Ideally a player should be able to manage 3-9 units (I'm targeting 5 while fiddling with these rules). A lot of how this works I'm borrowing from Dust but dumbing it down a whole lot.

The key now is to keep this simmering in the back of my head and keep making progress.

Permalink game dev

Unity Asteroids Pt 2

10.08.2014

After about 2 weeks I'm at the point I'm ready to call my little Unity Asteroid Shooter done, or at least 90% done. It's got laser particle effects, explosions, sound effects, and some begin/end screens. For a 7+ hour tutorial I played with for a month, there's a lot that it does along with a lot that's missing.

The one thing I skipped that's in the tutorial is keeping up with high scores. The tutorial uses the UserPrefs object, which stores values in the registry. Simple enough to use and implement, but I'd much rather use a plain text file for now than messing around with registry entries. Registry entries are a pain to track and debug. In addition, I haven't messed with any file functions in C#, and this boils down to some C# functionality versus Unity coding so it's a good excuse to learn.

I would like to better tweak the GUI of this game. I've got a couple of ideas to play around with, and it's more fun to tweak a working game than to experiment with something from scratch. If it starts out working and I break it, I can always back track. Phase 1 will be to change out the space ship model and associated effects. I think I've got a BSG Viper sitting in a directory somewhere...

I haven't posted the actual game to play, mainly because there are some licenses involved since I paid for the tutorial and associated assets. Plus I've never built a Unity project for "public" use and would feel really bad if I corrupted a computer with a memory leak or some such. When I leave the number of asteroids at the default set in the tutorial my monitors turn off after a minute or so and I'm forced to reboot. So I'm just looking out for you, the general internet public.

Plus, it's a fairly boring game unless you've spent a month getting it to work.

Permalink game dev video games

Unity Asteroids

09.21.2014

I've been (slowly) making my way through the last 3D Buzz Unity tutorial I purchased at some point in the last 2 years. The tutorial goes through and creates a 3rd person space ship shooter where you fly through an ever expanding asteroid field. I'm about halfway through coding the 7+ hour video series, having watched the series once just to make sure I know where all of this is going.

I make little mistakes following along with the videos. I type a wrong character or forget to add a component. So far there hasn't been any problem that's popped up that's taken more than 5 minutes to track down and fix. Part of following along with the video is annoying in that the guy doing the programming has a quirky way of naming his variables. A globally accessible variable is named in UpperCase. That bothers me as normally I would make them camelCase (which he uses for local variables in functions, which I would also do). This can be a little confusing when a variable ends up with the same name as the class, such as:
        public Camera Camera;
Camera is the class, while Camera is the object variable. That just bothers me. I big part of me wants to fix it (Camera camera), but the times I've tried this in previous tutorials I've gotten lost & confused when following along. Instead, I've opted to add lots and lots of comments in my code when pausing the video to try to force myself to explain what is being taught. This makes my tutorial progress slow, almost agonizingly so, but I think I learn more from it in the long run.

Earlier today I ran into my first problem that had nothing to do with actual code. The game has reached the point where my virtual spaceship can fly through the virtual asteroid field. No collision detection is set up yet, so nothing bad happens. Asteroids pop into view based on what can be seen on the monitor - only asteroids in the field of view exist and have movement, nothing (mathematically) is happening behind you or to the sides. My problem was that my monitors would randomly turn off. The computer is on and running, but the video output dies. Once I reboot the computer everything is fine.

Unfortunately I can only guess at what is causing this. My first guess is that the math of keeping up with 400 asteroids moving in 3D space is too much for my 5 year old computer. It shouldn't be, as the 5 year old computer was built for gaming and I don't want to think that I'm making a tutorial game that can break it. There could be a secondary process running interfering with the video - I think at least once I was transferring some video files over the network.

This always happens when I start to pause the game, which thanks to the controller setup means the ship starts looping and, at least in theory, a lot of asteroid position updating is going on. I'm taking a stab at lowering the amount of asteroids that can be viewed before continuing on my merry tutorial way. Maybe it'll work. Maybe not. I'm just guessing.

Tomorrow I get to the video explaining how to blow up asteroids. I'm looking forward to that one.

Permalink game dev programming/interweb