1.5M ratings
277k ratings

See, that’s what the app is perfect for.

Sounds perfect Wahhhh, I don’t wanna

The very first demo for The Waking Cloak, ProtoDungeon: Episode I, is live on Itch.io! And it’s free! Go!! Play! Enjoy! Tell your friends! Reblog and spread the news! 😄

gamedev the waking cloak indiedev pixel art game development zelda retrogaming pixel graphics gamemaker video games gameboy games indiegame link's awakening
thewakingcloak
thewakingcloak:
“Hear ye, hear ye!ProtoDungeon: Episode I will be releasing APRIL 6! It’s a small adventure set in the world of The Waking Cloak in order to demo one of its mechanics without spoiling anything.
Patrons (patreon.com/mrdaneeyul) get...

thewakingcloak:

Hear ye, hear ye!

ProtoDungeon: Episode I will be releasing APRIL 6! It’s a small adventure set in the world of The Waking Cloak in order to demo one of its mechanics without spoiling anything.

Patrons (patreon.com/mrdaneeyul) get early access at the end of this week, MARCH 30!

It will be released for free on Itch.io and $0.99 on Steam, currently PC only. Keep an eye out here for links. :)

Patrons will also get to vote on the next ProtoDungeon mechanic. Remember, there will be one of these small dungeons for each of TWC’s main items. Since chalice and sword will probably be combined into one, that means a total of at least seven ProtoDungeons!

Reminder that this will be released on Itch.io TOMORROW YEAH BABY

thewakingcloak

Building a ProtoDungeon

With the impending release of The Waking Cloak’s first demo, ProtoDungeon: Episode I, I thought it might be fun to write up a list of things I actually did to get this demo off the ground.

Since the demo is pretty small, and limited to a single main mechanic from The Waking Cloak, people might not realize just how much work went into this. The Waking Cloak is not feature complete at all, and so I couldn’t just copy+paste all my code, slap on some art, and call it done. I had to build tons of systems from the ground up, which will then be used in The Waking Cloak (and future ProtoDungeons). For example, The Waking Cloak doesn’t even have working doors!

This is what I started with:

  • Camera
    • Decoupled from player so that it wouldn’t break if the player wasn’t in the room (logo room, title room, etc.)
      • New state to follow the swap energy
  • Collision
    • Added “corner rounding”
    • Added “point collision” checking
  • Dialogue system
    • Added the ability for different dialogue box styles
  • HUD
    • Added the ability to show/hide it
    • Added displaying key and chapel seal count
  • State machine
    • Pixelated Pope created both versions of the state machine I use. The Waking Cloak was on the old version, and I updated this to the new version (which includes a draw portion for each state, very useful)

That’s it. Might seem like a lot, but let’s compare it to what I built brand new for the ProtoDungeon:

  • Designed the dungeon
    • A few weeks of messing with graph paper, sticky notes, and Tiled
    • Streamlined dungeon creation process
      • Rough sketches to graph paper to Tiled whitebox to GameMaker whitebox
      • Previously I just painstakingly built the final version directly in GameMaker, which was slow and difficult to find problems early on
  • Actually building the rooms in GameMaker
  • Swap mechanic
    • New states for player
    • Energy ball
    • Swappable object parent
    • Breakable swap objects (jars)
    • Non-breakable swap objects (blocks)
    • Several revisions to speed and mechanics
      • Originally the player could move around while the swap energy was out, but this proved 1) not all that fun, 2) difficult to keep the player out of trouble, 3) difficult for the player to focus on two things at once, especially while the swap energy was changing direction
      • The next revision, the player had to hold the spacebar to keep the swap out. This didn’t feel very fun.
      • The swap energy moved MUCH slower, then tweaked it and made it way too fast. Settled on a compromise for player control: press space and the swap energy goes really fast, hold and it goes slow.
      • Originally the camera did not follow the swap energy (since that would be weird if the player was moving and couldn’t see what they were doing), but changed this later on after I rethought that (and due to a suggestion from my first playtester).
    • Two levels: initial, and ability to change direction
  • Block pushing mechanics (the very first version of ProtoDungeon had this before The Waking Cloak as a prototype, but I also improved how collision, player push animations, and so forth worked)
  • Trigger/listener/broadcasting system (to hook up buttons and doors, mainly)
  • Buttons
  • Doors
    • Normal
    • Doors that close after you enter a room
    • Doors/gates that open when you press a button
    • Locked doors
    • Chapel door (requires special chapel seal)
  • Pits
    • These were working in the prototype earlier, but I added falling between floors
  • Cliffs and walls
    • Including one-way jump/slide down cliffs
  • Z-height–needed several things from this:
    • Player needs to be able to go up stairs within a room and be “above” the lower level
    • Swap energy fired at a lower level will hit walls
    • Swap energy fired at a higher level will go over walls
    • Essentially created a parent object that everything inherits from to add a “z” and a “height” variable, and then zones that modify objects’ z when they’re in those zones
    • Also added optional z-checking to collisions
    • This will also be nice for when I get to the jumping ProtoDungeon!
  • Player “teleportation” (stairs, doors, etc.)
  • Transition manager (for fades, wipes, etc.)
    • I have one of these in Genogatchi, but it’s not as robust and didn’t use the GUI layer
    • Added circle transitions
    • Added white transitions
    • Much easier transition triggering
  • Cutscenes
    • Had this in Genogatchi via FriendlyCosmonaut, but improved on it and added more functions (going to room, properly working with the transition manager, etc.)
  • Throne movement logic
    • This was extremely complicated/buggy and I still don’t know why
  • Swap mirrors
  • Resetting items when leaving the room and returning–tricky, because we don’t want to reset items if you’ve solved the puzzle
    • Art
    • Gosh, I thought I could just take all my art straight from TWC and recolor it, but it was a LIE… only thing that came over was grass/trees/walls/pits/gates and some HUD elements
    • I had to draw literally everything else from scratch–the player and all her animations (SO MANY ANIMATIONS), blocks, jars, jars falling down pits, three kinds of floors, tables, stools, arrows, arrow launchers, doors, buttons, rugs, swap energy, scrolls, keys, chapel seal (HUD and in-game versions), chapel seal pieces (HUD and in-game versions), bookshelves, dressers, stairs up and down and in-room, the final item, throne, exterior windows, braziers, and more
    • Of course adding the art to all the rooms took a while, though it helped to have the whitebox
  • Getting hurt
    • Arrows, pit
    • Getting reset in the room when you fell down a pit
    • Player health system
  • Writing
    • Intro
    • Outro
    • NPCs
    • Etc.
  • Audio
    • I was surprised at how much there was to do here
    • Designing and creating the sounds (probably 25 or so of these?) in FamiTracker and Bfxr
    • Playing them consistently, balancing the volume, not looping/looping, etc.
  • Game over state
  • New control system to allow keyboard/controller
    • Juju’s GameMaker input system, but with a few tweaks–this is 1-player only, and I also needed to fix issues with my crazy joysticks which apparently constantly poll for input setup
  • Win “cutscene”
  • Logo
  • Music
    • The most intimidating thing I’ve done in gamedev, kept getting in my own head and getting discouraged. Took me about a week, and a lot of scrapped tunes.
    • Then had to put it in the game and get it looping seamlessly
  • Improvements to debugging display
    • Also hid some hotkeys behind the debugger so the player doesn’t mess up their experience
  • Title screen
  • Loads and loads and loads and loads and LOADS of bugfixes and tweaks 
    • I counted 95+ of these on my Trello board, not including tons of bugs I fixed during the process of actually creating each feature, and not including the bugs left at the time of writing

All this took approximately 2-3 months. Not too shabby! And I’m very excited for the next ProtoDungeon, because even though the next dungeon won’t have the swap mechanic, I can build on this foundation  instead of creating everything from scratch! That means I might even be able to include stuff like enemies and a boss, or menu settings. And then who knows what I’ll be able to do in the third and onward ProtoDungeons.

All of this loops back into The Waking Cloak. I’ll be able to get feedback as we progress through the ProtoDungeon and really make The Waking Cloak the best it can be.

That’s all for now. See y’all on the demo release on April 6 (or March 30, if you’re a patron!)

devlog devblog The Waking Cloak ProtoDungeon game development gamedev indiedev demo changelog?
Hear ye, hear ye!ProtoDungeon: Episode I will be releasing APRIL 6! It’s a small adventure set in the world of The Waking Cloak in order to demo one of its mechanics without spoiling anything.
Patrons (patreon.com/mrdaneeyul) get early access at the...

Hear ye, hear ye!

ProtoDungeon: Episode I will be releasing APRIL 6! It’s a small adventure set in the world of The Waking Cloak in order to demo one of its mechanics without spoiling anything.

Patrons (patreon.com/mrdaneeyul) get early access at the end of this week, MARCH 30!

It will be released for free on Itch.io and $0.99 on Steam, currently PC only. Keep an eye out here for links. :)

Patrons will also get to vote on the next ProtoDungeon mechanic. Remember, there will be one of these small dungeons for each of TWC’s main items. Since chalice and sword will probably be combined into one, that means a total of at least seven ProtoDungeons!

demo zelda game boy pixel art gaming games video games link's awakening oracle of ages oracle of seasons The Waking Cloak GameMaker indie

Anonymous asked:

I've been watching this blog for a while now, ever since I started looking for other people who were making "GB Zelda"-esq games like me; I wanted to know if I was the only one who enjoyed the games feel and mechanics. XD Anyway, I fell in love with your blog and the development, but I was wondering if you're self-taught in Game Maker language and if so, how did you teach yourself? I get intimidated by GM language but your blog is such a huge inspiration, I don't want to give up! Thank you :D

Hi! Thank you for the kind words.

So there’s two parts: yes, I am self taught in GML, but I also had a foundation of computer programming before I started (once you know how programming works in general, it’s not too hard to pick up new languages!). 

So learning to code for the first time can be very intimidating. It all depends on how you learn best, but my recommendation is to have a plan for a game you want to make, break that down into all the pieces you’ll need (player movement, score, inventory, whatever). Once you have an idea of the pieces you’ll need, look up tutorials on how to do that. GameMaker is pretty popular and has a lot of stuff out there!

Good luck, and happy coding!

Anonymous

On Creative Burnout and How to Get Stuff Done Without It

Over the past week or two I’ve had a bunch of conversations with people who were burned out and having a hard time. And this is a bit lengthy, but it goes out to you guys.


I hit some pretty nasty burnout in early 2018. I couldn’t create anything for months. Even just *thinking* about making something made me mentally cringe away. I’d not only used up all my fuel, but I was also up against some tough tasks that I didn’t know how to tackle. AND I was stressed and frustrated because I didn’t think anyone was noticing The Waking Cloak. I felt like I wouldn’t be able to make it “good enough” even for what I wanted it to be. I felt guilty because I thought I was letting people down who were following along with the project… and I wasn’t delivering.

Sound familiar? Let’s talk.

I got past the burnout and am working in a much healthier way now, a year later. But this took a shift in how I thought about working on creative projects. I used to be constantly working on The Waking Cloak because I thought that’s what it was going to take to finish it. I couldn’t afford to stop, because what if I never picked it back up again? Now I see things differently.

Part of this came from the general internet, part of it came from years of experience writing and critiquing (and now, y’know, actually applying it to game development), and part of it came from learning project management at work.

0. Before we start…

You can do this.

You’re not alone.

If you’re burned out, it gets better.

I’m around to talk if you need it.

1. The Creative Cycle AKA PLEASE REST OR YOU’LL HAVE A BAD TIME

This is a principle I learned from @emcheeseman on Twitter with this diagram:

To quote her: “Creators feel pressure to spend every second creating, but CREATIVITY IS A CYCLE between active productivity and dormant recovery.”

So the two sides of creativity: Action and Recovery. Too much Action, you get burnout. Too much Recovery and… you’re not doing anything. These two absolutely have to be kept in balance. If you’re burned out, you need to spend more time recovering. If you’re procrastinating, you need to spend time building up the momentum and taking action.

(Note: it’s important also learn to recognize the difference between the two versions of procrastination: some can come from burnout, in which case you need to recover, not work more.)

This is a cycle that should take place every day. When you’re in balance, you’ll be working on something creatively every day, but you’ll also be resting. If you neglect either, you’ll be thrown off balance and have to take remedial action–especially in the case of burnout.

This is because the creative mind is like a muscle. Muscles gain strength essentially by being torn and reknit together stronger. If you continuously work out the same muscles without giving them a chance to knit back together, you won’t get stronger. This is why strength workouts have alternating days between muscle groups.

You know all those articles and studies coming out about how crunch is bad? All those big name game studios that required crunch and burned out all their developers? Guess what, the same principle applies to your personal creative work too. Crunch is bad. Somewhat counter-intuitively, just doing “more work” will actually make you less productive, while taking time to recover every day makes you significantly more productive. So don’t make yourself crunch. Not even if you’re enjoying what you’re working on.

I’ll talk about Action later, but how about Recovery? Well, congratulations, I have good news! Having fun is now part of your creative process. Do something passive you enjoy. Play video games. Read a book, watch a TV show or movie. Go outside for a walk. Take things in. Don’t feel guilty: this is vital for your creativity. What if you always exhaled without inhaling? Would you feel guilty for breathing in oxygen?

If you are currently burned out, you need to spend a lot of extra time recovering. The more you’re burned out, the more time it’ll take. That’s the part that sucks, but trust me on this. It will get better. You’ll be able to tell after time. This can be days or weeks or longer, but you need to take it until both of these conditions are satisfied:

  1. You no longer feel yourself mentally cringing away from creating something.

  2. The idea of not creating something is unbearable

2. Motivation: creating for yourself, not to satisfy others’ expectations

It’s super important to come at creative projects with the right motivation. Even if you have a pretty decent Action/Recovery balance, if you’re trying to please others, if you’re often jealous of others, if you’re comparing your work often, you will still get burned out. Creating with these as your motivation is a bit like trying to drive on fumes. It’s not sustainable, and you will run out of gas.

This is incredibly important but difficult to put into practice. How do you shift your motivations?

Some principles:

  • Creating for its own sake is valuable.

  • Other people are not competition. They are friends.

  • Other creative projects are not competition either–similar projects can, and should, and do exist in harmony. You can learn from one another.

  • If you work primarily from a standpoint of pleasing others, you are going to be very easy to disappoint.

  • Make what you want to make, for yourself, for your tastes particularly if this is your hobby.

  • The “validation machine” is tricky. At first, you’d be over the moon to have a hundred followers and maybe ten likes. Then a thousand followers and fifty likes. And on and on, all the way up–your expectations of validation will scale up. Don’t expect to keep getting high off those likes and retweets/reblogs. Make an effort to value every one of the people who follows you, even if it’s only five people.

  • All games are held together by duct tape and prayers. You’re not alone!

Some of these are easier said than done. Just keep an eye out for these thoughts/emotions in yourself. If you notice them, take a moment, take a few deep breaths, and remind yourself what it’s all about. Do you feel yourself getting jealous? Don’t take it out on yourself (or anyone else). Try encouraging that person you’re jealous of instead. Tell them what they’re doing well, and not in the mopey “I wish I could do this as well as you” way. Instead, the “This [specific thing] is so good! Keep it up!” way. It’s hard for jealousy to exist in the same place as encouragement, even if it takes a little bit to ebb.

Another suggestion is to write down the things that excite you about creating, about the specific project you’re working on, etc. This can be broad (“I like bringing my ideas to life”) or specific (“I always love exploring caves in video games and seeing what secrets they hold”). Keep this around and remind yourself of it. For The Waking Cloak, I love working on exploration, lore, and maps!

3. How to actually work and get stuff done

This is going to be the biggest point, but it revolves around a few foundational principles:

  • Work INCLUDES rest. It’s part of the deal. You’re not allowed to skip it. (see #1)

  • Short term goals are more important than long term deadlines (aka Agile “sprints”)

  • Task-tracking and manageable, bite-sized chunks

  • One Thing a Day/Momentum

  • Do it fast, THEN do it right

Most of this is stuff I learned from my day job when we got our new head-of-department and jumping onto what’s broadly known as DevOps principles. DevOps involves a lot more than I’m going to talk about here, but I bring it up because these aren’t things I’m just making up because they sound nice. They’re tried and tested, and they work.

So first, let’s talk about short term goals.

Years ago (and sadly still too often today), common practice in software development was to plan big projects spanning months at a time, build the entire thing, and then deliver it. Major problems occur with this: requirements change, the world changes, technology changes, the users wanted/needed something different and you didn’t know until they got it in their hands, etc.

The core problem is that nobody knows what’s going to happen in the future, not with absolute certainty. I’m not joking when I say this: it’s best to focus on short term goals and skip out on long term deadlines altogether. This is commonly in the form of two-week “sprints” which are geared towards delivering some complete functionality, not the entire project/software/game/etc. Here’s why these work:

  • You have something achievable now. Two weeks of work is so much nicer than… months? years?

  • You get quicker feedback and can quickly adapt to these in the next sprint

  • Sometimes project/features of higher priority get discovered that you couldn’t have planned for

  • You’re consistently finishing some chunk of functionality every two week sprint or every milestone. Progress feels nice!

Two week sprints don’t necessarily work for all game projects, but the principle is the same: plan short-term, time-based goals, NOT functionality-based goals. If you’re getting close to the deadline, move that functionality to the next “sprint”, don’t crunch any more than a day.

If you don’t have a long-term deadline for your game set by external factors (publisher, need food to eat, etc.), and especially if you’re doing this as a hobby, my advice is to not set a final deadline until you’re more or less done with the game. Know what your major functionality is and a general order that you’ll work on this functionality in, but long-term deadlines are almost always unsustainable. You don’t know what’s going to pop up, you don’t know how long certain features will take, etc. You can’t predict the future. But you can create milestones.

In normal game development, this generally includes pre-alpha, alpha, beta, and so on. But for our purposes, we’ll want to redefine this and break it down even further. An alpha could take many months. I’m more interested in defining sets of features that can conceivably take a few weeks to two months, closer to a sprint.

In The Waking Cloak, these milestones are the ProtoDungeons. Each has a set of functionality (I only know the broad strokes, not the specific functionality each will contain–that only gets planned at the beginning of the specific ProtoDungeon). There will be eight of these, one for each of the player’s items, and they will be a self-contained dungeon. This is to:

  • Get quick feedback on how the items feel

  • Get practice building dungeon maps

  • Build a lot of the “unknown pieces” that you don’t generally think about–doors, triggers, camera transitions, pits, z-coordinate levels, and so forth.

I’ve only completely planned out one ProtoDungeon. It included the item mechanic and all the functionality mentioned in the last bullet point, but it also included more, like enemies and a boss. But then I cut everything that’s unnecessary for getting these into the hands of some testers–so that meant a lot of this extraneous stuff got bumped to ProtoDungeon 2. That way, the quicker I get this demo out, the quicker I can improve for the next ProtoDungeon. The result is that working on the game feels very light and extremely productive.

Now that we have milestones and short-term goals, that brings us to tracking tasks.

I don’t really care how you do this so much as I care that you do it in the first place! Tracking tasks is extremely important. Without, it can be easy to get lost in where you’re at in development. You have to hold everything in your brain, which is extra wear and tear.

image

I use Trello, which is free! At work we use Microsoft’s Azure DevOps/VSTS and Kanban boards. You can even just use a notepad if that’s what you like (though I suggest something where it’s easier to move stuff around, even if that’s Notepad on your computer). Once you have a place to keep track of stuff, I recommend creating some sections (I use Trello columns):

  • Backlog - tasks you’re doing this milestone

  • Bugs/issues - you’ll find these all the time :)

  • Doing - this is the bug or task you’re working on. Only work on 1-2 things at a time. If you’re not working on it, it goes back in the backlog

  • Complete - just a pile of your accomplishments! :D


And then here’s how you create your tasks for your “milestone”:

  1. List out your major functionality

  2. Break those functionalities into chunks

  3. Break them into smaller chunks

  4. Smaller

  5. Still smaller

  6. Are they now tiny? Can you do these tasks in a day or two maximum? No? Still smaller!

  7. Stop when you’re basically at the “atomic level” of tasks. They need to be bite-sized (if they’re ridiculously small, you can include them as part of a checklist on a single task)

Take all these tasks and dump them into your backlog!

As I mentioned, plan for the current milestone only. You can have a bucket of general tasks for future milestones and even a general idea of the order you want to accomplish these tasks in, but you’re only planning for the current milestone and a bit into the next one.

Prioritize your tasks. You can put a number next to each task (1 being highest, 4 being lowest is what we do at work). Or if you’re using Trello like me, you can drag the highest priority tasks up to the tops of the columns to work on next. I occasionally switch these around depending on what I feel like working on next, so don’t feel like you have to strictly adhere to a specific set of priorities.

If you’re feeling really snazzy, “weigh” your tasks. How long is this going to take? You can do this by hours, days, a generic numbering system, etc. Enough to let you know what’s going to fit into a milestone and what needs to be moved to the next one. I don’t think this is strictly necessary for a hobbyist project, but it’s pretty vital for our day-to-day at work.

Also, you will discover more tasks as you work. “Oops, to do this, I need to add that.” That’s fine. Add it as a task, prioritize/organize it, and keep going.

Like rest, planning all this stuff out is hugely important but often missed because it doesn’t feel like you’re getting stuff done. It’s deceptive. Taking time to plan and maintain your tasks will actually make you more focused and productive.

If something isn’t necessary for the deliverable, move it to the next milestone and forget about it for now. This doesn’t mean you’re procrastinating or that you’ll never get to it. Your job is to keep things light and manageable for now.

Okay, so now you have a list of tiny, bite-sized tasks, and they’re all organized. Time for the next principle: “One Thing a Day.”

I mean, with everything we’ve discussed, this is pretty easy now, right? You have a bunch of bite-sized tasks. Work on at least one thing a day! You don’t have to finish it, though the fact that you’ve got these small tasks means you’re more likely to get tasks done quickly.

Let’s say you’re me and you have a lunch break. Well, now I can try a task or two, or check off a few of my checkboxes on one of my tasks,  or at the very least get started on something I know I can finish in a few days. Or we just got the baby down to nap and she’ll be asleep for an hour and a half (probably)–I can pick up another task and work on it there.

By having small tasks, you have a constant sense of progression, which is important for your morale. And by doing at least one thing a day, you develop momentum, which is extremely pivotal in countering procrastination.

For a while I logged these on the devblog, largely for accountability, but over time I haven’t needed to do that as much.

Also, keeping the creative cycle in balance is still important. Some days I absolutely did not have time, or just felt like it would be “too much.” So I didn’t do one thing that day. Instead I’d take that time to recover.

Finally, the principle of “Do it, THEN do it right.”

This has helped me on so many occasions. My procrastination often stems from a feeling of being overwhelmed. I sit there thinking about a task and how long it’s going to take, and all the different things I have to make in order for it to work well.

Beat the system. Hack that sucker in there in the cheapest way you can. Hardcode values. Tack code on to an existing object instead of creating a new one. All you have to do is add notes. //TODO is helpful–it doesn’t do anything automatic in GameMaker, but you can still do a project search for it to come back to it later. Then see if it works. See how it feels to play. Only after you’ve got it working and feeling nice, come back and polish it up a bit. Make it less hard-coded. Put it in a script so it’s easier to call from multiple places. Create those objects.

For example, I just added some “Game Over” functionality. First I just whipped up the screen (draw black rectangle, draw text) and then made it show up at the press of a button. Looking good? Nope, the text is off. Let’s fix that. Okay, now let’s take it off this key binding and add it to the transition manager to trigger when the player dies. Shortcut: add a key that kills the player. Still triggers? Good? Okay, now make it reset the game (well, in my case, reset the room), and test with that kill key. Does that work? Remove the kill key (that would be a nasty surprise for a player if they hit the wrong key), polish (I’m summarizing, there was a lot more of this), and voilà! The important part was taking those shortcuts to blaze the trail before I paved it over (I know that makes no sense, just go with it).

This is the same idea as the rough draft of a story. No (good) book was written the way you pull it off the shelf at your bookstore. It was much rougher when it started and only got good by drafting over and over again. The point is to get your raw materials out there, like a big ol’ block of stone if you were building a statue, create the vague shape (chisel off big chunks), then work on finer and finer details.

You cannot judge your work by its first draft. You’ll absolutely be disappointed. Instead, come into it with the INTENTION of doing it fast and sloppy so that you have those raw materials to work with as quickly as possible.

4. In summary

It’s going to be okay.

Burnout can be avoided by taking time to rest.

If you’re burned out, it gets better by taking time to rest.

Good motivation helps avoid burnout and procrastination.

Plan generic long-term, specific in short term chunks, and work in bite-sized tasks.

Working in bite-sized tasks helps keep up momentum and morale.

Keep action and recovery balanced every day.

It’s going to be okay. :)

devlog devblog burnout game development planning project management i hope this helps