Hit up the store at http://store.unity3d.com!

I’ve been doing some contracting and freelance work lately, and recently had a rather mortifying experience while working on site for a web development studio.

• No documentation of common plugins used across sites, despite there being several. You are regularly building sites with a common set of plugins, write them down.
• No documentation of common hacks used across sites, despite there being several. It is unfortunate enough that you are hacking core code with dodgy workarounds and quick fixes, but when those get copied into every other site, you should probably document this.
• No documentation of current processes or workflows. Which elements do I work on as a developer, and which does your designer do? Who do I talk to about server faults?
• No code versioning; meaning things are in a constant state of unknowing with no ability to roll back to a safe point if something breaks.
• No priority system, project management software, or bug tracker that I could see.

Documentation. By far the worst offense, was the pure lack of written documentation about how the company runs itself and how its development practiced work. I’ve seen a lot of developers that loathe writing documentation. I enjoy writing this stuff down, it means I can remember what I was doing later. If you are bringing someone in to work on something because you are pressed for time and need extra resources, documentation means those eyes that have never seen your system can more rapidly pick up and plow through your tasks. Keeping everything inside someone else’s head is no use if something were to happen to that person, or if they are so swamped with their work they can’t pass that information on to new recruits!

Version Control. Subversion is free, GIT is free, Mercurial is free. It requires no additional cost to run a basic code versioning tool and not just store files in random folders on various local network computers. Isn’t it a much nicer idea to have a central location for all your code, and when bugs are fixed, it can be easily rolled out to every site using your code, instead of manually editing each file on each computer in the network or on the server?

Task management. Put all the tasks into a system where everyone can see them. This gives the wonderful benefit that you don’t have to ask your developer every 10 minutes “what are you working on, how far along is x, y, or z?” You can look and see where everything is based on the status of tasks. Even something simple like Kanban, with issues moving along a whiteboard. A company I worked with in the past used this system, and it was so simplistic yet brilliant that I started using it at home for life management! If you want to keep it in software, there are various open source solutions for bug tracking and project management.

It is easy to work around one or two of these being missing… but when none are implemented?

Please, build software better. You’ll build better software.

Firstly, I prefer to edit files in SCitE when I’m working on Windows. It’s just nicer than Notepad, without being bloated and slow like loading up a full IDE. You can use anything really.

Options (including tray menu options) are loaded from wampmanager.ini. On starting,  the wampmanager.ini file is rebuilt based on the values in wampmanager.tpl, wampmanager.conf, and scripts/config.inc.php.

To set the tray menu icon to open configuration files/log files in SciTE (or your app of choice) edit the wampmanager.tpl file and find/replace instances of notepad.exe. For example:

Type: item; Caption: "php.ini"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters: "${c_phpConfFile}"

I replaced that line with:

Type: item; Caption: "php.ini"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters: "${c_phpConfFile}"

Repeat for the other configuration files or logs as you see fit.

Another change I made, was the addition of a menu entry for editing the httpd-vhosts.conf file for quick editing of Virtual Hosts. Unfortunately, despite knowing where the httpd.conf file is by default(c_apacheConfFile) there was no tracking of where the configuration file actually lived so we could get to this Apache versions httpd-vhosts.conf file.  Solution was to edit scripts/config.inc.php and add in the following line after the c_apacheConfFile is declared:

$c_apacheConfFile = $c_apacheVersionDir.'/apache'.$wampConf['apacheVersion'].'/'.$wampConf['apacheConfDir'].'/'.$wampConf['apacheConfFile'];

Then adding a new line to wampmanager.tpl:

Type: item; Caption: "httpd-vhosts.conf"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters:"${c_apacheConfDir}/extra/httpd-vhosts.conf"

Now quick access to the httpd-vhosts.conf file is possible!

Places you might want to take this could include adding an entry to open the windows hosts file for quick access to adding local subdomains and vhost servernames, or maybe adding in a php.ini for the CLI version.

Below, my diffs!

$ diff wamp/wampmanager.tpl wamp-mod/wampmanager.tpl
146,148c146,149
< Type: item; Caption: "httpd.conf"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters:"${c_apacheConfFile}"
< Type: item; Caption: "${w_apacheErrorLog}"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters:"${c_installDir}/${logDir}apache_error.log"
< Type: item; Caption: "${w_apacheAccessLog}"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters:"${c_installDir}/${logDir}access.log"
---
> Type: item; Caption: "httpd.conf"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters:"${c_apacheConfFile}"
> Type: item; Caption: "httpd-vhosts.conf"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters:"${c_apacheConfDir}/extra/httpd-vhosts.conf"
> Type: item; Caption: "${w_apacheErrorLog}"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters:"${c_installDir}/${logDir}apache_error.log"
> Type: item; Caption: "${w_apacheAccessLog}"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters:"${c_installDir}/${logDir}access.log"
160,161c161,162
< Type: item; Caption: "php.ini"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters: "${c_phpConfFile}"
< Type: item; Caption: "${w_phpLog}"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters: "${c_installDir}/${logDir}php_error.log"
---
> Type: item; Caption: "php.ini"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters: "${c_phpConfFile}"
> Type: item; Caption: "${w_phpLog}"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters: "${c_installDir}/${logDir}php_error.log"
173,174c174,175
< Type: item; Caption: "my.ini"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters: "${c_mysqlConfFile}"
< Type: item; Caption: "${w_mysqlLog}"; Glyph: 6; Action: run; FileName: "notepad.exe"; parameters: "${c_installDir}/${logDir}mysql.log"
---
> Type: item; Caption: "my.ini"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters: "${c_mysqlConfFile}"
> Type: item; Caption: "${w_mysqlLog}"; Glyph: 6; Action: run; FileName: "C:\Program Files (x86)\SciTE\SciTE.exe"; parameters: "${c_installDir}/${logDir}mysql.log"

$ diff wamp/scripts/config.inc.php wamp-mod/scripts/config.inc.php
35a36
> $c_apacheConfDir = $c_apacheVersionDir.'/apache'.$wampConf['apacheVersion'].'/'.$wampConf['apacheConfDir'].'/';

To show off this functionality they’re hosting a short competition with some rather nifty prizes. The Flash in a Flash Creation Contest is a two week competition running from Dec 22 to Jan 5, with the goal of creating the best Flash game or interactive application using the new 3.5 build. The prizes are quite nice, including a large cash prize, and several pro licenses, and some Apple hardware. The only thing that worries is me is whether the submissions will all be created in this two week period (ala the Game Jams, forum competitions, etc) or if people are likely to just quickly port the projects they’ve been working on for months. I think the former will really serve to showcase  the power of the tools as well as the creativity of the developers, while the latter doesn’t really seem as true to the spirit. I suppose we’ll find out when the results are released!

It’ll be interesting to see how people navigate the tricky holiday season with their entries to the competition. I have no plans for Christmas day, maybe I should get stuck into this myself!

Sent: 12/21/2011 4:14 PM
To: support@unity3d.com
Subject: Query regarding Linux Target

Hi Guys,
Firstly, let me say thank you for all your hard work and in releasing this development kit the way you have. The free indie license coupled with the sheer power of the platform in either it’s variations is amazing and we’re all thankful for that, I believe. However, I just want to try to get something official from you regarding plans for porting the player to Linux (though the editor would be nice, I doubt it’s likely any time soon) . On the Unity Technologies Blog you guys had a successful build  of core functionality of the Unity Web Player running in a browser on an Ubuntu machine. That was back in March, 2011. That was exciting for a few people who read the blog, I’m sure.
If you guys aren’t working on it officially for reasons of lack of financial potential or the cost of resources to develop such a thing, would it be possible for the community to organise a drive for funds to pay for the development for this task specifically. All we would need from Unity Technology is a cost and a promise to hire staff with the funds raised. This sort of thing has found success before, with the open sourcing of Blender as a shining example of what crowd-sourcing can do for software on a large scale.

If you check out the cries for Linux player support on your feedback site, you’ll see over 10000 requests for this feature, nearly 10x that as requested for the GUI Editor changes which are currently in progress. Below are two comments I’ve made on this particular issue, back at the end of October. (my user-name is wolflogic there)

Thank you for your time in reading this, and I hope to get something back from you. I want to post whatever you reply with to the Unity Feedback thread in question, as the people there are beginning to cry foul and assume that you guys don’t even read the feedback posted.

Cheers,

Rick
———-
wolflogic commented  · October 27, 2011

At time of writing, this feature request is ranked 1st, with 9,096 votes in its favour. Reading through comments, it’s been first for at least 6 or 7 months. The next ranked item in the list for a GUI Editor only has 1,805 votes in it’s favour. Why has the Linux player build target essentially been ignored? One of the reasons I left Linux as a primary OS was lack of decent games. A unity player would open up a massive library of content on Linux and bring more business.

And with the Humble Indie Bundle campaigns, it’s been evidenced that Linux Users are more open with their pockets for quality games than those on the other platforms.

http://www.lifehacker.com.au/2011/07/humble-indie-bundle-shows-that-linux-users-arent-cheapskates/

http://www.geek.com/articles/games/linux-users-pay-3x-that-of-windows-users-for-humble-indie-bundle-3-2011082/

wolflogic commented October 27, 2011

@Bugsbane — I would definitely throw cash at a kickstarter project if it were to get this done, player or editor, or both. Ultimately the player is more important than the editor, but I think a large number of people would fund both projects.
I have to wonder if this is something that the community could organise with Unity Tech to make it as easy for them to have to do as little as possible aside from hiring developers?

I got a reply pretty quickly; about an hour or so later. Their reply is below. Graham did counter with some valid points that we the community should probably address.

Date: Wed, 21 Dec 2011 17:00:30 +0000 (GMT)
From: Support <support@unity3d.com>
Subject: RE: Query regarding Linux Target

Hi Richard,

We have a few developers who have been working on Linux in their spare time.  For us to sell this as a feature, we need to know there is a market for Linux export.  We estimate that a full-time dev, QA and support engineers dedicated to this platform would run at around $250k/year.  This would equate to around 170 Pro sales per year.  We do not think that there are 170 people who would purchase Pro simply because we support Linux.  We would love to be proved wrong.  There’s no need for the Linux community to fund the development, just commit to buy the product.  With the exception of the HumbleBundle packs we don’t know who is making money from Linux gaming.

We don’t think that the 10k requests for Linux all come from our development community.  At least, when we ask our customers we get a different response.  We get lots of requests into the support team from end gamers who want to play Unity games on Linux, so some of the feedback is from end users.  Those end users should be demanding that the people who make games with Unity support Linux, and for those people (our customers) to tell us what revenue they are loosing because we do not support Linux.

Shipping the linux webplayer on a single distro (presumably Ubuntu) is easy.  It’s the on-going support for this, and constantly keeping it updated as the product evolves that is the issue.  If we released support for Linux and then dropped it in the future that is kinda worse.

Note that in 2012 we’ll have support for building to Flash, and that will work on Linux, so our customers will be able to target Linux gamers.

For an official comment you need to reach out to our founders.  My reply is based on my position providing support and being involved in QA.

Thanks,
Graham

He brings up a valid point. 10000 signatures saying “we want to be able to play Unity games on Linux” is not the same as 10000 devs saying they want to sell games to Linux users AND that they intend to buy Unity PRO. Now that they’re not getting money from the Indie license, if people aren’t buying their pro licenses, they’re not making any money, regardless of how many platforms are targeted. I assume this is why the PC/Mac versions are free but even basic iOS and Android targets are $400 a pop. Would anyone buy pro if it was the only way to build for Linux? Some would, but would it be enough to warrant the time and effort in maintaining the platform? What if it was another target like iOS and Android, $400 for basic and $1500 for Pro? Then what happens if you want to go Pro for all 3 (Win, Mac and Linux) then do you have to buy Pro for a “PC” twice?

Definitely something that we should think about, I think. Instead of just screaming that Unity is ignoring us, perhaps we need to talk to them in a more professional manner. Perhaps we should present substantial business cases as to how we as Linux developers will be a boon  to their product?

Edit – 2012-03-13-1113
I did actually receive another email from Graham as part of that conversation which I failed to upload. It didn’t change much, just added further information supporting their reasoning. Since I’ve been linked to by ubuntuvibes on this post, I figure I’ll update with those missing emails.

Date: Wed, 21 Dec 2011 22:37:08 +0000 (GMT)
From: Support
To: Me
Subject: Re: Query regarding Linux Target [ ref:00D2M42f.5002Juziw:ref ]

Hey Richard,

Good that you have some ideas now. Bear in mind that Linux is easily mistaken for open-source, which is easily mistaken for “no money”. We’d do a Linux version if we can see a commercial reason to do so. There is a food chain here. If end gamers want to spend money playing games on Linux, so game developers can make money making linux games, and spend some of that money buying tools from us, then it’s a business. And if that model is repeatable every year (meaning more teams end up buying licenses) then it’s a sustainable business. And, as I said, we know about the HumbleBundle – that is the example everyone gives. We’re just missing other examples of how our customers can monetise the Linux market. Just *assume* we’d never make a free version of Linux export, and charge $1500 for Pro and $1500 for a Linux add-on. Who’s up for spending that money? Are there people out there who’d pay this to get the ability to target Linux gamers? (I am not saying we’d never make it free, but we’d need to get money from customers somewhere…)

Thanks,
Graham

 

————— Original Message —————
From: Richard Cuddy
Sent: 12/21/2011 5:53 PM
To: support@unity3d.com
Subject: Re: Query regarding Linux Target [ ref:00D2M42f.5002Juziw:ref ]

Hi Graham,

 

Thanks a lot for taking time to reply and offer that point of view. It gives us a point to address and work on instead of shouting blindly into the internet hoping someone’ll pity us! I’ve posted your reply and my thoughts onto the issue in question (and my own blog) so hopefully something can be worked toward from the Linux community to show we’re a viable consumer base as developers using your tools, and not just as players of games!

 

As for the Flash build target, that will be truly awesome when it is launched. I’m looking forward to that one personally, but not as a “it’ll work on Linux” but just because I’m quite keen to see how well it’ll take advantage of the new Molehill. I’ve done AS3 dev in the past so it’ll be a pretty amazing addition to the tools, for sure.

Cheers,

Rick

After several hours of tweaking and changing and trying to force some sort of debug output, and wondering why it was completely failing to even throw any exceptions at the dread white screen of death, and thinking it was “something cross domain security” related, I stumbled on this post:

http://timheuer.com/blog/archive/2010/06/10/troubleshooting-debugging-silverlight-cross-domain-xap-hosting.aspx

My problem, it was solved! Figures, running linux servers, and apache wasn’t configured with the correct mimetype. The nightmare is over.

It’s also time for some new content, which will be coming shortly; updates on some new projects, some freelancing information, and some general thoughts about stuff.

Stay tuned, more to come.

Unfortunately, the keyboard shortcut tool doesn’t let you map the Super button anymore, so to set it we need to use gconf. Open gconf-editor and go to /apps/metacity/globalkeybindings/ and look for the option named “run_command_terminal” you can set it here by changing the value to “<Control>Super_L”; in this case it will work with the left windows key.

Another issue I found again today after opening Blender again for the first time in a long while, was that  Alt+RMB (edge ring select) gets stolen by Compiz and turned into a Menu popup instead. This can be fixed in gconf as well by going to /apps/compiz/general/allscreens/options/ and changing the value for window_menu_button to “<Control><Alt>Button3″.

I also need to convert these SVGs to PNG for including in the Design Document; and for art assets inclusion in the final product.

I tried playing around with ImageMagick, but it didn’t handle fonts as nicely as I’d have liked. There are ways to reconfigure it to look for the fonts, but I didn’t want to bother with that for now. Inkscape already displays it how I need, so I might as well use it for the whole process.

The simplest way to convert from InkscapeSVG to PlainSVG on the command line is: inkscape --export-plain-svg=OUTFILE INFILE

Note that if you name it the same thing you’ll risk killing your existing file. It’ll still load in Inkscape in theory, but some special things may be lost. Your mileage may vary.

To PNG, again, we can use the same command structure. inkscape --export-png=OUTFILE INFILE
Note that with PNG export, you’re going to have a transparent background by default. While you’re drawing on the canvas its default is white, however there is no actual data there, so it saves to a transparency. In this case I needed to have everything output with a white background. You can add the flag --export-background=ffffffff to get a white background. Replace the hex with any other html colour code for the equivalent background.

I put this all together in a script to let me do a bunch of files all at once. It needs some more tweaking for options like transparency on/off, checking for update times to avoid excess workload, etc; but it works fine for my needs. You may find it useful too. It creates two folders in the current folder: plainsvg and png. This keeps it neat and tidy. It’ll go over every .svg in the directory and convert and save. Note this has rename -f in use, which will clobber any existing files with the same name.

#!/bin/sh
# (C) 2009 Richard Cuddy
# Feel free to use this however you want, if you do something seriously awesome with it, let me know!

mkdir plainsvg
mkdir png

find . -name "*.svg" -type f -exec inkscape --export-plain-svg={}.tmp {} \;

mv *.svg.tmp plainsvg
cd plainsvg

find . -name "*.svg.tmp" -type f -exec rename -v -f 's/\.svg\.tmp/\.svg/' {} \;

find . -name "*.svg" -type f -exec inkscape --export-background=ffffffff --export-png={}.png {} \;
find . -name "*.svg.png" -type f -exec rename -v -f 's/\.svg\.png/\.png/' {} \;

mv *.png ../png/

I decided I wanted to make it look a bit less terrible by using Inkscape instead of the Gimp. For quick rectangles and text, Inkscape really is faster and looks better. As I was editing it, I wondered if it would be possible to use the SVG itself as a background image.

I opened up the Appearance settings, and browsed for the file. What do you know, it showed up. This in and of itself isn’t that exciting, until you realise that SVG can be changed really easily in a script. It’s just XML data. What can be interesting is that you can embed a link to a non SVG image to use an underlay. I didn’t have to duplicate my 600kb JPG, I was able to just embed that link, and then add text and paths on top of it.

What’s more exciting was that as soon as I saved any changes, the background image automatically refreshed itself. Something I was never able to make Windows XP do easily, without making an actual call to Windows’ DLL system. This was just edit, save, bam.

The possibilities are quite interesting. I may later put together some bash or python to do something fun like updating the BG with system internals, getting currently playing music, etc. Really you could do anything with this. All without damaging your original image or mucking around with graphics blitting code.

The only things to be aware of is that when you save in Inkscape, it defaults to an SVG format with a -lot- of extra information which makes the file more confusing than it needs to be. Just remember to save it as “Plain SVG” if you’re doing this. Also, the image link must be a full path. A relative link doesn’t work correctly, and Gnome can’t display the image. For example:
<image
xlink:href="/home/username/images/backgrounds/mypic.jpg"
x="0"
y="0"
width="1680"
height="1050"
id="image11" />
When it originally saved, it only saved as xlink:href=”mypic.jpg” If you’re doing future editing only in a script by changing the XML directly, you shouldn’t have to worry about this after you change it once.