{"id":9644,"date":"2010-10-13T11:23:31","date_gmt":"2010-10-13T16:23:31","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=9644"},"modified":"2010-10-13T11:23:48","modified_gmt":"2010-10-13T16:23:48","slug":"project-hex-part-1","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=9644","title":{"rendered":"Project Hex: Part 1"},"content":{"rendered":"

Well, I seem to have found myself with some extra free time<\/a>, so let’s put that to use and start a new project. <\/p>\n

Like a lot of wannabe developers I have a stack of game ideas floating around in my head. Some are just fragments of a game – a basic mechanic or a story hook. Others are decent one or two person projects. And some are immense pipe dreams that would require a team of people and a silver-plated eighteen wheeler carrying a diamond-encrusted vault packed with golden briefcases full of money. And Sid Meier would need to drive the truck. <\/p>\n

This particular idea has been floating around in my head for a few years and I thought I’d tinker with it a bit. However, I don’t want to start with talking about the game. Not because I’m afraid anyone will “steal” my idea. Like having “a great idea for a movie \/ book”, an idea alone is basically worthless. Anyone capable enough to use the idea is going to be too interested in working on their own stuff to worry about stealing ideas from random mooks on the internet. I don’t want to start off this series with pages and pages of mechanics and concepts. Doing so would only invite an avalanche of “but how does this part work?” sorts of questions. I might not have answers for those, the design might change once I see it in action, and I’m not even going to be working on that stuff right away. So let’s start simple. <\/p>\n

First, I need a bit of technology. <\/p>\n

What language to use? I’ve got a couple of weeks of Java rolling around in my head. I made some sort of puzzle-ish game in Java way back in 2003. I liked how easy it was. Disliked how slow it was. I’m told the speed is much better now, and the explosive success of Minecraft has impressed upon me the extreme utility of having a portable game that can even run in a browser window.<\/p>\n

On the other hand, two weeks of Java is chump change compared to a decade of C++. In C++, I’ve got a familiar development environment and I theoretically know what I’m doing. There will<\/em> be a learning curve to using Java and it will<\/em> eat time until I can transition from crawling to running. Also, I’ve got a bunch of utility code I always bring with me on a project like this. It handles the special variables and math you need when doing 3D rendering. Moving to Java would mean re-writing all of that. So what am I looking to do? If I’m honestly setting out to launch a commercial project I should probably go with Java. But if I want to tinker and prototype, then I should go with C++.<\/p>\n

I think I’m more interested in prototyping at this point. I’m doing this because I want to play around with some ideas, not because I want to blow a couple of weeks reading docs, re-writing old code, and wrestling with a new development environment. So C++ it is. If I like the idea or it seems to be heading someplace, I could always port it later. It’s more work that way, but less risk up front. <\/p>\n

(Although if any of you Java types have suggestions on where to start, I wouldn’t mind reading about that. It’s been years since I fiddled with Java and I imagine a lot has changed.)<\/p>\n

Having said that, there is some value to starting with something that’s not completely<\/em> married to Microsoft Windows. Okay, I’m using their development environment and their operating system, but in an ideal world the code I write could be taken to (say) a Mac or a Linux machine and have a reasonable chance of compiling without too much fuss. (And right away we see the cost of abandoning Java.) <\/p>\n

Jargon time: The acronym API stands for application program interface<\/em>, which is just a fancy way of saying, “some other programmer wrote some code that does stuff, here is how you use it”. It’s the interface. Think of it like the controls of a car: Gas, brake, steering. You learn the API and you can use the thing without ever needing to worry yourself about what’s going on under the hood. <\/p>\n

A good API will be easy to learn, easy to read, and not eat up a lot of lines of code. A bad API will be messy, unclear, or require you to worry about the inner workings of the system you’re trying to use. <\/p>\n

Imagine you were writing a program and Zeus poofed in and cursed you with the inability to use the plus sign. He’s always doing annoying crap like that. So now you need some external library for adding two numbers together. Great. <\/p>\n

Let’s say you get a nice API for adding numbers. You write some code to add 2 plus 5 and get the result.<\/p>\n

answer = AddTwoNumbers (2, 5);<\/pre>\n
Now the same thing with a bad API:<\/p>\n
LoadFirstNumber (2);\r\nLoadSecondNumber (5);\r\nPerformOperation (OP_SUM);\r\nanswer = FetchAnswer ();<\/pre>\n
It’s the difference between a car that works like we’re used to, and a car where you have a hundred unlabeled controls, and even starting the engine is a six-button operation. <\/p>\n
A lot of APIs suck because, statistically, programmers are not very skilled at communication.  They’re bad at organizing and simplifying information for others.  A big deal is made of the puzzle questions given to potential programmers during a job interview.  If I were screening potential candidates to work as part of a team, I wouldn’t try to bust their noggins with tricky special-case problems.  I’d just ask them to explain some technical concept for the layman to understand.<\/p>\n
“Explain a memory leak to the marketing team.”<\/p>\n
Good:<\/p>\n
“Every time a part of a program is run, a little bit of memory is used up.  Over time the computer will run out of memory entirely.”<\/p>\n
Less good:<\/p>\n
“That’s when a program allocates memory and doesn’t free it up again later.”<\/p>\n
Have this man killed:<\/p>\n
“That’s when a program iterates over a particular function or execution path that doesn’t properly deallocate objects created on the heap.”<\/p>\n
I’d rather have an average coder with excellent communication skills than a crackerjack ace who writes pages of code that only he can follow.  Sure, Ace gets done a day earlier, but everyone who has to use Ace’s code loses a day to tears and cursing. Ace is going to design an API that will drive people up a wall, like my above example where it took four lines of code to add two numbers. <\/p>\n
All of this is a roundabout way of saying that the API for Microsoft Windows is horrendous. This API is used for doing stuff like making windows, menus, buttons, scrollbars, sliders, and all the other window-ish type stuff you need in a modern desktop environment.  To be fair, bits of it are over a quarter of a century old. (Windows 1.0 came out in 1985.)  It’s full of backward thinking and systems designed with 16-bit computers in mind. It was a clunky design in the first place, and it has aged very poorly. As the years have gone on, that API has become more ludicrously byzantine compared to the other systems.<\/p>\n
One such other system is SDL<\/a>.  It’s library for making windows and such, but unlike the Windows API it’s clean, simple, and totally cross-platform.  Here’s an example of creating an empty do-nothing window in SDL:<\/p>\n
\r\n     SDL_Init(SDL_INIT_VIDEO);\r\n     screen = SDL_SetVideoMode(SCREEN_WIDTH, SCREEN_HEIGHT, SCREEN_DEPTH, SDL_SWSURFACE);\r\n}\r\n<\/pre>\n
And here is the same thing for a programmer using the Windows API:<\/p>\n
\r\n\r\n  WNDCLASSEX  wcex;\r\n\r\n  wcex.cbSize         = sizeof(WNDCLASSEX); \r\n  wcex.style\t\t\t    = CS_HREDRAW | CS_VREDRAW;\r\n  wcex.lpfnWndProc\t  = (WNDPROC)WndProc;\r\n  wcex.cbClsExtra\t\t  = 0;\r\n  wcex.cbWndExtra\t\t  = 0;\r\n  wcex.hInstance\t\t  = AppInstance ();\r\n  wcex.hIcon\t\t\t    = LoadIcon (AppInstance (), MAKEINTRESOURCE (IDI_CPICON));\r\n  wcex.hCursor\t\t    = LoadCursor(NULL, IDC_ARROW);\r\n  wcex.hbrBackground\t= (HBRUSH)(COLOR_BTNFACE+1);\r\n  wcex.lpszMenuName\t  = MAKEINTRESOURCE (IDR_MAIN_MENU);\r\n  wcex.lpszClassName\t= APP_TITLE;\r\n  wcex.hIconSm\t\t    = NULL;\r\n\r\n  if (!RegisterClassEx(&wcex)) {\r\n    return false;\r\n  }\r\n  if (!(hwnd = CreateWindow (APP_TITLE, \"MyProgram\", WS_TILEDWINDOW | WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX, CW_USEDEFAULT, CW_USEDEFAULT, SCREEN_WIDTH,  SCREEN_HEIGHT, NULL, NULL, HINSTANCE, NULL))) {\r\n  return false;\r\n  }\r\n<\/pre>\n
Gah.  And actually the Windows code might need a bit more to make it work.  But you get the idea.  The choice is long, clunky, dated, and Windows-specific vs. small, clear, and portable.<\/p>\n
So SDL it is.<\/p>\n
Great, now we have a system for making the program window. But we need a system for putting graphics in that window. This is an easy call for me to make.  My alternatives are:<\/p>\n
1) Go out and use some freeware graphics library.  There are a lot of them available. Some for Final Fantasy IV style graphics.  Some aimed at 2D platforming.  Some aimed at full-featured 3D games.  Pick one that suits your needs.  Some are “graphics engines” that only concern themselves with drawing and leave the rest to you.  Others are “game engines” and (theoretically) offer a framework into which you can drop your game logic. Unfortunately, most existing systems do not<\/em> play well with procedural content. They generally have predetermined ways of loading pre-made content from disk. I might get the project off the ground faster, but I’d spend the whole time fighting to get the graphics engine to let me do simple things. <\/p>\n
2) Use Direct X. (I hate<\/strong> the way Microsoft names things. They named their operating system “Windows”, which is like building a brand of car called “drive”.  Oh, I was driving my drive yesterday. I also wrote a program to make windows in Windows.<\/em> Madness! In this case, they gave the name “Direct X” to both the API and the graphics drivers that use the API. Arg. Note that when I say “Direct X”, I’m talking about the graphics API used by programmers to make polygons and such and not the drivers you use to make those games go.)  The Direct X API isn’t as bad as the Windows API, but it still has many of the same problems: It’s not portable and it’s exceedingly verbose.  <\/p>\n
3) Use OpenGL.  It’s clean, it’s portable.  I’ve been using it for years. I’ve written a bunch of tools to go with it. <\/p>\n
I agonize over this for three milliseconds before hitting copy » paste on all of my standard OpenGL code and creating a new project. A project which I will name Hex. For reasons that will become clear in the next post.<\/p>\n
hex_window.jpg<\/td><\/tr><\/table><\/p>\n
Huh? What do you think? Game of the year, right?<\/p>\n","protected":false},"excerpt":{"rendered":"
Well, I seem to have found myself with some extra free time, so let’s put that to use and start a new project. Like a lot of wannabe developers I have a stack of game ideas floating around in my head. Some are just fragments of a game – a basic mechanic or a story […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"class_list":["post-9644","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/9644","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=9644"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/9644\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=9644"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=9644"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=9644"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}