About 5-6 years ago, I chose Java when I was in a similar position and writing a game. It's a much easier language (I don't feel like justifying this claim, others have done so) and the final product is easier to share with friends (package your code in a runnable jar when you're done). One other word of advice, I found it simpler to write my own basic engine rather than learn another. If I had my current level of experience, I would definitely start by learning an engine. However, if you don't have a lot of experience coding, it might be easier to write it yourself. For example, you won't need to figure out the documentation for plugging into the game loop because you will have written your own game loop. (1)
There is a bug. If you are traveling right, then quickly press down, release down, then press left, and release left, you will die. This is not snake behavior.
Are you guys interested in teaching kids how to code/make games? Your visual method for scripting looks very similar to scratch (http://scratch.mit.edu/). Although I haven't used your program, it seems like it would make a natural stepping stone once kids have done everything they can in scratch.
<CSB> I taught an extracurricular class on game making in scratch to elementary school kids for four years. Every year, there were one or two kids that seemed to have mastered scratch and were being held back by the program's limitations. I wish I had had your program so that I could have given them something more challenging.</CSB>
Yup, teaching kids (and adults alike :)) is one of my motivation for CraftStudio. Scratch was a great advance back in the day (and their visual scripting system was definitely an inspiration for CraftStudio's own) but the Scratch platform is severly limited and I definitely believe CraftStudio would be a good upgrade for a lot of children (as an upgrade path from Minecraft too, since it shares some similarities). I know kids aged 10 to 15 are building actual little games with CraftStudio, so I'm definitely hoping to see that aspect of it grow more :)
Do I love the guy, no. But, he is doing something. I've "completed" quite a few side projects (video game, chat server, etc) but I've never got anyone to actually use them. To do all three sides of the coin, technical product development, artistic design, and marketing, earns you respect in my book.
My (heavily biased) recommendation - start with c++ or some other annoying, slow language. I know other people say learn python or ruby, but I think that makes for sloppy programmers and bad habits.
First, read Introduction and Basics of C++ in the link below. Then make a text based rpg with 1-2 rooms. I would have a character and two bosses each with with power, toughness, and 1-2 attacks. Then read Compound Data Types and Object Oriented Programming from the link below. Finally, revise the code of the game to use objects (don't worry, that will make sense once you finish reading). Also, to emphasize your bossness, say that are "refactoring" your code.
As a gamer, I thought it was cool that I could make a simple game like this. Maybe you won't. In which case, my suggestion probably is worthless. But, I think that learning a more systems level language will force you to think more about your code and make you write better code in the long run.
I actually agree with making game-y stuff just for fun, because it allows you to think up and build rather intricate architectures real quick. It's hard to make a game as a newbie and not have it turn into spaghetti as you keep making it more complex, but it's also no biggie, and you get to learn how to recognize those things, what to improve etc. Practice with games, when you become more confident make applications; to me that makes sense? Playing games may be a shallow pastime, but making one can become more hardcore than one imagined real quickly. Just about anything in programming you could mention, certainly all the "pedestrian" things, could theoretically be put in a game - but a game can also be just two rectangles and one circle, and in that spectrum, and the absence of even the pretense of being useful, lies a great opportunity for experimentation and learning.
Make a simple clone of a game or application or graphical effect you adore, and go from there. There's still plenty of opportunity to suck the fun out of it later :P
I disagree with your idea of running native code on the client as a replacement for the web in the context of laptops and desktops. The app store works because apple curates it. In the Android marketplace, many applications are viruses (http://www.androidguys.com/2012/12/14/lookout-18-million-inf...). If more than 9-10% of laptops and desktops had access to the app store, I would imagine that malware would be a more significant problem. Therefore, while I agree with the rest of your complaints, I disagree with the idea of making the web run using native code. I think that an interpreted environment will become good enough to do everything a user wants as computers get faster. In fact, if we can assume the standard user watches Youtube videos and sends and receives images and text through Facebook/Instagram/..., then interpreted code is fast enough today. On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer.
Side Note: I also just really, really hate app stores. I find them to be much more restrictive than just throwing a website up and allowing anyone to access it. The idea of having to pay someone to allow users to be able to use my stuff is way too restrictive to me.
Strictly speaking, native clients have nothing to do with app stores or speed. I just mentioned mobile apps and some software available in the Mac App Store as success cases because native clients backed by HTTP APIs seem to be a much saner development environment than shoehorning an app to run inside a browser, which is limited to one language, crappy APIs, broken interaction models and lack of standards.
> On the web, where the user must constantly accept and run code from unknown and untrusted developers, code must run in a sandbox to minimize risk of unwanted access to the user's computer.
First, sandboxed environments are not limited to browsers (e.g., OS X 10.8). Second, browsers are often the attack vector, because they were never meant to run applications, and have broken security models (e.g., no application signing). So you end up in a sandboxed environment with terribly limited APIs in the name of security, and on the other hand have hard to trace security holes, like XSS.
This is what I, after years of web development consulting, now advocate.
The browser should be left for documents.
The only way to provide the best user experience and operating system integration is via native applications, regardless of the environment, which communicate via network protocols.
I guess the change in the law is significant. However, I thought that shop owners would assume that any large item would be paid for with a credit card and raise the price accordingly. I don't have any evidence for this, but, is it likely that the only effect of this ruling will be on items that are usually paid for with cash, ie those under $25 (or whatever reasonable number of dollars)
Even if Bill Gates isn't doing the best job, every time I see one of these articles, it appears that there isn't any advice on better ways to grade teachers. Did I miss that in the article? Are there a lot of other people in the field that are doing better work? (I would really like to read if anyone can provide links to papers to other ways of analyzing teachers)
The blog link to this thread is a propaganda site. It conspicuously doesn't reference any of the original materials that it is attempting (weakly) to refute.
There was an article on HN last week that referenced a more source material article about the project.
1. http://gameprogrammingpatterns.com/game-loop.html