25 01 2021

Well, not quite.

I am annoyed with social media. Enough to want to move away from it.


Hello World 2.0 was perhaps too early (2018 was the worst year of my life). It is time however to start writing about my adventures through XR and document my writing of my own engine (although based on the Veldrid Rendering API).

Till next time.

“And the price of a memory is the memory of the sorrow it brings”

Hello World v2.0

26 10 2018

No pun this time.

I’ve started this blog 8 years ago. I’ve been coding commercially for 9. I’ve been programming for all of my life. Well at least as far as I can remember. It would have been far more traditional to wait the ten customary years before rebooting. But 2018 has been so full of changes that frankly, screw that. Let’s do this thing.

In my first post (I don’t even need to check, I remember) I wrote about the first save file I’d name in every game I played (and I still do): “At the start”

I’m not at THE start. Although I am at A start. So I’m starting again.

Name’s Amir. Pleased to meet you. And I’m a programmer. I love writing code. I can’t see that ever changing. Learned Basic on my Commodore 64. Taught myself C in Junior High with my best friend Yuval. We used to get together at 6.00am before school to write a simple adventure game. Then it was Pascal and Cobol and finally C++, Java, C# and even a bit of ActionScript every once in a while (shitty language, don’t ask). I worked on projects that lasted for years. I’ve worked on projects that took days. Some succeeded and others died.

I look back on almost 10 years. And I’ve changed. A lot. I had a list of programmers I looked up to; admired. That list? It’s only grown with the years as I meet more people in the field. Wish I could put myself there and although I’m alright, I still got a ways to go before. My code has changed as well. Maybe it’s because I’m growing older. Maybe a bit lazier… Not nearly as in-love with abstractions and inheritance as I used to be. Design patterns are helpful but no longer gospel and up-front designs I do in a pinch. And only by a pinch. And most of all, I know how much I don’t know and I’m eager to learn wherever I can. I learned to listen to others and not only read but consume code that isn’t mine. And that may be the best lesson I can give to others. If I could. Which I can’t. You’ll have to learn that lesson yourself ūüėõ

So. I’m ready.

Let’s kick this blog again.

Next post I’m going to write about maintaining other people’s code. And I’m going to write it on Sunday night.

“I promised you, Dad, not to do the things you’ve done. I walk away from trouble when I can”


20 10 2017

Is it already time for my yearly update?

I wish I did better with this blog. I really do. I like writing. I like writing and talking about game development. I also like talking about politics (though that usually ends up with someone getting triggered). But I’ve not managed to keep this part of my life updated consistently and I’m not sure why.. In part I guess it’s because of the time investment; though it’s a poor excuse to be honest. Maybe, hopefully, I’ll do better from today. I’m certainly going to try.

Last post I spoke a bit about the process we use to develop Buck. It’s not a perfect process and we don’t keep to it perfectly but as with everything in the development ring, there are no silver bullets.

In other game related news; I’ve update the codebase from supporting Unity3D 4.6 to Unity3d 2017. Took about two weeks. The morale of that story is “don’t change tools/engines during production unless you have to”. We had to.

And I think I might speak a bit about my latest forays into prototyping and some of the lessons I’ve learnt already.

‘Till next time,

“it’s the end of the world as we know it, and I feel fine”


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 Build.¬†I 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”

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”

Waking Up Late

8 10 2015

So; last year (not over yet) has not been the most prolific year in terms of blog posts. But things did happen. Things in the industry like Gamergate, like freedom of creation, a discussion regarding privilege mostly debated and fought over by rich kids with trust funds who have no idea what the word oppression actually means and discovering I’ll not touch publications like Polygon or Kotaku with a stick if my life depended on it any more. The kickstarter revolution and the indie-apocalypse and more fun games that I love/d playing (and some less fun games I suffered through). All of which I’ll probably write a post about one of these days.

On a more personal note; my kids grew up again when I wasn’t looking. Zeve is in kindergarten now and an avid watcher of a show called Qumi Qumi Land which is, let’s be honest, a platformer without a player. That is to say, I utterly approve. Skye switched schools, again, starting 3rd grade in a public school and she seems to be doing quite alright. She’s also enjoying her first [kids-level] MMO and well, I gotta say it brings a smile to see her enjoy gaming. What else? Ah yeah, we moved apartments. I got hit by a car. You know standard stuff…

Getting hit by a car sucks. Broke both the tibia and fibula in my left leg and now I have a intramedullary nail. Look it up. I’m facing 4 months of physiotherapy left (out of 6) but progressing. I can now walk with only one crutch and around the house mostly without crutches at all. I’ll tell you this (you, the invisible reader of this blog, most likely me in a few years), I never realized how much we take walking for granted; the little motions and angles. I no longer take anything for granted. I feel every single point of contact and movement required for a step. Ouch. If there’s one piece of advice to take from this rather rambly post it’ll be: “don’t get hit by a car, it’s not fun”.

Still working on Buck. We’re getting closer to release. Still working on other projects. Still doing freelance work when I can. Started helping on a little prototype for something called Red Heaven. Go check these things out ūüėÄ

But where do I go from here?
I’ll continue a more formalized discussion on the concept of “game” without vexing lyrically. I’m going to write more code posts. I might slip in a couple of posts about where I stand politically and why. Who knows…

“why I’m staring out your window with a suitcase in my hand”

Less lyricism

22 03 2015

Anyway, I’ve got heaps of stuff written down concerning games and game design (not to mention development). But it’s going to take more time to sort through and put it up in a more coherent way. I’m not really into the whole “stream of consciousness” style of writing. Nor am I much good at it to be honest. So, let’s chuck it up to a failed attempt and press forward.

In the end; and bottom line; games have interesting goals and use interactive systems to provide narrative which sit on top of a world simulation.

Blargh. There are plenty of games which can be considered games just not very good ones. I put “Gone Home” under this category quite firmly. Along with many other “games as art” games. Your mileage may vary. I hope it does. Accepting that diversity of opinion exist is a requirement for actual growth (rather than surrounding yourself with people who always agree with you).

Next on the program? Not sure.

“And he never did do a lot of harm in the world, but he never did do no good, people didn’t think too much of him”

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.

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”