A Couple of Weeks After Launch

It’s been a couple of weeks since Horde Rush has released on the Google Play Store, and I’ve gotten some really good feedback from players. I’m glad to know that most of the feedback is positive, and I’m also glad that whatever negative feedback I’ve gotten, it has been generally constructive, and a lot of it is actionable.

While I’m trying to figure out how best to promote my latest game, I’ve been keeping busy with a few more features and fixes to the gameplay based on the feedback I’ve received, and I’m also working on the iOS port! Yay!

So back to that “promoting” thing… It’s rough. I knew it was going to require a tremendous amount of effort to generate awareness for the game. And I know that many indie game developers fall flat at this point as well. So, I’m still working at it, and my hope is that eventually, a lot more people will enjoy Horde Rush.

Posted in Dev, Thoughts | Leave a comment

Horde Rush is Here!


I’m very excited that Horde Rush is now available on the Google Play Store. Play it now, if you haven’t already!

Anyway, anyone who has been occasionally checking out this blog will have noticed that the website was down for the last few days. I want to sincerely apologize about this. I’ll write about the outage in a future post, but for now, I’m just glad it’s back up, because now that the game’s out, I would like to talk more about it. Until then, have fun in Horde Rush!


Posted in Announcements | Leave a comment

The Horde Rush is Coming!

I’m coming to the final stages of development on my next game, Horde Rush!


I’ve been busy with bug fixes and adding some more content, so more detailed updates have been on hold for a couple of weeks, while I prepare for release.

I’m looking to release the game within a week or two, so keep an eye out for it!

Posted in Announcements | Leave a comment

Some New Monsters in Blender

I added a couple of new monsters to my game: a skeleton guy and a werewolf character.

e02_wire_front  e02_wire_perspe02_texturede02_w_e01_walk_anim

I originally thought that modeling and rigging the skeleton would be easier than modeling a skinned mesh, it turned out to be a lot more difficult. I modeled each bone with the intention of simply parenting each rigid bone model to the armature’s bone. I hoped to eventually have the skeleton break apart into its component bones when the hero character strikes it. Unfortunately, at least for this first pass, it was proving too time-consuming to do this way, and this means that the underlying code base would require some special-case implementation to support monsters breaking apart. For the time being, all bones are combined into a single mesh, and thereby skinned to the armature. As far as the texture goes, I know it looks pretty horrible as it is. It’s just a temporary test texture, and I’ll be improving that as I get closer to launch.

The werewolf, on the other hand, was very quick to model, especially with a model sheet that exposed a lot of the detail and dimension for me.




You’ll notice that in the first image, the model sheet drawing isn’t exactly symmetrical. I just worked my way around this and did my best to estimate the vertex positioning. The lower jaw is a separate model that is attached to the chest bone. This way, I can animate the werewolf biting the hero character, because the neck bone will be rotated away from the chest bone. I could have added an additional bone to the armature specifically for the lower jaw, but again, this would require special-case code that I didn’t intend to implement. I’m pretty happy with this model, it’s design, vertex and face count, and how easy it was to build and animate. It also looks like the most menacing character in the game so far.

So, my game is coming along. I’m running into numerous road blocks on the way, but that’s game development for you. I’m hoping to wrap up around mid October, so I’m excited, a little anxious, and just working on the project whenever I can.

Good luck on your own projects, and as always,…

Make it fun!


  • Blender 2.74
Posted in Art, Dev | Leave a comment

More Game Progress

Here’s a video of some progress on gameplay from a few weeks back. It’s gettin’ there, slowly but surely!

Posted in Art, Design, Dev, Programming | Leave a comment

Signing Into Android Google Play Game Services with Unity

Google Play Game Services

Google Play’s Game Services provide mobile apps with social game elements like leaderboards, achievements, and quests, which can give more value to the players of those apps. Since I’m using Unity for my current project,  I’m using an asset called Android Native Plugin from Stan’s Assets (ANP). Personally, I am not sure of how many other asset solutions there are that do the same thing, but at the time that I needed it, this asset was pretty much staring me in the face with its high number of customer reviews at pretty much 5 stars, its reasonable price, and the many testimonials mentioning the great support. So I went with it.

I actually used ANP first on Number Crunchers, for banner ads on the menu screens, and I also had some luck with Game Services login on that app, but decided against fully implementing the solution at that time.

Signing In

While Stan’s Assets and the Google Play online documentation are quite thorough in describing how to set up game services, the natural progression in software development is that shit happens, and not all the answers to your problems are immediately available. There have been some ongoing discussions on the Unity forums regarding connection issues, and here are some potential solutions and suggestions that I read about there to get this working, in no particular order.

  • The first thing suggested to me was to go to Edit > Project Settings > Quality Settings, and to set V Sync Count to either “Every V Blank” or “Don’t Sync”. Apparently some users have run into issues if this is set to “Every Second V Blank”.
  • The documentation for ANP still mentions that you can test on an emulator (not sure if this is still true), but it’s almost always a good idea to use an actual device to test on. Deploying admittedly takes a long time, but at least the results are far more accurate. The Google Play documentation also mentions using a debug certificate, and linking a debug version of the game in the Developer Console, but when I tested this, I did not get this to work, so you’ll have to deploy a signed APK.
  • Another suggestion was to delete the entry for the game in Game Services in the Developer Console, and then re-enter it, with a new keystore and client certificate. It sounds like a bit of work to redo, but it could possibly be the culprit.
  • If by chance, you’re upgrading from a previous version of the asset, first, back up your project. I was upgrading from 6.3 to 6.8, and I failed to fully read the “Update Best Practices” page, which probably would have saved me some headaches. Instead, I hand-picked all the files and folders to delete from my Unity project Assets folder, and installed a fresh copy of ANP. This resulted in a broken asset similar to what user D0R1N encountered here. I tried wiping the files clean again, and got as far as publishing and deploying my APK file, but I was still unable to connect. It was only until I again removed ANP using the “Remove” button inside the plugin that I got the asset working correctly.
  • Lastly, there have been suggestions (starting from user petediddy) about using a coroutine to wait for the connect() call to finish. In any of your Monobehaviours, particularly on init,
    void Start()
        StartCoroutine ("StartGooglePlay");
    IEnumerator StartGooglePlay()
        if (GooglePlayConnection.state != GPConnectionState.STATE_CONNECTED)
            GooglePlayConnection.instance.connect ();
            yield return new WaitForSeconds (1f); //pause for 1 second

    This isn’t directly tied to disconnection problems, but it has been mentioned for those who have had problems with sign-in latency and delays. I decided to keep this solution around in my code until a more stable release or workaround has been established.

I can’t guarantee that these solutions will work for everyone, but it’s what I gathered from the thread. I’m sure I missed a few other gotchas for the setup process, and am willing to add them here if anyone gives me a ping about it. There are quite a few landmines that can get you into trouble, so be careful ;).

Good luck!


  • Unity 5.1.3p2
  • Android Native Plugin 6.8.1
Posted in Dev, Programming | 2 Comments

Zombie Model and Texture

Here’s some work in progress on my zombie model that’s closer to my production target. I’m still getting through the production grind!


Posted in Art, Dev | Leave a comment

Number Crunchers Update!

I’m excited to see that more people are starting to try out Number Crunchers from the Google Play Store!

This encouraged me to update it a bit with a couple of things that I wanted to get in.

1.02 Release Notes

* Added a warning flash with 3 seconds to go before a safe zone disappears.
* Reduced the amount of time to wait for an extra life to 90 seconds.
* Fixed overlap for Game Over and In-Game Menu screens when backing out to Main Menu.
* Added background color selector to the in-game menu.
* Added error checking for an issue reported for RemoteException code -1001.
* Added Credits panel.

Here’s a screenshot of the background color selector:



The Number Crunchers update is now available on the Play Store.

Posted in Announcements | Tagged | Leave a comment

The Grind

It’s been over a week since I’ve posted, which is pretty uncharacteristic of me, judging by my previous posting history. Well, I’ve been caught up in the “grind”. Basically, that’s what I’m calling the Production stage of my current game that I’m developing. Since I usually like to give some perspective of what I’m doing in respect to a more general picture, I thought it was a great time to discuss the Game Development Cycle.

Before diving into what the game development (aka “gamedev”) cycle is, I’d like to step back for a bit, to describe game development in terms of overall thought processes.


An idea for a game starts with that creative spark. It’s difficult to define, but when you are exposed to something new, or you dig up some thoughts or memories, something in your mind just flips a switch. Whereas some people form an idea for a short story, novel, play, sketch, painting, song, or movie, others come up with an idea for a game (Games as a creative work is a topic that deserves its own article, so it’s out of scope for this one). You can tell that I haven’t studied psychology at all, because I’m pretty sure there is terminology and explanations for exactly what I just described; something like neurons, or firing neurotransmitters across synapses, etc. <shrug>.

Anyway, some creative ideas are good, some are great, some are mediocre, and others are just plain terrible. Either way, to bring a video game from idea to reality is quite the challenge, especially since some of those ideas might be so off-the-wall or so overly imaginative, that they may go beyond the scope of what’s possible with current technology.

Software Development

Video games are software. That’s the bottom line, and the basis for the entire development process. Without electricity and some sort of computer hardware, video games are vaporware. With that in mind, it makes sense that you can apply general software development processes and principles to making video games. Right? Well, yes and no. The challenge with video games is that you are creating an artistic work. So for game development, you really need to incorporate a combination of software processes and creative, artistic processes to have any chance of realizing the vision of your game.

The Game Development Cycle

The game development cycle is the process of making a game from start to finish. I’ll give a brief description of each stage of the cycle, but I don’t want to go into too much detail. Instead, I’d like to describe them in terms of the feelings and emotions that a developer might have. So here’s the list as a snapshot, followed by more detail about each stage.

  1. Game Concept
  2. Game Prototype
  3. Art Concept
  4. Preproduction
  5. Production
  6. Alpha
  7. Beta
  8. Final
  9. Release


Ah, this is the most fantastic and exciting part of the development process. After you get an idea for a game, you start coming up with all sorts of ideas that spawn from that one idea that would make the game more interesting. You conceptualize your game by trying to uncover every possible detail that you have that sounds like it would make the game great.

And of course, instead of keeping all of those ideas in your head, you had better document them somewhere. Speak it into a voice recorder, draw it on a white board, piece of paper, or napkin, talk it over with someone to bounce around more ideas, or more traditionally, write them all down in a game design document. You can further formalize this into a Powerpoint presentation.


In order to test out your ideas, your first attempt at building the software would be a prototype of the end product. This is where you can take all of those great ideas from your game concept (aka “proof of concept”), or at least the high risk features, and put them into a playable form. Some game designers even create prototypes of gameplay features with pen and paper, without any software. But to ultimately get a feel for how your game will play, it’s probably best to write a prototype in software. This is all the experimental stage, where you can figure out if your ideas will work, at a greatly reduced cost of both your time and money. It’s also during this stage that you and/or your team can start evaluating existing technology that you can leverage to make development faster or more streamlined, such as game engines, art/audio authoring packages, and other game development libraries and plugins.

Sometimes, you won’t know when to stop prototyping. When can you determine that the prototype has proven to you and/or your team that it is actually a fun game? That’s for you to decide, and there is no rule for this. It’s typically used to mitigate any sort of game design or technical risks before moving onto the full-blown production, so if you feel that these risks are addressed, you can probably feel safe to move on.


Along with the game prototype, concept art explores what the game will look like. Developing an art style is highly dependent on what sorts of emotions the game is supposed to evoke. The game ideas and prototypes can help identify the art style, as well as the genre that you decide to classify your game. Generating a wide range of concept art will also help to inform the development team about how much work it will take to create a particular style, and also alert the team to any challenges that the style may present to the technology that the team is using. Concept art usually takes the form of sketches, drawings, paintings, storyboards, and even mockup videos or animatics.

This stage is usually done along with the game prototype, but not necessarily in the game prototype, although that is not unheard of. These exploratory exercises stimulate even more ideas to help narrow in on the game’s identity.


You can argue that all the concept and prototyping stages can be considered Preproduction, but I separated it out here because concept and prototyping are so important on their own. Not only that, rolling into preproduction after finishing the concept/prototyping stages suggests that the full development project has been given the green light to proceed. Sometimes, after finishing concept and prototyping, you might just determine that the game wasn’t all that great after all, and it wouldn’t be worth it to proceed in making it a full blown production. In which case, you just saved a lot of time and money.

But, if you and/or your team are still excited about the game idea, you head into preproduction. You start integrating and experimenting with the existing technology that you evaluated during the prototyping phase, start to stand up core systems in code, write tools to streamline the process of creating artwork and other game content.

At this point in development, you’re still pretty fresh and excited about the game. You start to see core gameplay mechanics getting implemented. Although the results are still pretty rough around the edges, you feel that the prototyping stage has proven itself, because the game is very fun, and with more time, you will run more passes at the gameplay to refine the mechanics and polish them. The systems are fairly disjointed at this point, if they’re even built, and still need integration with each other.


Now, all the core systems are in place, the content authoring (art production) pipeline is in place, and it’s time to pump out all that artwork and gameplay. Authoring content for the game can in some ways, be monotonous, in that you are building things, like different types of game units, powerups, characters, items, etc. and sometimes there could be no end in sight. This is why I call this stage “the grind”. This stage takes up the longest development time in the cycle. You simply have to power through authoring the content. Occasionally, you’ll run into bugs that generate friction in the authoring process. And this can greatly hamper development. If, by chance, you do run into a serious issue that threatens the success of the project, or the project’s deadline, you have to re-evaluate continuing with the project. For the most part, you’ve invested so much time and effort into it, you have to eat the cost of however long it will take to solving the bug or issue, work around it, or compromise on the design. In fact, it may even be a game design oversight. As you are working through feature development, perhaps a game design conflicts with another design that no longer makes the game fun. These are the sorts of obstacles that require course correction and really threaten the completion of the game. But it really is important to power through it. If the game isn’t fun, it’s time to try and find other gameplay mechanics that you can substitute to make it fun.


“Alpha” is a software development term that varies across different software industries, and even across different game development studios. The Alpha stage that I am familiar with is when the game can be considered “feature complete”. This means all game features and systems are built, all artwork has been included in the game, but there are still a lot of major bugs to fix, and artwork to polish and improve. Declaring Alpha for your project is actually a cause for celebration. If you’ve made it through the production process, and the game is playable and is still fun, but just needs that extra polish to make things “solid”, you deserve a breath of fresh air. It’s like taking a large breather before going for that final push.


The “Beta” stage in software development is really the last step before calling it “finished”. This is the time to fix all remaining bugs, tune, tweak and balance gameplay to make it as fun as possible, and add extra polish. This is also a grueling stage of development, since any remaining bugs may have very low reproduction rate, or are very complicated to fix, which can potentially risk breaking the rest of the game, if fixed incorrectly. And polish can sometimes be difficult to introduce at this stage, because some polish tasks can end up taking a long time to implement, or after a little investigation, reveal itself as a complicated feature rather than something that can simply be polished.

Generally, it’s a nerve-wracking stage, but the finish line is in sight. You get very critical about all the work you’ve done, and you want to make sure everything is perfect. So you can actually get pretty stressed out, but you feel that it’s been worth it.

Also, if you haven’t already, this is a great time to prepare any marketing material for your game. The game content is pretty much done, so any sort of marketing screenshots, videos, or descriptions, will better reflect the game at release time. It’s arguable that marketing should actually start way earlier than this, and I actually agree, especially for independent developers. However, any sort of marketing you do before the game is complete will not reflect the final product. Nowadays though, some gamers enjoy watching a game in development, and it helps to create buzz for the game before release.


You can finally call your game “done”, but the Final stage is there to do any last minute testing in regard to compliance and integration with third parties, such as online stores.


And the game is finally released! You finally put a new product on the digital store shelves. It’s a time to rest, and also a time to work hard =). Basically, it’s at this time the marketing machine for your many hours/months/years of hard work kicks in to let as many people as possible know about your game. But marketing is out of the scope of this post, as you might imagine.

As you can see, the game development process is very much a journey. Making something out of nothing takes an incredible amount of time, effort, and dedication.


I’ve left out a lot of details about each stage of the process, mainly because each stage is so jam-packed with its own topics, that it doesn’t make sense to discuss it here. Not only that, the dev cycle that I outlined above is only a generalized look at the gamedev process. Some game developers have even established production frameworks that modify these stages to their own work methodologies. Agile software development comes to mind, and I’ll eventually write something about that too.

Game development is an iterative, creative process. Sometimes the end result doesn’t reflect exactly what’s in your mind’s eye. Sometimes, during the process, you get stimulated by other ideas that come about by something that you created, usually an interesting game mechanic or art style. Other times, you’re blocked by technological limitations or simply by the lack of time required to implement that technology, forcing you to find a way around, out, or through that problem. This incurs unexpected cost, in terms of time and/or money. Existing code and/or artwork has to either be reworked to match the new design, or thrown aside to cut any further losses. It’s no wonder why large game titles nowadays get their release dates delayed, or get extremely buggy launches.

New Trends

A few key things to note. Software is broadly heading towards the idea of “Software as a Service”. Games used to be released, supported for a couple months to patch up any serious bugs, and then development resources are moved on to another project. But now, games are largely supported long after it is initially released. Especially with outlets that allow independent developers to release their games directly to their customers, it’s more important to have the mentality that whatever you release, you have to support and maintain the game for your customers, and keep them engaged with your game and the content that each one offers.

Keep Digging

As I mentioned in the beginning of the post, I’m deep into the Production stage of development. It’s a long haul. I’ve got to grind through it, and every game developer goes through it. But that’s the cost of completion. I have no idea how long it will take me to finish. Originally, I thought I’d be done by the end of August, but now I think mid September, and even then, that’s pretty optimistic. But if you are to ever finish developing a game, you really have to set your goals, and try to set them even higher than you expect yourself to accomplish. Either way, I know I will eventually finish.

So, I guess I just wanted to inform game development newbies of what to expect during a gamedev cycle, and remind experienced developers what they go through to get to the end. That’s game development. It’s our passion, our labor of love. If you really want it, you’ll get it done.

Make it fun!


Posted in Dev, Thoughts | Leave a comment

Blender Rigify Bone Selector Panel

I’ve been ramping up my animation production lately, and one of the annoyances that I’ve run across while using Blender’s Rigify armature is that it can be difficult to select some of the control bones for a few reasons. In Wireframe display mode, trying to find the proper line segment to click on can be tedious. It helps to disable selection of meshes in the Outliner, but that still doesn’t help not being able to see the appropriate object to select. rigify_model_wireframeIn Solid, Texture, or Material display mode, again, it does help to disable mesh selection, but when the control bone is completely hidden by the mesh, as is the case for my character’s head, you have to start guessing where to click.


The best option by far, suggested to me by reddit user WhatISaidB4, is to enable X-Ray mode in the Armature panel.


Definitely an improvement over the other viewing options, but as you can see, it’s still a bit cluttered when having to make rapid selections.

So I wrote up a Python script to add a bone selector in the Properties panel of the 3D View.


The top “Use Front View” button toggles the view orientation, so that when you’re viewing the character from the front, the left-hand buttons select the right side of the character. If the option is disabled, then the left-hand buttons select the left side of the character.

The buttons outlined in boxes are the inverse kinematics (IK) bone selectors, and everything else refers to a forward kinematics (FK) control bone.

This panel differs from the Rig Layers panel, in that this is for selection, whereas the Rig Layers panel is for toggling the visibility of the rig layers in which each bone resides.

Below is the entire script. You can click on it to download it if you want, and you can just plop into your /Blender/<ver>/scripts/addons directory for Blender, and enabled in the File > User Preferences... > Add-ons window.


#  UTW_RigBoneSelect

#Copyright (c) 2015 Under the Weather, LLC
# Permission is hereby granted, free of charge, to any person obtaining a copy of this software
# and associated documentation files (the "Software"), to deal in the Software without restriction,
# including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
# The above copyright notice and this permission notice shall be included in all copies
# or substantial portions of the Software.

bl_info = {
    "name": "UTW Rig Bone Selector",
    "author": "Under the Weather, LLC",
    "category": "Object",
    "description": "UTW Rig Bone Selector",

import bpy

class UTW_RigBoneSelectPanel(bpy.types.Panel):
    bl_space_type = 'VIEW_3D'
    bl_region_type = 'UI'
    bl_label = "Rig Bone Select"
    bpy.types.Scene.use_rig_front_view = bpy.props.BoolProperty(name="Use Front View", default=True, description="Enable if the character is facing frontwards.")

    def side(self, left_side_button, context):
        if left_side_button:
            return "R" if context.scene['use_rig_front_view'] is 1 else "L"
            return "L" if context.scene['use_rig_front_view'] is 1 else "R"

    def draw_leg_controls(self, col, context, side):
        col.operator("utw.selectrigbone", text="Thigh").bone_name="thigh.fk." + self.side(side, context)
        col.operator("utw.selectrigbone", text="Shin").bone_name="shin.fk." + self.side(side, context)
        box2 = col.box()
        box2.operator("utw.selectrigbone", text="Knee").bone_name="knee_target.ik." + self.side(side, context)
        box2.operator("utw.selectrigbone", text="Foot").bone_name="foot.ik." + self.side(side, context)
        box2.operator("utw.selectrigbone", text="Heel").bone_name="foot_roll.ik." + self.side(side, context)
        col.operator("utw.selectrigbone", text="Foot").bone_name="foot.fk." + self.side(side, context)
        col.operator("utw.selectrigbone", text="Toe").bone_name="toe." + self.side(side, context)
    def draw(self, context):
        layout = self.layout
        col = layout.column()

        row = col.row()

        row.prop(context.scene, 'use_rig_front_view', toggle=True)

        row = col.row()
        row.operator("utw.selectrigbone", text="Head").bone_name="head"

        row = col.row()
        row.operator("utw.selectrigbone", text="Shoulder").bone_name="shoulder." + self.side(True, context)
        row.operator("utw.selectrigbone", text="Neck").bone_name="neck"
        row.operator("utw.selectrigbone", text="Shoulder").bone_name="shoulder." + self.side(False, context)

        row = col.row()
        col1 = row.column()
        col1.operator("utw.selectrigbone", text="UpperArm").bone_name="upper_arm.fk." + self.side(True, context)
        col1.operator("utw.selectrigbone", text="Forearm").bone_name="forearm.fk." + self.side(True, context)
        row.operator("utw.selectrigbone", text="Chest").bone_name="chest"
        col2 = row.column()
        col2.operator("utw.selectrigbone", text="UpperArm").bone_name="upper_arm.fk." + self.side(False, context)
        col2.operator("utw.selectrigbone", text="Forearm").bone_name="forearm.fk." + self.side(False, context)
        row = col.row()
        box1 = row.box()
        box1.operator("utw.selectrigbone", text="Elbow").bone_name="elbow_target.ik." + self.side(True, context)
        box1.operator("utw.selectrigbone", text="Hand").bone_name="hand.ik." + self.side(True, context)
        col2 = row.column()
        col2.alignment = 'EXPAND'
        col2.operator("utw.selectrigbone", text="Spine").bone_name="spine"
        box2 = row.box()
        box2.operator("utw.selectrigbone", text="Elbow").bone_name="elbow_target.ik." + self.side(False, context)
        box2.operator("utw.selectrigbone", text="Hand").bone_name="hand.ik." + self.side(False, context)

        row = col.row()
        col1 = row.column()
        col1.operator("utw.selectrigbone", text="Hand").bone_name="hand.fk." + self.side(True, context)
        col1.operator("utw.selectrigbone", text="Palm").bone_name="palm." + self.side(True, context)
        colmid = row.column()
        colmid.operator("utw.selectrigbone", text="Torso").bone_name="torso"
        col2 = row.column()
        col2.operator("utw.selectrigbone", text="Hand").bone_name="hand.fk." + self.side(False, context)
        col2.operator("utw.selectrigbone", text="Palm").bone_name="palm." + self.side(False, context)

        row = col.row()
        col1 = row.column()
        self.draw_leg_controls(col1, context, True)

        col3 = row.column()
        self.draw_leg_controls(col3, context, False)

        row = col.row()
        row.operator("utw.selectrigbone", text="Root").bone_name="root"

class UTW_RigBoneSelect(bpy.types.Operator):
    bl_idname = "utw.selectrigbone"
    bl_label = "Bone Selector"

    bone_name = bpy.props.StringProperty()
    def execute(self, context):
        bpy.ops.object.select_pattern(pattern=self.bone_name, extend=False)

def register():

def unregister():


I’ve seen some really slick bone selector utilities in Maya (you can do a Google image search for “Maya bone rig selector” to see what I mean), which I actually wanted to add for Blender, but I think this is about as far as I think I’m going to go. Hoping this helps streamline somebody’s Blender animation process.

Make it fun!

  • Blender 2.74
  • Python 2.7.10


Posted in Art, Dev, Programming | Leave a comment