2018 - March  |  2018 - February  |  2018 - January  |  2017 - December  |  Work Log
2017.12.28 - Thursday
A Video
I gave the player an inventory, let the player pick up guns, and added some sounds. Here is a video of that in action...
2017.12.26 - Tuesday
Technical Design
Guns guns guns! I spent the day working on weapons! I worked on attaching items to an actor, spawning items, drawing items on the ground, and general world item management. In the video below, you'll notice the Jade Rabbit littering the ground.

Tomorrow, I'll work on item pick ups and hopefully weapon firing.
2017.12.25 - Monday

Merry Christmas from GlitchRock Games!

2017.12.24 - Sunday
Technical Updates
I've finished the first version of the Controller Debug display, which allows you to seen when a button is presed on the gamepad. I'm still fleshing out the input component, which I've hooked up to the player component to an early version of movement going.

The more general engine work has been focused on understanding and implementing a dependcy inject based design. I've been reading a lot about it, here are some links... Now is a good time to go back to my list of Prototype Goals and cross off the ones we've completed. I will complete this list this week.
2017.12.21 - Thursday
General Updates
After two scheduled days off, I'm back! I'm on my second listen of Blood, Sweat, and Pixels. If you have any interest in game development, I highly recommend this (audio)book. Maybe I can be in the sequel?

In Blood, Sweat, and Pixels, Jason Schreier takes listeners on a fascinating odyssey behind the scenes of video game development, where the creator may be a team of 600 overworked underdogs or a solitary geek genius. Exploring the artistic challenges, technical impossibilities, marketplace demands, and Donkey Kong-size monkey wrenches thrown into the works by corporate, Blood, Sweat, and Pixels reveals how bringing any game to completion is more than Sisyphean - it's nothing short of miraculous.

I made a little object factory demo. I'm still not really sure this is right, but it seems to work as it should. Check it out.
2017.12.18 - Monday
Technical Design
I did a little work today on an item factory. When I need to spawn a piece of gear, I'd like to be able to do something like: GearFactory.RandomItem(player class) to get a random item for the player's class. Then say I need to drop a guaranteed legendary; GearFactory.RandomItem(playerClass, GearTier.Legendary). So that's in my notes for later....

So what does the tiering system for my gear look like? A lot of games use the a common, rare, legendary system. Some have higher tiers like ancient or mythic. Others have lower tiers like ordinary or normal. Some questions;
To be continued...
2017.12.17 - Sunday
Technical Design
I worked mostly on sorting out the initial component interfaces that I talked about yesterday. Towards the end of the day I made a short recording of the prototype playing a sound and displaying a pressed button. We makin' all kinds 'a games.

2017.12.16 - Saturday
Part One
Today, I'm working on the Input component. I need to track previous state, current state, and allow for comparison between the two. The way the game pad works, is that a button us pressed, or it isn't. There are no events for 'button pressed' or 'button released', so you need to compare the current state of the button to the previous state. I hooked that up, then tied the A button to a new SoundEffects class, and now the protoype plays a sound when you press the A button.

Part Two
I tried to be as hip as possible and went to a coffee shop to finish designing the base component system. I drank a big coffee, wrote in my notebook, and stared thoughfully out the window for about an hour. I want to get the component system as right as possible so it doesn't cause me pain later on. I'm also trying to stick to edict #6 by coding what I need, and avoiding the urge to look ahead to every scenario that may pop up. There's a balance there between too much and not enough. I'm still trying to find it.

Part Three
Once I started messing with the controller input, I realized I was going to need some kind of debug display to show controller button states. I drew a couple drafts and came up with something I kind of like, then found a nice controller button sprite sheet, and started working on the new DebugController class. Here is the sketch I'm working from. The outside rectangles at the top are the triggers and the inside ones are the shoulder buttons. The three circles in the bottom middle are the View, Xbox, and Menu buttons.
2017.12.15 - Friday
Today is a scheduled off day for Element work, but I wanted mention that I'm bouncing around some names for the game. I haven't thought of any good ones! I really don't even like the code name 'Element,' so I'm going to change that eventually. Also, this site has moved to nvn.io and has been redesigned.
2017.12.14 - Thursday
Game Design
One new edict: Breadth, then depth.
Basically, avoid getting stuck in paralysis analysis hell. I'm going to make a concerted effort to make things work only as much as I need them to. Once a component is established and has gone beyond the design stage, I can start implementing new features. Don't wax your car if it hasn't been put together yet!

Technical Design
I was pumped up to start coding today. The little breakthrough I had last night helped boost my hype levels way up, so I started working on an input component, which brought the hype back down to earth. This component will allow the game to read button presses, trigger pulls, stick moves, etc, from the gamepad, as well as determine if states have changed since the last Update() tick. Playing around with input brought about the need to draw some text on the screen, so I began on the Debug component too. Today is the first (of what I'm sure will be many) days where I will be shutting down with a project that fails to build.

I've been spending a lot of time reading about game design, here are some of the things I read today, number three will bring tears to your eyes!
2017.12.13 - Wednesday
Game Design
I gave the weekly state of the game presentation to my supporter.

Technical Design
There is a great post on stackoverflow about general game architecture that I came across today. It helped me understand how game objects are tracked and made me think about interfaces as they relate to games, and how I should be using them. It was a bit of an 'Aha!' moment for me. There are a lot of things I'm not sure how I'm going to do, this article helped me get a little closer to checking one of those things off the list. I wanted to see a little more info about the guy that made the post, so I checked his profile to find out that he is the Lead Engine Developer for River City Ransom: Underground.
2017.12.12 - Tuesday
Game Design
I drew a mockup of the DPS tester, storyboard pane #7, and took a bunch of notes on how it will function.

Technical Design
I extracted a couple of classes from the Player() object to make them usable for other characters. It doesn't seem like much in writing, but it ended up being a fair amount of code.
2017.12.11 - Monday
Game Design Technical Design
I did more work on the prototype, specifically on animated sprites, adding a feature that allows sprite animations to play out of order frames from the sprite sheet.
2017.12.10 - Sunday
I installed the monogame tools and intend to use them to build a prototype. I want the prototype to have:
For the prototype, I'm using sprite resources from Kenney Assets.

I also added a couple of design edicts to the list (see top of page).
Project Ever Design Edicts (draft)
  1. Figure out what FUN is and make it rewarding.
  2. Make the FUN competitive, and let people compete.
  3. No fetch quests. These are not FUN.
  4. Have lots of guns, really hundreds.
  5. Drop loot from the enemy that awards it.
  6. Breadth, then depth. Iterate to add depth.
  7. Loot must change gameplay, must be interesting.