Final Fanzine v1.1

Few years ago I made a small game for some friends and I decided to make a public version which is now available on this page:

Final Fanzine

Feel free to post comments here.

Description from the web page:

This game was a wedding present we made to a couple of friend in 2011. All the drawings in this game are made by friends of the couple, some of them are artists and some are not, which excplain the diversity of style, the patchwork feel of the game (which is actually pleasant because it feels personal, if you ask me). I made took some of the background pictures and found the others on the internet. I also designed and coded this game. It was made in about 2.5 weeks, only on spare time while having a dayjob, in collaboration with the friends of the couple.

There is 3 kind of endings to this game bad, good and special.

It was only technically made possible because of the ease of use of Renpy (the tool used to make this game). The hardest part was making the sex switch work. The game plays the same whatever sex you choose, except for some details (some of which are important but hidden). Fun fact the game didn’t display any drawing few hours before I finally gave it to the couple. I added all the graphics at the last minute, with the effects.

The story is inspired by the day the couple did meet for the first time, at a comics convention. They were making amateur comics and were placed on booth next to each other, which is how they started to talk. As it was also the day I met them at this convention, I decided to make a game related to this. However, the story of the game have nothing to do with the real facts. No real names have been used. Only some characters design have some similar physical traits.

The team members are designed so that they fit archetypes of behaviours we all have at some point while trying to make comics (or games). The point is basically to fight the issues induced by these behaviours. Which is not easy.

This game was not originally destined to be released publicly but I have been thinking about doing this for several years.

For this public release, I translated the game myself and in a short time. I assume that my english is very far from perfect and the talking is certainly looking awkward to native english speakers.

NetRush Development Statistics – 2014/01/04

I’m beginning this new year with a lot of work and interesting progress going on and it just occurred to me that it would be interesting to note some statistics about NetRush’s development so far.
Keep in mind that:

  • Some code and some data of this version (4th) of NetRush was extracted from the previous version (3rd) which was unreleased. I would say less than 4% of the code is directly from the previous version though.
  • So far all the code stats I’m posting here is about code I wrote myself. Some friends looked at the code but nobody else wrote any. However, some code is generated by tools like Protobuf, from proto scripts I wrote.
  • Some of the features of the game leads to unusual technical choices (for most games), which might explain some strange numbers for some old game devs (like the libraries counts).

Here are the stats, without a specific order. Most of the stats are extracted from my RhodeCode server (an old version though) and SourceTree for repository stats, a tool named Understand for code stats:

  • Languages and dialects involved: 8
    • C++
    • CMake
    • Python
    • Protobuf
    • HTML
    • CSS
    • JavaScript
    • Falcon (for embedded scripting)
  • NetRush source-only repository (Mercurial)
    • Revision count : 1336 
    • C++ files: 229 (82%) – 142 header files (51%), 87 source files (31%)
    • CMake files: 13%
    • Protobuf files: 2%
    • Python files: 2%
    • First commit (with a few sources extracted from the 3rd version): 23 February 2012 01:45 – which was not intended to really reboot the project at first.
    • Commit that really started the project: revision 23 on 20 July 2012 – when I started working on it full-time, 4 months later.
    • Average commits count per day (533 days since the “real” start of the project, including days off and days I worked on other projects including AOS):  2.5
    • Average commits count per day (367 days if I count only week days, removing weekends): 3.6
    • Higher commits count per day: 22
    • Stats from Understand (which counted only Python and C++ files, not CMake files):
      • Blank Lines 8,245
      • Classes 210
      • Code Lines 30,727
      • Comment Lines 3,054
      • Comment to Code Ratio 0.10
      • Declarative Statements 10,307
      • Executable Statements 11,439
      • Files 296
      • Functions 3,300
      • Inactive Lines 382
      • Lines 44,316
      • Preprocessor Lines 2,524 
    • Repository size when the working directory is updated to the last revision (Windows, “Size/Size on disk” ): 4.25MB/6.96MB
  • NetRush dependencies repository (Mercurial):
    • Revisions count: 156
    • Repository size when the working directory is updated to the last revision (Windows, “Size/Size on disk” ): 989MB/1.03GB
    • Dependencies projects count: 10
      • Boost (not in the repo, installed on the developer’s system – it’s a big collection but I don’t know exactly yet how many libraries from Boost I actually use, I would guess around 10);
      • GTest (not sure a unit test framework count as a dependency)
      • Ogre (which include several plugins provided by the project)
      • Ogre Procedural (which is a plugin for Ogre)
      • Awesomium
      • Navi (which is glue code between Ogre and Awesomium)
      • FMod (that will certainly be replaced)
      • Falcon
      • Intel Threading Building Blocks
      • Google Protobuf
      • RakNet
  • NetRush-specific modules (no dependencies):
    • 2 executables (client & server)
    • 9 shared libraries
    • 14 static libraries (9 are network protocols, mostly protobuf generated code)
    • 3 unit test executables (TOO  LOW! NEED FIX!)
    • 1 build-system scripts python module
  • Stable Test Versions Privately Released (to some friends who tested and validated the versions): 4

Some comments:

  • Currently I don’t use any external assets (except some config files), only proceduraly generated content, mainly because I needed to solve the technical challenges before starting to making the game more “esthetic”. I will very soon reach having to focus on the asset pipeline which will allow some artist friends to begin to help (other than on design). This partially explains why there is not much anything else than source code in the main repository. However I think I will still separate the assets, and maybe modules too, into separate repositories. Mercurial is not very good (even with the largefile extension) to manage asset files but SVN already do it well and I also have the option to use Perforce for that. I didn’t decide which one to use yet, but it will certainly be SVN.
  • I didn’t count source files in the dependencies directory because the point is to have only code from others gathered in one place, with a version and potentially patched for my specific use. Most of my patches have been open sourced and already merged in the stable versions of the projects I’m using, so basically there is only 1 CMakeFile.txt and 2 bat files which I am the author of. The CMakeFile configures all the dependencies in a NetRush-specific way.
  • Some of the code (the more fundamental or tricky parts) are heavily commented, some of the code is not commented at all (mostly code using the fundamentals or being obvious). Most parts not yet commented are parts that I was not totally sure about, experimented a lot and waited that I found a simple and stable interface before adding docs. But I should probably add comments once I reach my next milestone.
  • I started unit tests a bit late in the project and I really regret it. The more fundamental parts are heavily tested because the rest of the code relies on them. I don’t have yet a reflex of adding unit tests as soon as I start working on a new class (when it’s not too hard to test, like the input engine), but I’m working on it because I regularly discover very important issues by adding a simple test several weeks after I wrote the wrong code. Don’t underestimate unit testing. That being said, I do have a strong habit of using assertions to check invariant, but unit tests and assertions don’t really test the same things.
  • The languages involved might change depending on some potential issues I’m suspecting, but so far so good.
  • For different orthogonal reasons the shared library count should explode in the coming weeks or months. Also, at least 2 executable binaries should be added after I reach some milestones later in the year.
  • Dependencies were hard to manage at first but now I get it well. Also, some dependencies will be removed soon.
  • I don’t use “#pragma once” at the moment, so most of these preprocessor lines are include guards. I do have some macros, mostly for code that can’t be duplicated or inferred by the language. Yet.
  • I think I managed to reduce almost half of the C++ code of 2 netrush libraries after finally getting access to a compiler providing variadic templates, default/delete functions, class member initialization and constructors that can call other constructors. C++11/14 helped reduce the code. Also, a bit of compilation speed improvements. Still C++ biggest weak point.
  • About timing: there are several months where I worked mainly on Art Of Sequence, so commits per day don’t actually say much. I can see on a graph that there are 4 periods in these 2 years where I didn’t commit at all for a month. However in all other periods I see between 15 and 5 commits per day, which seems familiar. One of the things I want to fix is to be more regular in my work process, less big batch of work in a small time; more regular small batches. Another thing is that a lot of these commits involve too many files, and sometime several features, while they should be smaller commits, each one specific to one semantic change (if possible). Anyway, commits don’t really measure actual progress I guess. It also count only for code: design didn’t happen in the repositories but mostly on paper and google docs.
  • Before the 23rd commit (which officially started the project), I spent some time playing with different kinds of architecture to solve several problems I knew I would have from experience with the previous NetRush versions. These experiments were not done in the same repository and I didn’t report anything about that in these stats. Time spent fixing some open source libraries is also not represented here.
  • The dependencies repository is clearly too big (in size on disk), maybe because I did several very wrong manipulations in the beginning when trying to organize this repo with very big set of sources + data from some dependencies like Ogre. I don’t know how to fix this except by setting up a new clear repository with no history. Suggestions are welcome. 
  • The test versions I sent to my friends to test are not really what I would call “a game”, just an interactive “toy” which check several important features and assures me that the whole system works as expected on different kind of computers. I plan to send more game-y versions to a lot more friends, I reduced the test friends to these that could answer me quickly and had a bit of gamedev background.
  • Part of the challenge of developing  NetRush is that it needs some special unusual technical aspects to be implemented first before getting to the more game-oriented stuffs. It’s a better idea when starting a project to get quick to the perceptible gameplay, but my previous attempt showed me it was not a good idea for this specific kind of game (RTS with multiple versions of the “truth”), because you end up “hacking” the non visible parts which actually are the most important. Also, lack of available teammates forbid me to parallelize work even to this day, but I hope to fix that this year.

That’s it!
I wanted to add some stats from my Trello but I can’t find how to extract numbers for it so it’ll be for another time.
Let’s take a look back at these numbers in a few months, compare numbers and see evolution.

Meanwhile, happy new year! :)


In Node Orbit

Lets get back to the development of NetRush from now on. Here is a quick update on the feature I’m currently focusing on.

One of the important decisions I made for NetRush was that the Zone’s mesh (the “map” topology, a graph made of nodes and links between them) would have “no up nor down”.


Continued reading >

Post-Mortem: 1 Year Full-Time Developing My Own Projects

In the middle of July 2013 I got back to France as unemployed (I was working in Japan before, to make some iOS games). Unemployment in France, if you worked long enough before getting in this situation, is a good opportunity to start a new company as you are paid a part of your previous salary for some time (15 months for me). I decided to focus on my own projects to prepare myself to make a living from them.
I already knew the time necessary to setup a project that I could live from would be longer than a year so I focused on getting enough momentum in these projects to be able to continue later on good bases.
Now I reached the end of this period and it’s time for learning from my mistakes. Maybe it will be useful for others.




Continued reading >