Tuesday Blues

18 11 2016

Well, not really blues, maybe a light aqua sort of shade…

“Amir” I hear you say, “you crazy beautiful bushy bearded programmer, I don’t think you’ve ever talked about managing the workload with Buck!” And you’re right, I haven’t written much about the project management side of things. So perhaps now is the time to draw the outlines of the hows, whys and wheres of managing a project the size of Buck.

Let me preface this post. Every team is different and so in my opinion every methodology must therefore be customized for those particulars. In essence; there is no magic “one size fits all” management process that would boost a team’s productive output. And I remember spending a lot of time when I had less experience looking for one. With that said, let’s start.

[quick note at this point; I know the title says “Tuesday” and today is Friday, but I started writing this post on Tuesday]

Before getting into our process and because our team is different from yours. Let’s meet the team.

Buck has three people working on it. A programmer [me!], the artist and the designer (who does animations, sounds, music and the business side of things on top of it all… we love you Gal). As you can see we’re a small team. A very small team. We work separately except one day a week when we meet and put in a full office-like workday. We wanted three basic things from our process. Simple, transparent and fast. We’ve tried several approaches which failed (and I might write about those later because knowing what failed is also important but I’m running out of time again).

So, what do we do?
Enter Trello.

Trello is a simple and free (yay for awesome free tools) online tool which allows its users to create vertical lists across a horizontal axis. Each list contains cards which can be moved between the lists or archived into an internal [hidden] list. As I said, simple. At the moment we’re using a single board for Buck and have broken it into two sections; one for the code/development and one for the art/design. I’m not familiar with the art/design section (I’m the programmer after all) so I’ll concentrate on my section.

Let’s take a small detour to the cards. We have two types. Feature cards and Bug cards. And, just as they sound, each does exactly what you’d expect. A feature card describes some game or editor feature that someone wants (me or the designer) and will usually take the form of a request; ie. “I want to do [X] because of [Y]”. Bug cards are broken into two. The title of each card will describe what the bug is while the description in each card will (ideally) describe the steps required to reproduce the bug (called in parlance, repo).

Onward to lists; five lists. Backlog, Sprint, Doing, Review and Issues.

The backlog list is the catch all of all features we want in the game at some point or another. It isn’t organized in any particular way and we add to it constantly… too constantly… it always seems to grow 😀 (though not all of cards will see the light of day and will remain forever unimplemented – until the next project).

The issues list isn’t anything special; any issue we or one of our testers discover ends up there. And like the backlog it has a tendency to grow somewhat. Unlike the backlog we do sort the bugs. Into minor, major and game-breaking. Guess which ones we take care of first?

Then we have the Sprint list. This list contains all the cards we’ve decided to implement in the current sprint session. A sprint session is a static (ie. not changeable) length of time we’ve set to get from point A to point B. Point B meaning BuildI can’t actually stress this enough but;
Sprint times are immutable. Do not make them longer or shorter while sprinting. Stick to your sprint time during the sprint and Do. Not. Change.

You can change sprint times. In fact iterating over the process is as important as anything else in the process. So, what did I mean? First, we do not end the sprint prematurely. And secondly WE DO NOT PUSH THE SPRINT END UNTIL WE HAVE A WORKING BUILD. Whenever we arrive at the end of a sprint and can’t make a build. Tough. We don’t make a build. We end the sprint. Failing to implement features means we’ve taken on too much and/or we’ve misjudged the workload on any particular card. This is our opportunity to learn. Otherwise the process will fail over and over again because we’ll never become better at estimations. Trust me; I’m speaking from experience here. Don’t do this.

So what can you do?
Like all good software developers: Iterate. Do a few sprints (unless some colossal failure happens). Review; do you want more features in a build? less features in a build? Add a week, take off a week. Rinse/Repeat. Small increments will yield stable results.

Our current sprints last about a week (fast iteration, only one programmer) and usually amount to one new feature implementation and bug fixes. They were somewhat longer when the project started because we needed more time to implement systems and set up the framework before we could implement game features. Experience and pain; get it and learn from it 🙂

Once the sprint list is set work can begin. I pull the card I’ll be working on from the sprint list to the doing list and when I think I’m done, I push it to the review list. After each build Gal will test and review each card in the review list while I’m working on the next sprint. Review cards that passed are archived; cards that failed are updated with information and put back into the backlog for the next available sprint. And that’s about it.

Nothing I said here is set in stone. Our team is small and very flexible. The planets do align sometimes to throw us a curve ball and we have to step outside the sprint. As a small team I suspect it’s easier for us and at times too easy. Keeping focus is also hard work. Anyway, I hope whoever reads these things of mine enjoys and until next time…

“I speak of madness, my heart and soul, I weep for people who ain’t got control”

Advertisements




Friday Afternoon

11 11 2016

It’s been a hectic week and I’ve not managed to post a normal update on Sunday like I wanted but such is life I guess. This post is going to be fairly short as well I suspect. So, what happened?

Well, Donald Trump got elected. This has nothing to do with writing code but it was a fairly monumental event. Hopefully he’ll do better than his predecessor; concerning the middle east, I doubt he could do worse.

Everything else about this week had to do with chasing down minor bugs in the code and chasing after some bureaucratic bullshit concerning my father.

What did I manage to achieve this week?

Firstly we’ve replaced all interactive text prompts in the game with icons. And in order to do this I extended our basic sprite component to allow for atlasing (ie. the practice of having several distinct images within one texture and allowing users/systems to access them in an easy way). This in turn made it possible to quickly generate a texture atlas containing all input icons. And now the systems will automatically recognise and display the appropriate interaction input icon based on the player’s bound keys.

Secondly I had to fix some issues which came about from our new scene transitioning system (added a proper loading screen, support for an animated icon and an easier to use fade in/out system). The strangest bug that happened was that the pause menu broke. I guess that’s what happens with interconnected systems in the end. One change affects another. Luckily I’m not debugging on blind and I do have some automated tests…

Anyway, that’s it for now.

everybody knows that the dice is loaded, everybody rolls with their fingers crossed





Not Dead – Yet

23 10 2016

The title says it all. No, I’m not dead. And, hopefully, neither is this blog.

I’m not really sure why I’ve stopped updating here; it isn’t like I’ve stopped posting code, in fact I’ve been posting a lot of code on twitter and have even began recording coding sessions, tool development and bug testing over on youtube.

Actually, scratch that, the last paragraph does kind of answer the question of why I’ve stopped. But this death of the long form is not an effect I’m happy with. Twitter is fun and so is Youtube but I’ve always had a soft spot for written prose. Maybe it’s because I (once upon a time) wanted to be a writer of fiction as opposed to a writer of code (though I love doing both truth be told). And maybe now is a good a time as any to resurrect this ancient craft.

I am no longer sure what should go in here. When I started this blog it was geared specifically towards “code” but even that’s a fairly nebulous concept. So let’s set some better guidelines. What is this blog going to be about?

Well, for one, game development because I’m a game developer.

Secondly, code and code design because I’m a programmer.

Third, I want to talk about games and game-design because I’m a gamer (oh what poison has this word become to the lips of some).

Fourth, maybe, just maybe a bit of politics because I’m a human and we all love to argue about this kind of shit.

And I think that’s it. My complete life experience. Oh yeah, I’ll probably sprinkle a bit of kids, wife and parents talk because I’m also a father, husband and son.

Ideally I’d like to have a posting schedule. Once, maybe twice a week? maybe Sunday post about weekend and outlook to rest of the week and Friday post about the week itself… maybe? sounds good? I’ll try to keep up with it. And given that today is Sunday let’s ease ourselves into this.

It’s been holiday season in Israel. Not much work has been done since the kids are home from school and have been so for the last 10 days and will be home until Wednesday. Last week we showcased Buck at a games fair called GameIN which was sponsored by Microsoft. Was heaps of fun. Lots and lots of people played it, some of them (although very few) broke it. All of them died lots of times! It was exhilarating and exhausting all at once. This week I’m working mostly on bug fixes and implementing some of the feedback from last week’s players.

That’s it for now I think; like I said, let’s ease back into writing. Next post I want to tie some loose ends from last year to get things out of the way. So I’ll be writing about some personal stuff; mostly healing from a broken leg, having a new daughter and, briefly, my thoughts on GamerGate 🙂

“Better carve it on your forehead or tattoo it on your ass”





Vexing Lyrically Some More

10 02 2015

I’m not really big on philosophy. Sure, I’ve had my run of it when I was younger. Attempting to define the universe and feeling quite grand about it. It’s not that I think philosophy is not important; on the contrary, I feel that these attempts are a strong force in driving us forward. But these days I also tend to adhere more to the Mel Brooks Perspective 😛

With that out of the way; let’s disseminate some more on my idea of games. And digital games in specific. In which I attempt to derive my understanding of a what game is by mostly trying to figure out what lots of things which are not games are.

I’ve already introduced a category for scientific experiments; which are clearly not games (especially the blow-up-in-you-face-and-two-city-blocks kind of experiments). Science attempts to answer questions by simulation of conditions. Games also provide an underlying simulation in order to provide interaction – interaction being a most important part of games. But this alone is not enough.

Let’s go on another tangent (because, why not?)

Flying an airplane, be it a fighter jet or a commercial one, is no joke. And definitely not a game for the pilots who are responsible for many many lives. And yet. And yet flight simulators exist. Are all flight simulators games? That’s an interesting question. Do we treat all flight simulators as games?

The first and probably biggest difference to notice between flight simulation games and real life is the absence of actual responsibility/personal danger. These games provide a safe environment to participate in an experience which is usually not available to their players; another element, escapism of a sort (or fantasy).

So to iterate; as their name imply, simulators have at their core the concept of simulation. But as we’ve seen before, simulation is not enough to make a game. What other elements are provided by simulators. Abstraction. Fantasy. Safe.

There are, of course, further elements which can make simulators better at being games. And as the simulation level increases I suspect that the “game-ness” of the product decreases. I wonder if realism is somehow a force working in opposition to gamism.

Well, more on that later. Real life is in the way again.

I was walking through the counters of a national concern, and a cash machine was spitting by my shoulder





Vexing Lyrically

21 01 2015

I’ve not used this blog much for personal note keeping; trying to stay on course as a technically oriented space. But maybe that’s not the only direction I should take?

Been thinking a lot about games lately; the definition of the word, the people fighting to define it, etc. So let me vex lyrically for a few lines about this. Disconnected, disjointed and even nonsensical sentences may follow.

A game is played. The “play” of a game is governed by rules. To play a game means to interact with the game and with other players of the game. The game rules govern these interactions. Without rules there is no interaction, without interaction there is no game. This is not specific to digital games but is applicable (and indeed was applicable first) to physical games. All “things” in real life are interactive because of the universe’s inherent physical rules. But not all things in the universe are games (though most interactions can be made into games). It follows then that the physical rules of the universe (or any) are not enough in and of themselves to render something a “Game”.

In science we perform experiments. These experiments are set in order to test particular results from given conditions. These experiments mimic universe rules and environments and allow those performing them to interact in order to see results. This is a simulation. An experiment is NOT a game (although, again, may turn into one). It follows then that simulations are not games; this is not to be confused with the ‘simulation’ game genre, something I’ll touch on later.

Hmm…
More ideas are bubbling around in my mind but alas I shall continue them later.

“I was in another lifetime one of toil and blood, when blackness was a virtue and the road was full of mud”





Editing Project Files

19 11 2014

I find myself in a common situation where I want to open all of the .csproj files in my source directory for editing. My editor of choice is Sublime Text and I’ve got a customized environment to help me locate all of my development tools via common paths (I think I wrote about that in another post, if not I’ll write about how I set up the environment in the next post). I could write a batch file to handle that via the Windows cmd, but I figured how hard could it be to write a small tool in C#.

It wasn’t hard at all and took about 20 minutes. For me it’s a win. So without further ado, here’s the main parts of the code.

public static void Main(string[] args)
{
 try
 {
  var files = GetProjectFiles();
  var files_path = GenerateExeArgs(files);
  var exe_path = GenerateExePath();
  Process.Start(exe_path, files_path);
 }
 catch (Exception e)
 {
  Console.WriteLine(e.Message);
 }
}
private static string[] GetProjectFiles()
{
 var root = Directory.GetCurrentDirectory();
 var files = Directory.GetFiles(root, "*.csproj", SearchOption.AllDirectories);
 if (files.Length == 0)
  throw new FileNotFoundException("No .csproj files found under current directory");
 return files;
}
private static string GenerateExeArgs(IList files)
{
 var files_path = "";
 for (var i = 0; i != files.Count; ++i)
 {
  var filename = files[i];
  files_path += " " + filename;
 }
 return files_path;
}
private static string GenerateExePath()
{
 var sublime_dir = Environment.GetEnvironmentVariable("sublime_dir");
 if (sublime_dir == null)
  throw new NullReferenceException("could not find the %sublime_dir% variable");
   var exe_path = Path.Combine(sublime_dir, "edit");
 return exe_path;
}

Alright. Not too much to comment on that. Note that I do have a sublime_dir environment variable already declared. And the use of Process.Start() to run the executable.

“I fell for you like a child, Oh, but the fire went wild.”





Counts your lines!

5 10 2014

Type, type, type… Compile… Coffee… Type, type, type…

Eight hours and thirtey commits later. Blink. Stretch.

“Hmmm… How much code did I write exactly?”

It’s not really a useful question to be honest. The quality of my (and your) codebase is measured and quantified by better values than the infamous “Lines of Code”. Bill Gates was attributed with saying that measuring programming progress by lines of code is like measuring the progress on a Boeing by measuring its weight [not a direct quote]. And I agree. But sometimes it’s still fun to weigh things.

My first thought was running the analysis tools in Visual Studio. The numbers they crunch go further than simple LOC and weren’t really that interesting. My second thought was google. But alas, too many results and not enough time to go through them. It was then that I realized. Hey, let’s reinvent the wheel!

With that in mind I started a new console project (this is going to be written in C#) and decided to being with the simplest thing possible. Checking if I can read all files under my current directory and output how many code files there are.

public static class Program
{
  public static void Main(string[] args)
  {
    var root = Directory.GetCurrentDirectory();
    var paths = Directory.GetFiles(root, "*.cs", SearchOption.AllDirectories);
    Console.WriteLine("Found {0} code files", paths.Length);
  }
}

That works. Note in particular that we’re searching just for “.cs” files. And under all directories.

Next we need to actually count all lines in the files.

  var line_count = 0;
  Console.WriteLine(":: Counting Lines of Code...");
  foreach (var path in paths)
  {
    using (var reader = new StreamReader(path))
    {
      while (!reader.EndOfStream)
        line_count += 1;
    }
  }
  Console.WriteLine("Found {0} lines of code in {1} files", line_count, paths.Length);

And that should be it, except it isn’t. Our little program will now count all lines in all files. ALL lines. I don’t want all lines. I want to count code lines. But wait, what do I mean by code? For our purpose with this tool we’ll take it to mean any line that is neither empty nor a comment. To do this we’ll introduce a new method to query whether a given line is considered for counting.

public static bool ValidateLineIsCode(string line)
{
  if (string.IsNullOrEmpty(line))
    return false;var unspaced_line = line.Replace(" ", "");
  
  if (string.IsNullOrEmpty(unspaced_line))
    return false;

  if (unspaced_line.Length == 1)
    return false;

  var ch = unspaced_line[0];
  if (ch == '/')
    return false;

  return true;
}

And yeah, it’s not perfect but for my coding standards it’s pretty good and gives me a decent metric (albeit a useless one) for LOC.

It was always summer and the future called; We were ready for adventures and we wanted them all