Game Development

Hosting and payments done

I figured out a host provider for my game server this morning. I also figured out how to and selected a provider so I can accept credit cards over the net. Because of the per-transaction charge I’m going to shoot for recurring billing every 3 months, rather than every 1 month. It doesn’t sound like much but this is a problem that has I’ve been trying to resolve for weeks now.

With this out of the way I can hopefully spend more time on game development.

Game Development

Cancelling paypal

I was going to go with PayPal for recurring billing because they have a powerful API and are relatively low cost. But after reading this The PayPal Fiasco I decided this was a very bad idea. PayPal could shut me down anytime they wanted, for any or no reason, and keep all my money. I would be basing my entire business on the mercy of a third party that doesn’t care about the success or failure of my business and in fact has self-interest to see that I fail. My alternatives are a lot of trouble but so far the best seems to be Payment Online. For some upfront fees they have the lowest rate of 30 cents plus 2.15% per transaction. The company looks professional and they offer APIs that seem to do everything I want.

Game Development

GDD, feature implementation spec, normal mapping

I wrote out a 26 page game design doc yesterday. Although I’m practically the only one reading it it helped a lot because it turns a loose collection of ideas into something cohesive and developed. I was able to resolve several design problems by doing it. A nice effect of writing it is I was able to put down every creative idea I had without regard to implementation details. When I think of stuff I usually also consider how well it fits into existing code, which limits my creativity.

The game design doc also helps because knowing what features I’m going to have, I’m able to write a list of exact features I need to implement. This means I can do specific implementations rather than loose and vague concepts where I’m not sure what I need. It makes things MUCH easier without really losing flexibility since I still program flexible interfaces where it will have obvious use.

My first pass at the programming feature list was almost pointlessly high level and glossed over all the potential problems. So halfway through I stopped and went over again, forcing myself to think of where I would actually begin coding. That made a tremendous positive difference. Doing this, I am solving difficult programming problems in minutes in my head as compared to hours of refactoring code. Additionally, I think of unforseen features and find better ways to implement them than I would have otherwise. One example is that I was originally going to write a physics editor out of context. Various editors that needed physics would load a predefined physics file. Upon review, I found that without context it would have very limited use and that furthermore I need the same editor for both the ship design, weapon design, and base design screens. Making that change substantiallly changes how I was going to design all of these elements and I wouldn’t have done it if I had already started coding.

Lastly, here’s my first render of a ship using normal mapping.

Normal mapped ship

Game Development

Progress report

This weekend I finished the fundamental properties of the particle editor. This includes an interface to the GUI system and of course the ability to display particle.

I have a model viewer working as well, which I am going to convert and expand to a material editor.

Save and load isn’t implemented for either one yet because it would be pointless to implement it without knowing the specs of what I need yet.

Fortunately, it’s been 10X easier and faster to write my second editor, the material editor, than the first one since all the GUI elements are already debugged and working. So it may be done as soon as this week.

In other news, Novodex didn’t respond to me. I guess they don’t want people offering them business?

Game Development

Newton revisited

The primary way Newton is used is to use basic primitives and place them as an overlay with the 3D model. The primitives are triangles, cylinders, boxes, and similar. You can also create a convex mesh but the documentation said this is much slower and more memory intensive.

What I was originally looking for was a physics library that just worked with any arbitrary mesh.

Once I found out Newton can’t do that I had 3 unappealing options to choose from.
1. Write my own physics editor, that would let designers create a physics model using primitives and materials.
2. Force all ship designs to be convex and accept the memory and speed hit
3. Write my own physics

I could always switch libraries to something more powerful of course. Novodex is the next step up but they are not free. I contacted them but if they ask more than a few hundred I can’t use it. Considering it is one of those libraries that don’t show the price I’m assuming it’s a “If you have to ask, you can’t afford it.”

Out of the three options I think #1 is the only thing that can achieve my requirements for both gameplay and design. I was really bummed out at first since this puts the schedule back a week but at least I discovered this early on.

If I’m lucky Novodex will get back to me with an offer I can use. I’m pretty sure a library that powerful would have a built-in editor into 3DS Max which will be far more than anything I come up with.

Game Development

Physics Engines

I expected to get a lot done today but I’ve been sick so progress is pretty slow. Anyway, I’ve been looking at physics engines. I found 3 right away: ODE, Tokamak, and Newton Dynamics.

ODE was my first pick but the included projects wouldn’t compile. Faced with potentially several hours of getting it to work, I checked around and it didn’t seem like anyone was using it. The project has not been updated for a year and a half. So as much as I like open source I moved on to Tokamak.

Tokamak looked very promising from the webpage. But on download they only offer DLLs.

Newton Dynamics looked competent and the projects compile. The documentation is about what you’d expect for a free library, if you had low expectations. The samples are interesting but much less impressive than what I’ve seen in commercial libraries. This isn’t necessarily a failing of the engine though. I like that in the documentation the author points out the same principle that I follow: an API is supposed to be a black box. He demonstrates his principle in the distribution – there is only one header file and you have your choice of DLLs or static libraries.

As usual it took a significant amount of trouble to get my behemoth of a solution compiling. Total time spent was only about an hour though, which is far better than certain other libraries.

When I feel better I’ll be back to try out some physics in action.

Game Development

Open letter to API authors

When people download your API, they don’t care about your API. They care about what it can do for them in the context of getting their game done. This means that they don’t want to have to read or change the source to compile. They don’t want to have to search Google for a single minute to get around compiler or linker errors. They don’t even want to compile the binaries. They want to add a few header files, a binary, and compile straight away in any configuration. If any special settings are necessary, they want those settings to be immediately and obviously apparent available in the manual. The settings should be as clear as possible, with screenshots and exact names when appropriate. It should work the first time and by work I mean do what the user thinks it should do, not what you think it should do. Lastly, it should not force them to change a single line of code in their program. They should add your code, not modify their code to fit the way you think code should be designed.

You think people don’t mind checking the source? In RakNet I’ve had people bitterly report problems that could have been resolved in 30 seconds by looking at the source. Let me be clear: When people complain about problems in MY api you know it’s obscenely simple stuff because I hide the complexity. You, unless you are the author of Irrlicht, probably do not. I’ve had people complain about not being able to compile in Dev CPP. I, who had never used it in my life, was able to compile my library in 10 minutes. From that point on I included a Dev CPP library in future builds. When I forget to update the library, people complain although the mistakes are trivial to fix, such as a file that no longer exists. People DO NOT like to spend time resolving problems getting your API to work, nor should they.

Given the kind of user I just described, imagine giving one of them Open AL and telling them to use it in source code format. There is no function level API documentation. There are no compiler instructions. It won’t compile unless you include the exact specific files, with no way to know which files they are other than trial and error. You then have to change the code in 3 places, trace through the source to resolve a crash, set a preprocessor definition, and manually call DLLMain code, either by modifying the source or writing a new file to do it. Lastly, you have to resolve a DirectX GUID dependency by including dxguid.lib, something not clear by from the errors that come up.

Don’t even bother writing an API if you are not going to make it user-friendly. If you’re going to cost your end-user time to use your library, they will just use something else.

Game Development

OpenAL resolved

I resolved the bugs with OpenAL
– They initialize global variables in DLL main – which isn’t called if you use a library or source.
– They include mutually exclusive cpp and c versions of 3 of the same files. All the cpp ones do is call the C ones in some #define so not only was it an pointless thing to do but made it so if you included both it wouldn’t compile with very strange errors.
– They changed it so you can no longer check for errors after querying the device but before creating the context. I think this is actually a bug, since querying the device is something that should potentially return errors.

I’m honestly curious as to why people knowingly release APIs in complex configurations that cannot compile in other configuations. It could be that they don’t know, but I think this must be something people complain about a lot. It could be that they think people won’t mind fixing it. Possible, but it’s non-trivial. I had to create a new file for example to call the DLL main contents in a constructor and destructor. I imagine novice users would complain continuously and give up shortly thereafter. It could be they don’t care. Maybe they don’t have professional pride in their work because it is open source.

One good thing about Microsoft is the projects they release actually load and build in different configurations.

Game Development

Documentation? Who needs it?

So here I am, doing what I usually do on my game. You get two guesses:
1. Adding features
2. Screwing around with compiler settings, trying to get third party libraries to work

If you guessed 1, you haven’t read any other posts on this blog.

So this time it’s Open AL. Back with version 1.0 I got it working quickly and with a minimum of hassle. I updated to 1.1 it’s like they purposely made it hard to compile. ONE API has FIVE projects, two of which are DLLs and 3 of which are static libraries. There’s no documentation on why there are 5 projects or what they do but who needs it when you have such descriptive names as “ALc”, “ALu”, and “ALut”?

After like an hour I got the damn thing compiling to a library, only to find out that it crashes every time I run it somewhere in assembly code. So I give up on libraries and just try to compile the source. Burn past about 100 warnings, get it compiling, and still crash in the same spot.

I’m still working on it. I’m just happy there is only one more third party library to deal with: Newton Physics. Hopefully that won’t be too bad. I wish more people took a lesson from the Irrlicht author and actually designed libraries in a meaningful robust fashion and include documentation.

Game Development

Irrlicht is well-written

Irrlicht is the first library I’ve ever used where
1. I feel all features are useful
2. I’m able to mod it without a headache
3. I can use the library directly, without feeling like I need to make my own wrappers.

With no other graphics library would I ever consider using their input library. Originally I was going to find something cross platform too. But for the heck of it I took a look at what Irrlicht does and it’s actually quite simple, sensible, yet does everything I need. It doesn’t force me to use strange design architecture and ties in well with their whole system of gui elements, cross platform capabilities, and event notification.

I was able to mod the file loader quite easily. Everything I needed was straightforward, in a single file. When I was looking at Torque before there were so many files that did so many things I got depressed just thinking about it.

Lastly, all the functions I’ve seen so far are powerful and simple. I remember when I used Ogre one of the first things I did out of the tutorial was to make a wrapper for the camera, since the camera was too low level, with many unnecessary functions that still somehow forced you to use a certain design paradigm. Sort of like MFC…

The author’s code is readable, clean, and well-documented. No Hungarian notation at all 🙂

Good job!