What I learned from my pandemic project

What I learned from my pandemic project

I wrote this a while ago and have been hesitating to publish it. I'm not sure what the ultimate conclusion I want to draw from this is, but maybe sharing this will help start some discussions...

Over the past few weeks, I finally started on my pandemic project. It's a little late in the pandemic, but everyone else seems to have learned guitar, or cooking, or whatever. What have I done…? Nothing! So, to fix that, I've decided to wander back into game development. It started with just learning about using a feature of modern HTML called "Canvas" which gives you 2d or 3d functions to draw to a browser window. It's all HTML and javascript so it's super accessible and it also lets me practice those skills more. The game concept I went with was a Legend of Zelda style 2d, tile-based kinda thing and has been a lot of fun in some surprising ways.

The power of small increments

One of the most rewarding (and surprising/refreshing) aspects of this game project is how I can regularly tick off so many "completed" things that add to the overall game. I say "completed", but for every “completed” thing I have probably gone back and reworked/rewritten almost every line of code multiple times. Some people, especially the work types, would say it probably wasn't done for any of those. To me though, that's not how software is supposed to work. I feel they are supposed to be semi-liquid and not frozen. Sure, at some point, you need to “put the brush down” so to speak, but I like the idea of going back and reworking something in light of new ideas.?

For this game, I have a running list of 'todo' items that I revisit almost every day - adding, removing, checking off as done. The to-dos themselves are not long-winded "requirements" but instead, they are short - a few words or a sentence. Sometimes it's clear what they are when I reread them later, other times it's not. If I don't know what it is I just delete the line and move on. If it was important, I'm sure it will come back. I don’t keep this in a strictly ordered list of priority items. When I'm looking for the next thing to do I just scan the list for something that seems interesting or might be a prerequisite for something else. Each of the items is inherently small(ish) and so far has been something that I can complete over a day or two. This has been working out surprisingly well. Sometimes, to implement one thing, I might also need to implement the skeleton of something else. There is a mostly emergent priority for things.?

As an example, my list included the to-do "quest system".

Map
    [x] load map
    [x] enter/exit map areas
    [x] save world state between transitions
    tiles from multiple tilesets
    map events
    [x] draw small maps in the center of the screen


player
    [x] move
    [x] attack
    [x] smooth map / walk animation
    health/damage
    inventory / pickups
    death

npc
    walk
        [x] random
        restricted to area
        path
        goal
    [x] speak
    [x] conversation/interact
    trigger behaviour - cause NPC to do something
        from a quest
        from a map event


story / quests
    [x] quest
    cinematics
    generate NPC dialog data from text file
    [x] new quest - "first talk to ron"
    intro dialog to explain controls
        

That's it. Clearly, there is not a lot of detail there... but I sort of understood the goal as 'give the player something to do'. The initial plan (and by plan, I mean the list of things I came up with on the spot that morning) for the quest system had a lot of potential prerequisites. So, what should the player do? What is the goal for the player? I continued to refine the plan and added the following detail: "You would talk to an NPC (“non-player character” for those of you who are not gamers. These are the inhabitants of the world that you can interact with) and that would activate the quest and the quest would end if the player had a special item". Just that simple thing has a lot going on - talking to NPCs, keeping track of quests, keeping track of items, and having NPCs be able to detect all of that and react appropriately. However, despite all that, at the end of one day, I had enough done that I felt I could tick off “quest system” from my to-do list.?

How did I get so much done?! Well...it basically comes down to not doing things the way most people would have been expected to at work. The “final” result, the thing I considered “done”, broke down into:

  • Talking to NPCs? - they didn't say much - just "Hi", and "Are you done yet".?
  • NPC “gave” you a quest which was just persistent booleans inside the “talk to NPC” code - quest_started and quest_completed.?
  • Possessing an item was needed to complete the quest. Items were just an array of strings in the player object that had the "name" of an item.?
  • A different NPC would “give” you the item
  • The first NPC could detect if you had the item with access to global variables.
  • The quest would be ‘complete’ when first NPC took the item from the player.?

It was all clunky and hardcoded but it worked. More importantly, it lets me explore the feature and was free to make mistakes/not be perfect because this was supposed to be "just enough".?

No alt text provided for this image

For me though, this “just enough” approach was perfect and over the next few days, while tackling other to-do items, I significantly rewrote almost everything I had already done. Not all at once, but compared to what I started with to what I have now (which I’m still not completely satisfied with) it's completely different... but the bones are all still there. I don't think there is any way I would have been able to come up with the current solution without first doing the “just enough” solution. This has been the most surprising aspect of this project for me... The sense of accomplishment and progress (dare I say velocity) has been so refreshing and my growing to-do list isn't an overwhelming quagmire. Done is not necessarily the same as finished, but it is usable and moves the project forward.?

What does done mean anyway?

I get the feeling that this sort of “done” is impossible for most of us at our day jobs. Where everything is a discrete and seemingly disconnected “project” with an arbitrary beginning and end (almost always driven by a specific date rather than a user goal). The “end” is the most important because that is where everything "stops" and the team is free to start the next thing.?You might never get another chance to go back and improve, so you need to get it right the first time.

It’s no coincidence that most teams still work with a “project” mindset. A project is discrete and finite. A finished solution with a fixed set of requirements that are recorded, in complete detail, at the start of the project so you can give a clear "end" date (the word estimate is frequently used...). To be clear, a list of features is a good thing to have and this game is no exception. My to-do list was based on what I thought I wanted to build and the features I think I wanted to include. It started at ~20 items and now is somewhere around 100. I don’t view this as a recipe, a fixed blueprint, or a binding contract. This is a rough sketch in the form of bullet points that changes day-to-day. Can you even put an end date on that? It's the difference between working towards a goal/vision and executing a predetermined solution. One feels like a journey, the other is a march.?

As an aside, if each item continues to take about a day or so - that's 100-200 days. Could even be a year once you consider not every day will be dedicated to this project and the list of todos continues to change. That's a daunting realization - but it's ok. Every day I finish one thing, and I show it to people. Nothing is ever huge or super exciting - it's usually much more underwhelming than it sounds. It’s all baby steps, but it's continuous progress.?

Does this only feel like it works because it's my hobby project and has no real purpose or consequences? I really don't want to believe that. I think this could be doable at work as well. Right now, the big difference is that I have as much visibility into the goal of the whole as well as the parts. I can see the parts and how they fit together with other parts. I have understood the trade-offs over the short term because I can see that there is a long term. The power of small increments is how I stay motivated over the long term. I’m able to consistently check stuff off of my to-do list and continue to make progress without getting overwhelmed. It’s the increment that matters. It’s more than just being small, it needs to be small and useful. Small and visible...

Rob Carroll

Technical Advisor at Technical Solutions and Networking

3 年

Great article by a brilliant mind. I remember your senior project at college... It was impressive as hell, as was your ambition and drive. Glad to see you working on fun stuff again, even if it's just a pet project. Keep going, man.

Richard Gratton

Software Product Development Leader

3 年

You might want to check out the book Why Limit WIP by Jim Benson. Short book, you already know most of it, but he focuses on the immense satisfaction of getting things done and how most workplaces are perversely organized to prevent just that. Not intentionally. It’s just that an organization that lacks the ability to reflect on vision and goals focuses instead on working, starting things, being busy, becomes on where no one gets things done and its impact on motivation is staggering.

要查看或添加评论,请登录

Craig Schumann的更多文章

  • Everyone should learn to code…

    Everyone should learn to code…

    Picked up on a theme floating around on Twitter which lead to this blog post: The post was clearly a response to this…

  • Better Backlogs

    Better Backlogs

    Be honest your backlog is a bit of a mess isn’t it. Is it clear what you need to work on next or what purpose those…

    10 条评论

社区洞察

其他会员也浏览了