015. ONE GAME A MONTH (DEV LOG #11, FINAL)

Woot!!!!!

The game is finished; I limped through the finish line, but it’s done. And I’m proud of the execution of the idea, and I really learned a lot on this project. You can find my project and all the source code in the Dropbox link below.

Enjoy, and let me know what you think of it. I’ll do a full post-mortem of this tomorrow.

Link to “Ludovico Clouds”

Ludovico Clouds - Gameplay

Weird image splicing won’t be apart of the game lol

Ludovico Clouds - Main MenuLudovico Clouds - Tutorial

012. ONE GAME A MONTH (DEV LOG #8)

I brushed up on timelines when working on the tutorial that will be in my game. Timelines are simple once you understand the big picture.

WTF are steps?

In GameMaker, we have this concept of “steps” (others might call them ticks or updates). A step is the smallest unit of time that your game is using. All of your code in your “step” events will run during each step.

How many steps can you have? You decide. Games that are 60 fps have 60 steps every second. The more steps you have, the smoother everything should run (in theory).

Steps and Timelines; what’s the deal?

So we know how to drag and drop code into the Step. This code will be called every step of the game (if your game is at 30 fps, the code in your Step event will run 30 times a second). It’s not very flexible; what if I have an enemy that I want to start walking when the game is at 69 (hehe) steps? You could set up a timer to count up the amount of steps that went by, but this gets complicated when you want to create complex events. This is where Timelines come in.

Credits to Adele

Credits to Adele

A Timeline is like the status bar that shows your time remaining in iTunes. Let’s say you wanted your character to start moving left at the 10 step mark, you would go to the 10 step mark and add the code there. If you wanted the character to start moving down at the 30 step mark, add the code at the 30 step mark. When you’re done creating all of the events, you can hit play (run your Timeline) and admire your character moving all over the place, just as you planned it.

In my tutorial, the player walks into the room, and text pops up showing you how to move him. Then the cloud character comes into the window and more text comes up, telling you how you can move him. Lastly, an enemy comes and you are shown how to kill him. There are pauses in between each of these events (which Timeline does perfectly), and the results are exactly as I wanted it.

These are the main timeline variables that you will need.

  1. timeline_index             – this is the timeline that you will be working with. Set it to the name of the timeline that you have created in GameMaker (or if you’re a bad ass that created their own dynamic timeline. Good job, showoff.)
  2. timeline_running         – when you want your timeline to actually play, set this variable to true
  3. timeline_loop              – if you want your timeline to repeat, set this to true. You might need this if you have an enemy that patrols. The enemy can start walking left, then at 60 steps, start walking down, then start walking right at 120 steps, and up at 180 steps. Set “timeline_loop” equal to true to have the enemy patrol forever

Timelines are a strong feature of GameMaker. Take advantage of it, rather than using long-winded if-statements and alarms. Work smart, not hard.

011. ONE GAME A MONTH (DEV LOG #7)

I had a semi-day off today. My friend invited me to a hiking trip, and I hesitantly said yes; but I’m glad I did though as the whole trip was quite relaxing. I hiked up Breakneck Ridge in New York and walked to Cold Spring, a quaint village with a couple of tiny antique stores and not much else (sorry if I offended anyone). I also caught up with old buds and met new folks.

Once I got back home, I programmed a functioning menu, that works with Keyboard inputs, Mouse clicks, and gamepad control. I put in “working code” to get everything working and bug free. That got me thinking if I should look back through my code and rewrite things more elegantly. Were there variable names that could’ve been more expressive? Are there optimizations in the code that I missed? I always wanted to be the type of programmer that wrote elegant code. But now that I’m facing a deadline, and writing code that I most likely will never look at again, I decided that reviewing my code after testing and debugging it made no sense. Sometimes, you just gotta be a programmer that gets shit done, programs, tests, comment the hell out of it, and pray you don’t have to look at it again. And hopefully as I learn more and more, all of my “get shit done” code improves and uses elegant solutions to new problems.

008. One Game A Month (Dev Log #4)

Another long day at work, and then I came back home and baked cookies.

I did animations for my player standing and player walking and was pretty happy with it…for a first attempt. I won’t be a perfectionist with this; I’m getting used to using Synfig and creating keyframes and playing with my drawings as if they were clay. With the walking animation, I adjusted the rotation of the body parts to give them movement, and then increased the scale of the body parts to make them seem like it’s coming towards you.

I spent more time on the cookies than I did on my game today, so I might as well show both off. Let’s try not to let this happen again tomorrow. The end of the month is fast approaching, but I’m optimistic about finishing everything up.

Player walking…or dancing

007. One Game A Month (Dev Log #3)

I did a bulk of the gameplay programming today. Here’s what I did:

1. Finite State Systems (FSS) for Basic Enemy AI The enemy will roam around and chase the player when they’re within range. FSS are super helpful when you find yourself using large nested “if” statements in your code to check for various characteristics of your character (is he holding a gun? is he in the air and holding a gun? is he crouching and holding a gun?).

In lieu of nested “if” statements, use a variable for your object called “state.” As the user pushes a button (i.e. to shoot a gun), the player’s state becomes a “shooting” state. Then all code relating to the player shooting guns will be neatly encapsulated and you’ll have easier-to-read, neater, and less error prone code.

2. Added in player and enemy damage

3. Player and clouds can’t go off the screen

Tomorrow, I’ll be working on the rest of the character animations…well, technically I have no animations yet. Just a bunch of Inkscape files and Synfig files with no keyframes…haha ha ha…

This article was a godsend for me; read ALL the articles here! “Finite State Machines” – Bob Nystrom

005. One Game A Month (Dev Log #1)

I’m already at crunch time for this game of the month. My day job kept me busy…and I just got lazy. Now I have a week left to get this game in and I’m excited for this challenge. Some people work great under time pressure and I’m one of them.

I go into every project wanting to learn something new. I don’t want to keep pumping out the same game dressed up with different art assets. For this month’s project, I’m going to work on art animation (no more squares for my hero avatar) and custom camera movement.

My game is inspired by a mechanic in the game, The Binding of Isaac, called the Ludovico Technique. The player moves their weapon with one hand, and moves the character using their other hand. This forces the player to have their eyes focused on two places at once.

My game is going to feature a boy who befriends a cloud. You walk around avoiding enemies (undecided on what these should be) and attacking them with your cloud buddy. I’m programming the player/cloud movement and adding Xbox controller support with a dynamic camera camera (thanks Shaun Spalding!). Tomorrow, I’m going to get the artwork going and hopefully have something to show for it.

Link: Shaun Spalding, Youtube

One day, my games will have no squares in them at all.

One day, my games will have no squares in them at all.