atomic monster

Wrapping up the last few images for the wireframe I hit the stride I should have had all along.  Even though the last 5 rooms were by far the hardest to block in there was a different feeling to the process of getting them up to speed.  While they were the hardest to get my self motivated to complete they were actually the easiest to complete.  Props and details will come as the gameplay gets solidified. The first quarter of the rooms felt really new and fresh so I kind of approached them as a standalone illustration and could easily blow 30-40 minutes on one.  By the time I got to the last 10% I was so worn out creatively that I just wanted them done so I would slap them together as fast as possible to convey the initial thinking. That really is the way that I should have approached all of them from the very start.  When you spend even 30-40 minutes on something like this you do tend to get a little attached.  That makes it so much harder to look at the room in the context of

This is another old game concept image I did years ago.  This one still has some charm to it for me.  I don't know if its from the mix of pixel characters against a soft background or if its because seeing this takes me right back to wondering what the game would feel like to play.

All the rooms have been wired up together for a few days and you really do start to get a sense of place.  Even more so when the room thumbnails get updated to a first pass on the vector block out. At first I thought that 29 rooms would not be a ton of space for the game and that does feel some what true right now with nothing to do but move from room to room.  BUT I am starting to feel the art burn taking 29 rooms from super vague thumbnails to even fairly simple and empty feeling vector art block outs. I am looking forward to getting more time to do the art for the rooms but even getting them all to a basic level is taking a while.  I'm 23 in and only have 5 to go which is really good but at this point those last five feel like the first 23.  However I push on and with each new block out I get more excited to finish. 

Documenting your work is always a little boring and I'm really bad at it.  Regardless of the zombie like state of bordumb it puts me in I sat down last weekend and put a very basic manual together. Right after I wrapped it up I ended up adding a few new things and tweaked a few others in my engine.  And so begins the dance of documentation updating. I'm pretty stoked actually to have some documentation inplace for the engine and it's data structure.  The number of things in the engine has grown and there is a great deal that I had finished and not worked on that I had started to forget some of the details.  The manual sits at 98 pages right now which I'm kind of proud of as I have never written anything more then 20 pages.

I took some time last night and put together two templates for sketching out the rooms for the game.  One is a detailed page that I think I will use when working out more detailed ideas.  The other one is a page with 16 thumbnail screens with some room for a few notes. After I had a few sheets of the templates printed out I cracked open my sketchbook and did a mind map of locations.  I found this much easier doing it by hand instead of on the computer.  Another upside I had not thought about but now appreciate is that when doing this you are naming locations first.  This made it much easier for the next step. After I had a decent sized mind map of 29 rooms I figured I should do some quick and dirty thumbnails.  This was harder to get into at first and I found I had to come back to it the next day.  When I did come back to it everything came together really quickly.  There are some ugly thumbnails that are just a mess but it is enough for a first pass wireframe. they ain't p

As we head into the wire-framing section for the game there are some areas of the data structure that I feel are a little bit bloated and kind of sloppy.  I am happy with 99% of the structure but there are still some things that I keep thinking about that I would love to add and re-organize. One of the things that I would love to build out to be more powerful is the animation system.  Currently it is just a list of images and you cycle through them like a flip book.  But it would be much more powerful to be able to have multiple images with their own positions stored as frames.  We could even expand it out to trigger logic if we really wanted to but that is like feature creep on top of feature creep.  Changing the animation to work in this manner would not be very hard.  The part that I am mulling over right now is if I want to break the idea of splitting this up to multiple objects.  So one object that can use flip book animation and the other could use complex animation.  I can th

So I finally got around to something that I had been putting off for awhile now and that is the concept of verbs for my game engine.  I came across the old SCUMM training manual that used to be used by Lucas Arts to train up their new adventure game programmers.  Reading through it I came across a section talking about implementing new verbs.  This really interested me as I have played all of the old classic SCUMM adventure games and know a fair amount of how SCUMM worked.   The coolest thing about the verbs in SCUMM was that they could be custom built for each game.  This is very noticeable if you look at Loom compared to any of the other games.  The core of my current engine that I am calling SWINE is really similar to SCUMM in a lot of ways and mulling over the idea of custom built verbs as the main interface and I finally landed on a decent solution with my approach. So I got the first pass of my concept of a verb interface integrated into the data format, updated the logic

Over the weekend I expanded upon the logic processing or my game engine.  Originally it would process all of the logic for the current room (a level essentially), actors in the current room and any logic scripts held in a global list.  When a new room is entered all logic not contained in the global list is dumped and the new room and actor logic is run. There are functions to load and stop global logic so if I needed to kick off logic that would process across multiple rooms that is very easy to do.  But I hit an issue putting together a new room that needed to have more complex logic that was executed only in that room. I could make a script that is run globally but I would need to make sure to kill it when the player exits the room.  This is not a problem but it does leave plenty of room for error if you forget to kill it when the room exits. Introducing "local logic" all the flexibility of "global logic" but with out the need to clean up.  The local l

This video is amazing and I can't recommend it enough to anyone that is writing code.  Hearing this stuff from someone like Mike Acton should really echo the importance of what he is talking about.  The core ideas he shares here can be applied to EVERYTHING including art and design.  Do your self a favor and really watch this video preferably multiple times to really drive the ideas home.

It feels like I have added a new feature to my game engine almost every night this week.  These are some important features that have been added too such as halting user input and turning it back on, drawing images and animations without being linked to objects and just a few moments ago I finished adding custom cursors. It's interesting to see how many new things have been added to the engine and hence the data structure I originally designed.  Each new feature was first added to the data structure first.  Doing this always seems to get me thinking about how the feature is going to be access and what it should actually store. An example of this was the cursor.  At first I just thought I would need to point to an image and that would be that.  But when thinking more about it realized that the most common case would be changing the cursor to different images and some of the different images would need offsets.  So I put together a dimple dictionary of cursors with each cursor

In the last post I talked about how thanks to the data first design idea how easy it was to add in "on_enter" and "on_exit" logic when the player enters and exits a room.  Well after I posted that a situation came up where I really wanted to turn off the players input while a bit of logic ran and then turn it back on when it was done. Again this entirely new feature was implemented in a couple of minutes.  To do this I added in a simple bool variable called "player_input" at the root of my data format.  Then I added two new functions to my "system" functions called called "input_on" and "input_off" where I set the "player_input" to either True or False. Next I added the "player_input" variable to my if statements where I check for input.  There are only 9 spots I check for input 3 for rooms, 3 for actors and 3 for objects.  The inputs there are normal "mouse_down", "mouse_over" and &

Over the weekend I was doing some work on the game for my son and ran into a situation where I needed to have an object start hidden from the player.  In the current pipeline with Inkscape I use python and the command line arguments to export out all of the pieces that I need.  This has been awesome for iteration and adding new things to rooms.   The rub is that the object needs to be visible in the SVG file when it exports otherwise it exports and empty png image. There are some ways I could get around it in the pipeline but I wanted a much more useful solution.  I opted for putting in two new functions to my logic "on_enter" and "on_exit".  Then added the execution code right before and after the main logic processing code. On_Enter is run when a new room is entered.  I already track the current room and the last room so the logic triggers were already there now I just loop over all the logic attached to that node and I'm done.  I do the same on the

Damn I miss Hypercard.  I have such fond memories playing around with it before school in Junior High.  Hypercard was not only the first program that ever learned to do some basic, and I mean basic code in but it is also the first application that I ever used to draw in. When my family finally got a PC at home we got an IBM PC with DOS and Windows 3.1 so I never got to play with Hypercard anywhere else except the school computer library.  Even though that was the case I never forgot about it.  Once I got older I started to dig around about it more only to find out that I was hardly even scratching the surface of what you could do in Hypercard.  People made games, which is what I did but they also made their own software or education tools. Steve Jobs has been quoted as saying that the computer is the bicycle for the mind.  I think that is 100% true and I would dare say that Hypercard turned your bicycle into a custom built motorcycle.

Ron Gilbert and the old school Lucas Arts guys are amazing.  It is so wonderful to learn about how they did stuff.

I finally got a microphone and keyboard.  I don't sing or play the keyboard so it has taken me years to finally breakdown and get them.  Since I am working on a game with my son and I thought he would love it to hear himself and I in the game.  The keyboard I really wanted because I get tired of trying to find simple free music to use in my projects.  Added bonus both my kids love to sing and play with toy instruments so now I can better capture those moments.

Tools are probably one of my favorite things to code.  Tools and pipeline scripts often do not get the attention they fully deserve or worst yet they get skipped over completely because the task seems so small to waste code on.  Most commonly what happens is that tools start to get designed and built as soon as a project starts.  The problem there is that tools are meant to simplify and improve workflow but there is no way you can actually know your problems before you are fully sure of what you are making and what the actual problems might be.  Sure you can always give it your best guess and try and have the tools solve problems you think you might run into or to build the workflow that you assume might be best.  The reality is that it is better to grow your tools in the beginning by keeping them small and simple.  This way they can grow and change as your project grows and changes and adapt to actual production workflows.  This keeps your tools light and super affective at their

I need to do more of these kinds of drawings.  They are always a lot of fun to do and as a bonus I can save out each of the objects to us for any kind of prototyping I might want to do.  This one was done in painter a long time ago.  These days I use Inkscape but the idea is the same.

Over the weekend I started making a game for my son.  He is 5 and loves everything Mickey Mouse or Disney.  He also really likes adventure games.  Over the holiday break he and I finished Thimbleweed Park the latest game from Ron Gilbert and Gary Winick. So he is basically designing and telling me what to put into the game which is super fun because I get to spend some good quality time with him and I also get to stress test my little game engine project in some creative ways instead of my normal I just wrote this let me test it kind of way.  Now I get to actually try and make it work in ways I have not thought about yet.  Like just yesterday he put together some stuff that required me to finally put in hotspots into the rooms.  I had been meaning to do it regardless but now I finally had a reason to, I had to use them to make his game. He is designing the game by making drawings of rooms he wants me to make and I then take his sketch and do a quick and dirty vector art version

Last post I talked about a project I started using the approach of designing the data first.  It is my current pet project and one that I will keep exploring and playing with because it is so much fun.  So here are some snippets of code the show the structure of my data and some of its values. One thing you might have noticed is that I am using the JSON data structure.  JSON is a great format and pretty much every language already has a JSON parsing library so it really let me focus on the design of the data and how each piece would reference/connect to other bits of data.  Just like code you spend a good chunk of time very early on iterating your data design.  My first attempt I found that I was nesting things way more then I really needed.  Since there was no code at this point it was super easy to just move things to new sections and make large sweeping changes until everything started to make logical sense for what I wish to accomplish.  As the data structure started to grow

Data first design is an interesting subject.  My favorite video I have seen on the subject is the below talk by Mark Bastian.  The thing about his talk that I enjoyed the most is that he actually uses a game as his example explaining the topic. I took the concepts from this talk and explored this approach for a few weeks and I found some very awesome things.  In the near future I would like to share out some of the things that I have found and show some progress the project I have started up using this kind of approach.  One thing that I will say right now is that it is really fun to design a game and its logic without actually writing any code.

Whenever I am given the option to choose a difficulty in new games I tend to choose "easy".  The reason I tend to do this is that the majority of the time the game is absolutely no different except you tend to do more damage while the bad guys tend to do less.  It really bothers me when games do this and ruins the entire point of a difficulty selection.  However there are games out there that use the difficulty selection as actual game play.  My favorite examples of this are Wolfenstein 3D and Doom.   When you picked a difficulty setting it would either add or remove enemies to maps.  So the designer was designing the experience.  These gave way to awesome gameplay experiences and replay ability.  Maybe on one difficulty setting you could run right through a room but on the next difficulty setting maybe there were two or three bad guys in the room ready to ambush you.  Plus the enemies actual difficulty was still the same you were just dealing with more difficult sit

Now there is no promises that 2018 will globally be any better than 2017 and I am not holding my breath for any kind of change from the douchebags that run this country to change.  So why the hell do I feel so good about starting a new year?  It really comes down a quote from Hitchhiker's Guide to the Galaxy "I'd far rather be happy than right any day."  I love that line. What that line means to me is not the idea of giving up on fact since it is a fact that facts are facts.  Instead, as it relates to my hobbies and professional work.  Now I have been in the game industry professionally since 2000 so I have about 18 years as a professional artist and even more as a hobbyist game developer.   During that time I have thrown myself into learning everything I can about game development, programming, design, art and audio... not nearly enough audio though.  I have been a quite lurker on development forums and consumer of youtube videos showing the "right"