018. Quitting Public Accounting

Yesterday, I finally quit my job in public accounting. It’s one of the biggest risks that I’ve taken. Instead, I’m going to dedicate myself full-time to starting a career in the computer programming industry.

There were too many days where I woke up and dreaded going to work. The work was boring and pointless. I had gotten into the Tax field thinking that I could find a job that I found bearable, and follow the American dream of making 6 figures, getting married, getting a mortgage and having kids.

But fuck this shit! I definitely can’t be mindlessly preparing tax returns for the rest of my life. I haven’t found many posts that talk about people’s thought processes while quitting their comfortable accounting jobs and pursuing their passions. I’ll be updating this with my own insights and all the details that you might be worried about.

Good luck to all my CPA’s out there.

017. Next Project – Tug of Tetris

I took a short break from programming and basked in the glory of my finished game. But now, it’s time to work on my next little project. My sister loves playing Tetris, and I’m going through a phase where I want to develop local multiplayer games. So naturally, my next project is going to be multiplayer Tetris.

The point of the game is simple. Each player will be playing their own personal games of Tetris simultaneously. They will each be represented by avatars on the top of the screen who are playing tug-of-war. With every line you break, your avatar will pull the rope closer to them. Simple enough!

I haven’t thought of all the power-ups and items that might come into play, but I’m excited to work on a game that I think the general public would play and appreciate! I’ll start keeping a more detailed dev log of everything I do; especially all of the ugly problems and issues I see. I don’t think there are enough blogs about the underbelly of game development.

016. Post Mortem of “Ludovico Clouds”

So now I want to look back at everything that happened on this game. What did I learn? What could I have done better? Let’s go!

Don’t judge a book by its cover, unless you’re going to be staring at said cover the whole time.

The first couple of projects I worked on, I quickly lost interest and was looking ahead to the next project. Usually, this happened as soon as I finished creating a working prototype, sans art, of the game mechanics. After that was done, it was a chore for me to add the rest of the game. Game menus, GUI, art, etc. were all shitty, because that’s the amount of attention I gave them (none). Don’t do this!

Develop your art at the same time as your audio and gameplay mechanics. For some, programming might be the hardest part of game development so they dive right into it. But all aspects of your game work off of one another. 

Another important aspect is that it just provides you more motivation. If I had to spend my entire game development time staring at moving squares, my interest would quickly wane. Learn simple art and animation programs like (free) Inkscape and (free) Synfig. I used these for the first time in my game, and although it’s not going to win any awards, I love the art style I created. I adore all of the little details, like the beating hearts in the GUI, or the bouncing buttons in the Main Menu. Debugging my game was less of a chore when I had something pretty to look at. 

Build your game like a staircase, and plan out every step.

A carpenter wouldn’t start building a house and just “wing” it. And neither should you. A carpenter meticulously plans out everything that he’s going to do. With your projects, make sure you do the same thing. Don’t go into your project with only a vague idea of what it’ll look like. Start drawing it on paper; start thinking about what it would feel like playing it. What physical buttons are you going to be using? What does the GUI look like? How much of your design can you strip down? Take a full day and write everything down.

When you start working on the game, you wanna cross things off and see that you’re making progress. With me, things popped up that I didn’t think I would need, which would’ve changed if I just put some thought into it. Because of that, my to-do list never got smaller. You lose motivation. 

And with your first couple of projects, motivation is one of the most important things you’ll need to become a game developer.

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”

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

014. ONE GAME A MONTH (DEV LOG #10)

On a road trip to Philly. I’ll be back home in New York tonight. I brought my laptop and fixed up a small bug I had with my animation, and did some work on the timing of the tutorial. Other than that, a rest day from programming. I’ll finish everything (hopefully) and have a link posted to my completed game tonight. 

013. ONE GAME A MONTH (DEV LOG #9)

omg…so sexy.

There was an event at work today. Free drinks and free food. Need I say more?

And in my inebriated state, I managed to wobble all the way home and get some shit done. Working on this game, piece by piece, used to be something I found to be miserable. The slow progress, and seeing the same thing over and over again was demotivating. But the fact that I’m using new tools (Inkscape and Synfig) to create different dimensions for my game (art and animations) made it enjoyable again.

For those of you just beginning to program, learn as much as you can about the language. But don’t be one dimensional! Learn how to draw something; learn how to animate; make music; design levels! Seeing your game come to life is amazing; so stop fucking drawing squares!

I got some tutorial animations done, and…then I managed to almost delete my entire game project. There’s a glitch where, when I accidentally set my animation length in the sprite editor of GameMaker to a ridiculously large number (such as 20,000), the game freaks out. What happened this time was that, GameMaker froze and said it had a memory leak, and then when I reopened it, all of my rooms and objects were missing from the in-program folders 😦

Luckily the objects and rooms were saved elsewhere in GameMaker’s automatically generated folders and were unscathed. All I had to do was reimport them. But it was scary as hell seeing all the work you did for the past week…gone. Should I consider using some version control like github? Or maybe I should just email a version of my project once a day? I think I’ll try learning that for my next project. I’m going on a road trip tomorrow; the end of the month is fast approaching, but so is the end of this game.

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

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.

010. ONE GAME A MONTH (DEV LOG #6)

Ladies and gentlemen, we have a somewhat decent playing piece of shit art.

I got my animations into GameMaker, and it actually wasn’t that bad. I wish I had spent more time on the animations themselves; but for the amount of time that I did put into them, they liking on fleek. Most of the time I lose motivation around this point of game development because I’m just staring at moving squares. But even seeing the “pumping hearts” in my GUI is enough enjoyment for me to stay working on my game. For those working on your own game, work on some “good” placeholder art for 5 minutes, and not just a square! That’ll give you a lot more inspiration and motivation.

Things finished today:

-player finite state system

-art assets are imported into the game

-enemy death effects (screen shake and blood gunk)

-enemy spawning system

Things left to do:

-Menu

-Tutorial

-High score

-Bug fixes

009. ONE GAME A MONTH (DEV LOG #5)

Judging by the picture below, this whole game will revolve around a dancing Isaac with a Cloud as a dance partner.

I finished up the animation sprites for the game; animation is a totally different beast than programming. Programming is logical; you think through mathematical formulas, declare strict variables, and if you leave out a parenthesis here or there, your whole program won’t compile. Programming is rigid, and there’s a clear right and wrong way of doing things.

But with programming, there’s more than one way of doing things. You can use for-loops, while-loops, etc. There’s creativity behind selecting expressive variable names and different approaches you can use to tackling problems. An art is a medium for you to express yourself to others, and that’s what good coding is (albeit expressing yourself so that others can understand what you’re trying to do). And sometimes you just have to use your gut when finetuning variables. Does the player movement “feel” right? Does the screen shake “feel” good?

So maybe programming is more of an art after all. Ehhh, too philosophical for me to decide.

The animations of the game worried me most, and I’m 90% of the way through it. I’m gonna do a shitload of programming tomorrow, and get a pretty prototype done soon.

If you’re interested in getting into Animation, check out The Animator’s Survival Guide. I’m only a couple of chapters in, but everything is explained well in laymen’s terms that even a programmer can understand.