GamemakingMonkey-X

 Posted by (Visited 3304 times)  Gamemaking  Tagged with:
May 132014
 

Monkey-X is my current favorite language for doing game prototypes and even full projects. It isn’t at all widely known, and has more than a few rough edges, but I still find it congenial and thought I’d share so that more people will give it a try.

When I went looking for something to code in, I had the following criteria:

  • Get stuff on screen in under an hour. Ideally, under ten minutes.
  • Output to as many platforms as possible.
    • Web, because that is useful for accessibility, Facebook, demos, and more.
    • Desktop, because that’s where midcore and core gamers still live.
    • Mobile, because the whole world is moving to touch.
  • Avoid porting. Porting is tedious and expensive. Yes, you get the advantage of maximizing use of the hardware, but the fact is that there’s a lot of headroom on hardware these days.
  • A community large enough to supply libraries for things I don’t want to write myself. I am no great shakes as a coder, you see.
  • Syntax that doesn’t make my eyes cross (looking at you, Objective C).
  • Garbage collection. Why? Because I always mess it up, and then it gets in the way of being productive.

Monkey-X met these criteria, though the community is still pretty small.

Continue reading »

Jul 012013
 

I answered a whole lot of questions on Quora in the last few days, and thought I would share some of them here on the blog over the next little while, since I have been pretty quiet.

The question on this occasion was, what programming languages should an aspiring game designer learn? And the answers tended to be around things like “C++.” But I suggest a different approach to the problem.

Learning new things is hard. Programming calls for a new mindset, if you have never done it before.

Therefore, you should learn whichever one you will stick with. And that means, the one that is easiest for you to learn first. The one that will give you positive feedback quickly.

Don’t jump to C++ because you are “supposed to,” even if you are aiming at working in AAA console. Don’t jump to C# because it’s the current hotness or what Unity uses. Pick the one that you feel like you personally can make progress in.

Any good programmer will learn many languages over the course of their career. Heck, I am not a good programmer, and I have worked with BASIC, C, C++, Python, Lua, modern BASICs like Blitz (three members of that family so far), three homegrown scripting lnaguages, JavaScript, PHP, and Java.

Pick one that is easy and cheap to get started in. It doesn’t need to be powerful, because you don’t know how to use that power yet. Instead, what you want is something that will let you get a picture on screen very quickly. When you are starting out, positive feedback is the hardest thing to come by, because you suck. So you want a language that will make iteration fast and your failures obvious, and your success gratifying to you.

Don’t worry, you may graduate to a language with greater complexity and power. (You may not… designers don’t need to be great programmers. They need to be able to try ideas out).

So high level languages will work best for a beginner. I would try out things like

  • Gamemaker
  • Flash
  • One of the versions of Lua with a simple graphics library. I used to use one for PSP homebrew development that had a simple API like “screen:draw(“picture,jpg”). That is the level of complexity you want.
  • Same goes for one of the versions of python with a graphics libray.
  • One of the many BASIC variants aimed at indie game developers: BlitzMax, DarkBasic, whatever. I am currently using Monkey, a cross-platform language by the maker of Blitz.
  • If you have an iPad, a neat Lua variant is Codea – you can code right on the iPad! I’ve used it for a couple of prototypes. There are similar apps for Python, and other languages.

Remember, your first game is going to be on the order of Hangman, Pong, guess the number, not Uncharted. You want a “toy” language, as the pros will derisively call these., because you want to play around.

A lot of your game development heroes started out with MS BASIC.

Game talkSome times you should write new code

 Posted by (Visited 4615 times)  Game talk  Tagged with: ,
Jan 072012
 

A fair amount of folks have taken the last few posts (on making games more cheaply and on rigid programming philosophies) to a bit of an extreme further than I intended. So in the spirit of contradicting myself, here are some good reasons to write new code.

When you have something new to learn.

I still remember how proud I was when I independently invented the bubble sort in response to a problem. Then how baffled I was when I tried to figure out how quicksort works.

Writing your own version of a known solution is a fantastic learning tool.  Trying to learn how to write jazz progressions? Grab a jazz song, change the key, and start modestly tweaking the chords (an 11th into an augmented, or whatever). Then build your own melody on top of it. Trying to learn how to draw? Start copying people who know how. Trying to figure out how a given game genre works? Try cloning or reverse-engineering a game in that genre. It’s a classic method of learning and there is no shame in it. If you have any creative spark, you’ll quickly move past this sort of journeyman work and start adding your own elements to it. (This is one of my caveats to Dan Cook’s post on game cloning).

Continue reading »

Game talkMy biggest coding takeaway

 Posted by (Visited 7635 times)  Game talk  Tagged with: ,
Jan 052012
 

Rigid programming philosophies are the devil.

Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

So take everything I am about to say with the appropriate grain of salt.

Continue reading »