2 days ago I ran across this site:
http://programming-motherfucker.com/
I was actually looking for C# tutorials, and this site is related to "Learn <language> The Hard Way". (Which might be fine - too bad there aren't more Python-tutorial-like websites, which is really the best:
http://www.learnpython.org/
)
Anyways, back to Programming, Motherfucker... which is now a technical term, so don't be offended. The "manifesto" part of the page struck me as funny enough to post on my facebook page, then take it down because .. well just because. And Zed Shaw has written a HUGE number of books.
So last night watched his ACM talk "The Scams That Derail Programming, Motherfucker", which is worth the time if you're sort of interested in the psychology of "community" and manipulation:
http://www.youtube.com/watch?v=c5Xh2Go-jkM
In a nutshell, take good care of yourself, watch out for scams, and learn what you can from everything that's out there without becoming a fanatic. Oh - and program! Like the wind!!
Wednesday, March 13, 2013
Sunday, February 3, 2013
Building a Board Game
I recently created a prototype board game for a game idea I've been working on. If you are at all interested in this sort of thing, I highly recommend this video about user interface design at Apple:
How to Build an iPhone App that Doesn't Suck
That video changed the whole world for me - because it got me started making a paper model board game that I could play with family and see their reactions, without writing any lines of code. It's also a lot of fun to cut out paper tiles and apply artwork.
But the real work that precedes the paper model, is the set of rules that makes the game. I used a spreadsheet for writing out my rules, and could easily generate random board layouts - all of this builds up momentum and generates ideas.
The whole process eventually lead me to some generalizations about both board games and card games (possibly other genres too). If you look at a well-designed game, you might imagine they used this process:
1) Create Layers
The simplest game I can imagine is to flip a coin: heads I get <something>, tails I don't. I'll call this "directly dependent attainment". The attainment of <something> is directly dependent on the coin toss.
Creating layers means adding indirect dependencies for attainment. [And by naming the indirect dependencies creatively, a story-line is generated.] So if we replace "flip a coin" with "open a goody hut", the goody hut may have a 50% chance of containing people (versus being empty). Will the people be friendly or hostile? It depends on <player stats OR technologies researched OR religion OR the phase of the moon>.
So the simple (and boring) coin toss game becomes interesting as layers of attainment are added - and a story is generated along the way. I can think of resource combining, exploration, and technologies as these sorts of layers that make a game interesting.
2) Organize Dependencies To Maintain Parallelism
This is really all about story-telling. Don't believe me? Listen to that guy talking about his last poker game - or my mom talking my brother's ear off about the Scrabble game she won by 1 point (I almost had her!). Maintaining parallelism of dependencies makes the story that much more compelling.
If you add several layers of dependencies for the player to create a specific unit (or issue a specific attack, or build a specific building, etc), each layer should contain related elements. One layer might contain resources (the landscape), another layer contain technologies (the technology tree). Don't put 1000 lbs of iron in the technology tree - it makes no sense!
3) Organize the Learning Curve
This might be more about presentation than it is game-play. If the game is deep, can the game elements be organized such that players don't have to know all the rules before they can start? In this way the game rules themselves are evolving as the game unfolds.
4) Subtlety Creates Depth
Here is where I bang my head against the wall - how are Chess and Go such wonderfully deep games with such simple and few rules? If you watch or play many chess games, you start to see piece development and piece cooperation as key. The story becomes more subtle even as it becomes more simple, less contrived.
These are what might be considered the highest art of gaming - a subtle story playing out, which like a good joke, maybe only a few will understand.
You'll find more discussion about game design in an earlier post Patterns and Rules.
How to Build an iPhone App that Doesn't Suck
That video changed the whole world for me - because it got me started making a paper model board game that I could play with family and see their reactions, without writing any lines of code. It's also a lot of fun to cut out paper tiles and apply artwork.
But the real work that precedes the paper model, is the set of rules that makes the game. I used a spreadsheet for writing out my rules, and could easily generate random board layouts - all of this builds up momentum and generates ideas.
The whole process eventually lead me to some generalizations about both board games and card games (possibly other genres too). If you look at a well-designed game, you might imagine they used this process:
1) Create Layers
The simplest game I can imagine is to flip a coin: heads I get <something>, tails I don't. I'll call this "directly dependent attainment". The attainment of <something> is directly dependent on the coin toss.
Creating layers means adding indirect dependencies for attainment. [And by naming the indirect dependencies creatively, a story-line is generated.] So if we replace "flip a coin" with "open a goody hut", the goody hut may have a 50% chance of containing people (versus being empty). Will the people be friendly or hostile? It depends on <player stats OR technologies researched OR religion OR the phase of the moon>.
So the simple (and boring) coin toss game becomes interesting as layers of attainment are added - and a story is generated along the way. I can think of resource combining, exploration, and technologies as these sorts of layers that make a game interesting.
2) Organize Dependencies To Maintain Parallelism
This is really all about story-telling. Don't believe me? Listen to that guy talking about his last poker game - or my mom talking my brother's ear off about the Scrabble game she won by 1 point (I almost had her!). Maintaining parallelism of dependencies makes the story that much more compelling.
If you add several layers of dependencies for the player to create a specific unit (or issue a specific attack, or build a specific building, etc), each layer should contain related elements. One layer might contain resources (the landscape), another layer contain technologies (the technology tree). Don't put 1000 lbs of iron in the technology tree - it makes no sense!
3) Organize the Learning Curve
This might be more about presentation than it is game-play. If the game is deep, can the game elements be organized such that players don't have to know all the rules before they can start? In this way the game rules themselves are evolving as the game unfolds.
4) Subtlety Creates Depth
Here is where I bang my head against the wall - how are Chess and Go such wonderfully deep games with such simple and few rules? If you watch or play many chess games, you start to see piece development and piece cooperation as key. The story becomes more subtle even as it becomes more simple, less contrived.
These are what might be considered the highest art of gaming - a subtle story playing out, which like a good joke, maybe only a few will understand.
You'll find more discussion about game design in an earlier post Patterns and Rules.
Tuesday, December 18, 2012
Worlds Cheapest Git Server Pt. 2
Here it is! To install git, run "apt-get install git" (while online of course, which for me meant hooking up ethernet cables and a television at the local library). "Wheezy" is the raspberry pi ported version of Debian, which has ssh pre-installed (although with strange defaults that I haven't worked through - it doesn't quite do keyphrases as expected right now).
Wheezy also comes with Scratch (an educational programming system for children) - worth checking out.
After setting up accounts, permissions and repositories, and Git Extensions on my Windows machine, and git-scm for Mac http://git-scm.com/download/mac, and turning on meta-files in Unity and following the other Unity documentation, it works! Hurray!
[Somewhere in the process git asked if I wanted Windows-Unix line-terminator conversions, which I answered "no conversion" and that seems to work fine so far.]
Also, not only does it work - it works well. There's some latency when checking out a 500MB repository for the first time, but it isn't bad. I will have to put some mileage to see about making minor code changes and checkin/checkout waits.
The other downside - if the house burns down, so does the git server! So it's either make a fire-proof housing for the server, or store it off-site when not in use.
Total cost:
Raspberry pi (Newark): $35
(but look at my previous post and you might get a better coupon price before January 30th or so)
Power Supply (Newark): $7
Newark shipping: $10
SanDisk 32GB SD-card (Newegg): $35 + free shipping
http://www.newegg.com/Product/Product.aspx?Item=9SIA12K0AT5024
Total: $52
Optional (really could have lived without this, since can use any t.v. screen, and after ifconfig to get IP address, just ssh remotely for setting up):
HDMI to DVI cable (Newegg): $7 + free shipping
http://www.newegg.com/Product/Product.aspx?Item=N82E16812576006
Also - to do a git push, you have to set up a git bare repository on the server. Something like this:
pi@raspberry ~ mkdir myRepoDir
pi@raspberry ~ cd myRepoDir
pi@raspberry ~ git init --bare
Now from your client you can push to ssh://pi@192.168.0.100/~/myRepoDir (or whatever the IP of the raspberry is), and the repository is set up. Now any other machine can pull from ssh://pi@192.168.0.100/~/myRepoDir.
Thursday, November 8, 2012
Worlds cheapest Git server
Yesterday I looked at Git. This is a version control written by Linus Torvalds, and I'm not going to pretend I'm an expert. However, github (https://github.com/) seems to be the favored place for open-source repositories.
Great! What if I want to keep my code private? Github allows private repositories for $7/month.
This might be a competitive price to Amazon Web Services (http://aws.amazon.com/) - although for the CPU bandwidth, it's more cost-effective to build a machine from scratch (I'm assuming their prices haven't gone down significantly since I last tried them about a year ago). It's certainly competitive to Linodes which go for $19/mo and up.
So how cheap can you build a PC for nowadays?
If you're not in ANY hurry - take a look at the quite awesome Raspberry Pi:
http://www.alliedelec.com/lp/120626raso/
Turnaround is months from placing the order, unfortunately.
You'll need a power supply and SD Card - which will run a total cost under $60. For small projects that you want to keep private and quickly set up a git server, this looks like the right way to go. There are also rumors of an Android build for Raspberry Pi, and those GPIO lines... something about them calls out "make something!"
Great! What if I want to keep my code private? Github allows private repositories for $7/month.
This might be a competitive price to Amazon Web Services (http://aws.amazon.com/) - although for the CPU bandwidth, it's more cost-effective to build a machine from scratch (I'm assuming their prices haven't gone down significantly since I last tried them about a year ago). It's certainly competitive to Linodes which go for $19/mo and up.
So how cheap can you build a PC for nowadays?
If you're not in ANY hurry - take a look at the quite awesome Raspberry Pi:
http://www.alliedelec.com/lp/120626raso/
Turnaround is months from placing the order, unfortunately.
You'll need a power supply and SD Card - which will run a total cost under $60. For small projects that you want to keep private and quickly set up a git server, this looks like the right way to go. There are also rumors of an Android build for Raspberry Pi, and those GPIO lines... something about them calls out "make something!"
Sunday, October 28, 2012
Reading the PHP manual...
Today I decided to read as much of the PHP manual as I could. While working through examples, multiple times the thought "coding horror" came to mind. But I can't afford to be that kind of snob can I?
I finally hit a language "feature" where variable names can be created by other variables. They are called "Variable variables". So if a script assigns a string to a variable $a:
$a = "horrifying";
that string can become the name of another variable:
$$a = $a." is as ".$a." does.";
It can be referenced as ${$a}. Or it can be referenced as $horrifying.
Did I mention coding horrors? Can anyone explain a legitimate use of such a construct? What drove the language to put it in there in the first place?
This language feature reminds me of the first assembly language code I wrote in High School, on a Sharp PC-1500 Hand-held Computer. [I had to use POKE commands to enter the ASM code in by hand - there wasn't any assembler.] What was cool was that the code was self-modifying! It wrote to a relative address in the code itself to increment a comparison, and change the minimum pitch of an oscillating tone. At the time, I didn't know that self-modifying code was a bad idea. It was just pretty cool how it all worked to make a wah-wah- gaming sort of sound. And I could brag about it to whoever understood what I was talking about.
So web-searching for "coding horror PHP" yields no shortage of blogs complaining about how bad a language PHP is.
My theory at the moment, is that this is fine. Really bad code can continue to be generated, and there is no shortage of enthusiastic 14 year old's out there to wade through it all. For the price of 1 experienced engineer, you can hire 10 teenagers instead. They won't know why the above example is a bad idea - they'll think it's really cool.
This gives me great pause at considering any work prospects involving PHP coding. As a good friend of mine once advised:
"Always read the whole prospectus before making any investment."
Friday, October 12, 2012
Parrot Engineering
Last night I finally got a Maqetta website to run on the App Engine launcher. For most new development stuff, there are several blogs and youtube tutorials on how to use the stuff. Not so for Maqetta. I was beginning to wonder if I could pull it off in the next few days or I'd actually have to RTFM - if there even are such manuals.
Maqetta's website has tutorials. They go as far as showing how to use the tool, and assume the developer is stuff is something you already know.
App Engine - almost the same story. I've gone through their tutorials, but still wasn't clear on the how these tools really work with each other.
Luckily one of the Google tutorial videos "Google I/O 2012 - HTML5 and App Engine: The Epic Tag Team Take on Modern Web Apps at Scale" also includes a Github link.
http://www.youtube.com/watch?v=v9TG7OzsZqQ
https://github.com/greenido
Maqetta's website has tutorials. They go as far as showing how to use the tool, and assume the developer is stuff is something you already know.
App Engine - almost the same story. I've gone through their tutorials, but still wasn't clear on the how these tools really work with each other.
Luckily one of the Google tutorial videos "Google I/O 2012 - HTML5 and App Engine: The Epic Tag Team Take on Modern Web Apps at Scale" also includes a Github link.
http://www.youtube.com/watch?v=v9TG7OzsZqQ
https://github.com/greenido
Downloading his code, and comparing with my files, eventually yields an app.yaml file that looks like:
application: heyworld
version: 1
runtime: python27
api_version: 1
threadsafe: yes
handlers:
- url: /favicon\.ico
static_files: favicon.ico
upload: favicon\.ico
- url: /images
static_dir: images
- url: /lib
static_dir: lib
- url: /static
static_dir: static
- url: /themes
static_dir: themes
- url: /samples
static_dir: samples
- url: /stylesheets
static_dir: stylesheets
- url: /
# script: main.app
static_files: file1.html
upload: file1.html
libraries:
- name: webapp2
version: "2.5.1"
#- url: .*
# script: main.app
#
Where all the Maqetta directories that contain Dojo libraries, etc, are specified. The downside to this, is you can enter directories and it serves up all of their files - not very clean. I'm not sure there's any workaround for that problem, as app.yaml seems to work like a file system directory for the whole site - if it doesn't show a directory, none of the scripts seem to have a way to get to those directories. [Yes? No? Anyone? Please leave comments clarifying if you know! Thanks!]
I call this "parrot engineering". Not a proud badge - but if it gets the job done, do it. If I can't find the answer on youtube or google, or by looking at a website's source code, Github seems to be another great source.
Wednesday, October 10, 2012
The Three Motivators
There were 3 warriors who needed to cross a great desert on horseback. Nobody had ever crossed that desert and lived to tell about it.
Not only was the desert hot and dry, it was on fire. Clouds of black smoke blocked all view, and obscured the sun overhead.
But there was no other way.
So the first warrior set off. After 2 days his horse was starting to show fatigue. But the warrior had seen many battles, he had commanded armies, he knew something about survival. He dismounted and looked his horse in the face. "We'll die here if you give up. You can't get tired now. Keep going!"
After 2 more days the horse had collapsed. The warrior found his way, but not without a great loss.
The second warrior went through similar circumstances, but rather than talking about death - he tried feeding his horse treats, and entertaining him by telling a wide variety of "a horse walks into a bar" jokes.
"So, why the long face?"
Same outcome as the first warrior - the horse eventually collapsed.
Now what did the 3rd warrior do? He and his horse made it through alive. How?
This warrior first of all had keen control of his senses. This came with training - he didn't just read a story or a book and learn that control. It took practice and a transformation of his conditioned mind into an awareness of the most subtle cues.
As a result, the warrior knew when he was acting out of compulsion and fear and when he was acting fluidly. He made no distinction between himself and the horse, or himself and the desert. The horse was also aware the warrior had no fear. Not as a contrivance "no fear", like what you might see on a bumper-sticker. "No fear" doesn't describe it positively. "All clarity" would be more accurate. The warrior was "all clarity" and the horse could see that.
So when the horse was beginning to show fatigue, the warrior also dismounted, and looked his horse in the face. "I have seen a vision of our arrival - and they are waiting for us with great anticipation! Today, we will not die!" The warrior's face was completely radiant! This was because he really had seen such a vision.
The affect on the horse was an invigoration - a perfect dissolution of fatigue. He was completely renewed, and continued through the desert refreshed. Such refreshment, when moments before he had been so tired, how can this be?
The 2 motivators commonly talked about are "fear" and "greed". But both of them, in whatever form they take, are really forms of harassment, and not based in true Authority. They are two demons, that drive common people mad chasing this way and that, both tormenting themselves and others.
Don't do that.
The 3rd motivator is like "Soul". It is much more subtle, and sometimes seems miraculous! Performance is maximized in such a place. The body relaxes without fear, and the blood vessels aren't constricted by tension. Everything flows. It isn't a question of "how can we motivate you?"
It's a selfless, pure, abiding in love.
And isn't that why we are all here? Because deep down, we really love what we do? Why would anyone resort to any smaller Vision than such an abiding?
Subscribe to:
Posts (Atom)