Tag Archives: Rapid Game Development

Nightcap Update

For the past couple of weeks during the wee early morning hours before the kiddos wake, I have working on my latest pet-project, “Nightcap“. I thought that the program was mostly done. I should know by now to be more cautious of this mindset. I had been running Nightcap on my two Windows 8 PCs for months now without much ado, but when I took a closer look at the code base, I knew a couple of things needed changing before the much anticipated product release. My main concern was with the event-based approach that I used to detect keyboard and mouse activity. At first it appeared to work well, but during testing on our home PCs, my little beta testers (Thing 1 and Thing 2) noticed that their computers fell asleep while playing games. Clearly there was a lot of activity happening, but for some reason Nightcap had stopped noticing.

It turns out that Windows 8 was secretly unhooking my event monitors and replacing them with Folgers Crystals

Well not actually that, but it might as well have. The net effect was that my app could no longer sense anything about the computer and that was kind of the whole point of Nightcap. Why did Windows have it in for my app? Perhaps Windows had deemed Nightcap a poor citizen of the OS? I did a little research and learned that in recent years Microsoft had discouraged event monitoring for programs like Nightcap for good reason. These event-hooking hogs can really slow a computer down. Microsoft recommends using Raw Input instead of events hooks because it doesn’t hamper system processes and provides a more efficient way to delivery device messages. Reading over the documentation, I could see that this approach was radically different than event hooking. Being so close to completing my app, I was desperate to find a quick-fix. Clearly, I wasn’t the first person to write an app that used event monitoring. I wasn’t thrilled about reworking the core of my app when it was 99% there. After a quick search, I learned about a workaround where you can fudge a registry setting to set the bar so low that no process, however laggy, would ever be unhooked. The “fix” worked, but the hack never sat well with me. I had sort of forgot about that workaround while I was in the final push to get Nightcap up on my website. Without this hack, I imagined thousands of computers inadvertently falling to sleep while folks were playing games or composing emails. Bottom line, this was no way to release Nightcap.

Which brings me to last week… I did some more research and decided that Raw Input processing was definitely the way to go even if I had to rewrite Nightcap. Unfortunately, the API was written for C++ and if I were to use it in my C# app, I would have to come up with a way to integrate the unmanaged code. Being new to C#, that was a learning process in itself, but I stuck with it and got the raw input code to work within Nightcap. However, after some initial testing, I noticed Nightcap had stopped responding to click events. Somehow the WM_INPUT handling was interfering with the normal event processing. After a few days of trying out various C++/C# incarnations without much luck, a new plan started to emerge. I thought,

“What if I separate out the event processing part of my app from the reporting and configuration piece?”


Eureka! I can write the input event monitoring as a Window Service and leave the C# app as-is. Only now, the visual aspect of Nightcap would interact with the behind scenes service to tell it under which circumstances to put the computer to sleep. The nice part about this approach is that the monitoring part of the program will be active even when no one is logged in. This comes in handy if your PC wakes up in the middle of the night because of LAN activity.

My blog has been neglected for the past couple of weeks, so I felt an update was in order. I hope to have a beta version of Nightcap on my website by May. As a side note, I really enjoy working with Microsoft tools once again. Visual Studio 13 is fun to work with and in my experience is the best programmer’s workbench in the industry. Debugging code is so well done and I really like how git has been integrated into the IDE. Nice work!

Well, I am getting back to it now. 


RGD: Week in Review

I somehow managed to finish a game this week. Now, I am not all that proud of the game, but my son thinks it’s cool, so I am going with that. The game is called “Grape Boy” and  its premise is pretty simple: You play Grape Boy, a character who catches grapes in his mouth. The more grapes you catch, the higher your score. If a grape hits the ground, Grape Boy loses a life.


When I started the week, I had all kinds of “fantastic” game ideas but as time went on and I worked through my lofty game designs, I could see that I needed to simplify. Thus Grape Boy was born.

Panic set in around Monday evening. It just didn’t seem possible that I was going to complete a full game in a week using traditional programming techniques. I needed a plan B if I was going to make good on my commitment. That’s when I gave Construct 2 a go. I briefly experimented with the game construction kit about two years ago and thought it would be easy to pick up (maybe wished would be a better description). Through the years, I’ve learned that with software development there is always something to fight. There is no such thing as painless development. Frustration is a constant. The folks at Scirra have done a fantastic job of making a very powerful and “easy” to use game kit. If you don’t have a programming background I suspect using Construct 2 is the easiest way to go. For me, it was a different story. I had to restrain my desire to write code and figure out how to accomplish the task using events sheets and layouts. Having a full time job didn’t make it any easier, but I couldn’t let lame excuses get in the way of my goal. I had hoped that my focus on fun would somehow make everything go smoother… No, fun as game development was, there were a lot of hours of “Why doesn’t that just work like in the example?” or “I can’t believe it’s so hard to do this simple thing” and a few hushed expletives as well. I spent most of the week just learning how the game tool worked, but I felt confident that if I stuck with it, Construct 2 would pay off in the end. Grape Boy doesn’t have all the features that I would have liked, but it is a complete game and that was my goal. I wished it had sound and more play elements, but I ran out of time and decided it was better to post a little game than no game at all. I am proud that I was able to add a high scores feature. Now you can try to best my high score. I love a good competition! 

The whole experiment had unexpected rewards for me too. My son caught the game development bug and started writing a game of his own. He is working on his latest masterpiece as I write this post. Thing 1 is a natural gamer and is amazingly talented. One minute I look over at his monitor and he is playing Supreme Commander and the next I see him polishing off an amazing looking space game. All without asking me a single question. I am in awe of his creativity and imagination. I can’t wait to see what he will create next. In the near future, I will be posting his latest creations to AdventuresInPlay.com/games.

Well, this week I plan to take a break from game development to finish off my taxes and take care of my to-do list.



RGD: Day 1 Report

OK, it’s Tuesday and I need a change of plans! I had a case of the Munday’s yesterday, so not too much to report on the game front. I did however get an email from Gamasutra informing me about a great deal at Yoyo Games where you can get a copy of Game Maker Standard edition for FREE until March 2, 2014.  I downloaded and installed Game Maker just to try it out. The really neat thing about Game Maker is that you can write games for Mac or Windows without a single line of code. After trying it out for an hour, I could see some real potential in Game Maker for my rapid game development projects. However, I feel the time pressure to get something done for Sunday, so I don’t want to spend too much time learning a new game development environment. That’s when I remembered another great tool for quickly creating games called, Construct 2 by Scirra. With Construct 2 you can create non-commercial game for free for multiple platforms. The really great thing about Construct 2 is that your game came be played on almost any platform without an installation. The free-edition does have some limitations, like limited program events and limited platform support but overall this is a great tool for my gaming projects. There is a learning curve to using Construct 2 as well, but I did some of the tutorials a couple of years ago, so I think I can get a game up and running without too much fuss. So, I’ve decided that my first gaming project won’t just be playable on Macs, you’ll be able to run my game from Adventures in Play without any installation on your computer. 

Now, I need to get back to it and finalize my game concept, but first I have to go to work. I’ll report back tomorrow with some screenshots of my initial game ideas.


Rapid Game Prototyping

Experiments from the Blogatory

This week I’ve decided to try something a little different.  So far, I’ve written career posts and whined a bit about my PCs and that has been great fun, but when I created Adventures in Play, I wanted to create a segment that focused on fun stuff that I like to do in my spare time. The problem for me, is that like many, I don’t have a lot of spare time and lately I have been exercising a lot of down-time watching the Olympics and Netflix (I discovered Farscape this week) shows. Mind you, watching the Olympics has been a lot of fun and to be honest, I am going to miss watching those athletes do their thing. It inspires me to be superfocused on my goals. Speaking of being super-focused, have you heard of rapid game development? Back in 2005 I read the now classic article “How to Prototype a Game in Under 7 Days” (still a terrific treatment on the subject). I’ve always meant to run my own game prototyping sprint to hone my game development skills, but I’ve never really had the time or frankly, discipline to commit to a crazy development schedule. Some of the recent articles I’ve read on rapid prototyping have gone to greater extremes, writing a game in one weekend or 30 games in 30 days. I guess it’s a matter of preference, but I do have a day job and would like to spend time with my family.  So, my revised plan is to focus on the fun and return to the original goal of one prototype in 7 days. My focus for this experiment is to have fun while writing a simple game for the Mac. Really, what do I have to do in February besides get my taxes done early and wait for winter to end?

Experiment #1: Creating a game in 7 days


 My Rapid Game Prototype Commitment:Spritekit

  1. Write a simple, yet complete game in one week.Spritekit
  2. Create a game for the Mac using the SpriteKit framework.
  3. Have fun!!! Although I am genuinely interested in becoming a better game developer, my motivation for this experiment is pure whimsical fun.
  4. My kiddos (Thing 1 and Thing 2) will judge my game at the end of the week giving my game a fun-factor score.
  5. Make my game available to the public for general enjoyment!

I plan to give daily updates on my progress, so check back here tomorrow or follow me on Twitter (@runstop) to see how I am doing.