I have had several geese charge me - this is a poor approximation. I was quite young and the geese were used to humans and knew how tasty the french fries and clam strips we carried were. Honking with an bestial hunger, the savage geese charged! Pursing me across the fried clam shop’s parking lot, my mother could only cackle as she scrambled for the camera.
To this day - I have not returned to that shop.
I was playing with Python’s binary extension system and was impressed with the simplicity. I think that the usage of setup.py encourages a consistent ecosystem … as opposed to the more open conventions used by Java and CLR.
(I followed the generic instructions and they worked fine on Windows 8.1 - disregard the hype/hate!)
In which I pontificate on the subject of Hungarian Notation
It boils down to an ambiguity for the word “type” within English / C++. MicroSfot’s modern style-guide says not to use “Abbreviations and Acronyms” or “Hungarian Notation” - originally Hungarian Notation was a style of abbreviation. I’m going to paraphrase a long blog post by Joel on Software and summarize my thoughts at the end.
I’m going to illustrate this with an example of storing the day number as an integer.
Charles Simonyi’s idea was that when you created an
int day; to store the weekday variable you would use the name
int wDay; to denote that the semantic type of this day integer was “week.”
They were using “Abbreviations and Acronyms” as a sematic-type on their variables
The IT managers who set policy didn’t understand the difference between semantic type (the meaning of the data) and storage type (the mechanical storage of the data) but knew Simonyi’s team was working better and the “type” as a prefix to their variables.
So the convention became “thou musteth prefixth thine variable names with their types” for a long time.
I think that this was before IntelliSense and CodeCompletion was practical - error checking took a long time and this misinterpreted version of Hungarian Notation did help. My guess would be that IntelliSense and CodeCompletion came along and the practice became a redundant chore so it was abandoned mostly.
To get the best of both worlds (and still look clever) name your
int day; as
dayOfMonth so that things like …
… will look more-wrong and stick out when you’re debugging.
Certainly better than;
// What is this?
Awhile ago I undertook a goofy little “game-play study” with space ships.
It has space ships
I’m calling it Space-Ships.
I wanted to see if 2D game-play (like S.P.A.Z.) could “feel” like traditional 3D. (like Freelancer) To study this I built a game-play prototype with a 2.5D chase-cam in (Unity) a 3D game engine. I used engine’s existing rigid body simulator (PhysX) to provide a limited version of physics. After constraining everything to a 2D plane and fiddling with the interia values in various ways I was happy with the flight mechanics. I made a doo-dad generator to setup and teardown an infinite (not-quite) random set of space junk - amusingly this reduced disorientation with the slight tradeoff of vague motion sickness. I created some guns and a dumb AI ship that flew in circles until e saw something and started shooting at it.
Even when constrained to a 2D plane, the “accurate” dynamics simulation annoyed me. Momentum became an obstacle when I wanted to rapidly change directions to pursue another ship. My I changed the ships to get a lot of “inertia” when the controls weren’t being used - take your foot off the gas and you start to slow down. (It wasn’t actually inertia - it was “drag” … I think the manuals call it inertia … which is going to bug me now) Hunting down other ships was amusing, but the core of the game-play literally felt shallow I think that it would work for PvP style game-play, or as a sugary layer over any game with a meta-strategy system - but I’d worry about trying to make a game out of just shooting other ships. The lack of height variation limits the size of ships a bit so doesn’t lend itself to sweeping space-opera drama without big triangular ships looming over the audience’s view.
I don’t consider the technical aspects especially interesting - however I’ll outline them for the purpose of self-promotion.
The project allowed me to go nuts with extending the UnityEditor - an experience that I’m happy to repeat.
Unity’s Editor is the real star of Unity - adding extra shiny-bits in the SceneView is relatively easy, and extending or replacing the inspectors to give each script its own special arrangement of buttons doesn’t take much thought.
The most delightful of this was using a drop-down menu to assign
string values (parsed from
ProjectSettings/Inputmanager.asset) to controls that had to read from
Input.Get??(...) - a trick that I’m surprised I haven’t seen this sort of thing in Unity proper.
(It’s too cool to be a new discovery though … also it relies on using forced text asset serialization)
At a higher level - I experimented with a sort of “detached manipulator pattern” to decouple functionality without relying on inheritance.
The spaceship’s engines and guns were
MonoBehaviour classes with public variables to control whether they were firing or pushing or whatever.
The player’s ship and the AI ships both had an additional
MonoBehaviour class that grabbed these scripts and set the values as their logic needed to.
The player (of course) set the
openFire field to the value of
The AI ship used a trigger volume pointing forwards and “fired” whenever something which could be destroyed moved into that volume.
While the pilot scripts were coupled to the flight system, the flight systems weren’t coupled to the pilots.
This had the unexpected benefit of making it possible to “fly by inspector” and debug things that weren’t quite right.
For the moment I’m happy with this as a sort of “game-play study.” I’m not especially interested in carrying out more work on it at this point, but I’m not nearly as put off the idea as I would expect. I was able to try out various technical approaches and feel that while it’s not “done” it’s a decent RoI for the weeknights and weekend I spent on it.
Maybe someday I’ll add multi-player …. or maybe I’ll tryout a 2D isometric adventure.
… did I mention that there are SPACESHIPs!
I have an old Unity project that I haven’t looked at in awhile - this one. If memory serves; assembling a WebGL version is slow and boring - so I’m making my eager little Jenkins server do it.
Really I’m a bit bored with
sbt-launch malarkey and I wanted to see if I could get this rolling.
Broadly the steps that I followed went like this;
- Install Unity (5.3.3) with WebGL modules
- 5.3.3’s WebGL stuff has improved since I last checked
- Build the whole tootin thing by hand (on your workstation)
- This never works on the first try - better to do it locally
- A custom build script was involved but many snags later it lives!
- Validate WebGL player
- Build by hand (again) on the CI server
- I needed to reinstall Unity5.3.3 to get the trimmings I wanted
- I also needed to make a build script
BB8ild(script is below)
- my CI server is slow so I wanted to iron out slow problems before I started picking at it here
- still need to set it up for CI stuff
- Configure Jenkins to assemble and post the project
- This was more complex than I had anticipated
- I needed to
cdaround and run a variety of tasks (script is below)
- In the end - I cloned and pushed the whole site
- … and hoped for the best
Some paths were changed for security-via-obscurity; this won’t literally work but if run line-by-line and changed as you go you’ll get there.
This’ll work as-is
In which I ramble a bit about setting up CI for this very blog.
I have a Jenkins server running on my OsX computer. (… or … I’m setting one up anyway) I also have (am establishing?) a blog built by Hexo … because that seems the right way to do this sort of thing. My constraints of “MarkDown“ and “no really - let me use MarkDown because I’m going to have a lot of code fragments” seem alien to most blogging software - “Hexo delivers” as the kids say.
I knew that this would all work from a command line on the computer and a command line on my Windows 7 PC. After a bunch of chewing - I’ve scrawled this post in victory as a sort of test.
Hexo is built in Node.JS. I installed it and played about with it as I was instructed.
npm install hexo
After installing Node.JS I encountered various errors and I switching to a stable version of NPM. (… which I thought I had already used but … I guess not)
npm -g install npm
This was discussed here but may be irrelevant.
I setup Jenkins to poll (and pull) my repository at
H/15 * * * *.
I had already setup a Hexo site and configured it to deploy to GitHub pages.
(… which incidentally don’t seem to do anything interesting for you with Jekyll AFAIK)
The “secret” to this recipe seemed to be that the Jenkins build seems to require installing Hexo itself to work.
npm install in the folder but full-on
npm install hexo et al.
This seems odd to me but it’s what worked … but this is a CI server so longish builds are fine with me.
I used four steps, each a shell command, to perform the generation and deploy the site.
The first command installs Hexo.
I tried to install it (globally?) with
-g but encountered a security exception.
npm install hexo
The second command installs a sitemap plugin that should make my site reachable from Google-like crawlers
npm install hexo-generator-sitemap --save
The third command … installs … the site?
This may be redundant but I’m not interested in going through a “change” > “reboot” > “check” cycle to learn that I’ve broken my configuration.
The fourth command actually generates the site and uploads the generated site.
It seems odd to me
deploy doesn’t implicitly generate the site - but I can take advantage of that, see the Addendum!
hexo deploy --generate
So … yeah … that’s that. This post was the first one that I set to push out through this system.
So it’s been a few weeks/months and I want to stick generated HTML from somewhere else onto my site.
But … Hexo tries to “fill in the blanks” which keeps a consistent CSS and
<title> stuff … but breaks my Unity WebGL game.
To work around this, I’ve
- generated the WebGL to a
assets/folder and committed it to the blog’s repository
- an explanation of this is beyond the scope of this post … I’ll write it up another time
- split generation and deployment into two steps
- copied the
assets/folder into the blog’s
- deployed everything as normal
The fourth step above is replaced with these three commands;
… and it works!
I am experimenting with Hexo. I do believe it’s much nicer than my old system.
So far I’ve setup a basic site, a sitemap generator and it deploys to my existing GitHub pages configuration.
Now I’m tweaking
themes/ and copying over worthwhile articles from previous blogs!
Whole thing weighs in at 480K (or did before I added this sentence) so I’m fighting the Website Obesity Crisis somewhat … right?
… I pass the Taft test I think …