LN2 tech demo

[gimbal]

Hi yall. I thought I would change the mold of spamming an incredible amount of information about my latest project in one post and in stead keep you all guessing a little about what the hell I am up to, as well as letting you all guess what game I am working on I would be the last person on earth to write in a blog, but this is going to mimic the style a little I'm afraid.


ABOUT MY PREVIOUS PROJECT

My last idea for a game was the TwinTris project, which I had in an advanced stage already. The idea behind that game was to be able to make it run on both a regular windoze machine and a pocketpc/smartphone. I have abandoned my ppc game development efforts however, since it was seriously pissing me off. It is a typical MS environment, no clear standards so every pocketpc is basically different and for smartphones it is even worse. To make games work on most devices out there you need many, many device specific hacks and I simply do not have access to different devices to test on. To hell with all that. Maybe I will pick up the game using Java in stead, perhaps even turning it into an applet so you can play it online.


AND SO MY CURRENT PROJECT BEGAN TO TAKE FORM

I was looking for a new game to develop that would be useful and not create any copyleft problems. Some of you may have read that I was playing with the idea of doing a multiplayer cannon fodder. I decided that creating a networked game is not within my reach yet for the simple fact that I need a good testing and debugging environment for that, with many people testing the multiplayer aspect so it can be fine tuned to perfection from the very start of development. Also, the use of the name would probably lead to some problems. I needed something simpler, something that I could accomplish on my own, or at least the beginning of it.

Then I started to get interested in a little Amiga game that was mentioned many times in this forum that I knew I could improve upon in many ways. Doing remakes is fine, but I really like how for example JOTD tries to improve the originals and add a little more fun and value to the game. I could do that with this game. However, there was one big problem: the game plays in a way that I have never programmed before and is quite complex technically. Would I be able to get it done?


THE STRATEGY: BUILD A TECH DEMO

That is when I decided to not do the game, but do a tech demo with which I could prove that I could do it. That tech demo is what I am going to release to the unsuspecting public sooner than you might think, because I have proven to myself without a doubt that I can do it. I have seen it move fluently, I have made many improvements and fun changes to the original already, the collision detection is awesome, the tech demo supports in-game events that can be specified from within the tools and the tools themselves make my life a lot easier.

The thing I am doing now is filling the holes, implementing those last things that are left to do. For example: I want a basic enemy AI in the first tech demo that will improve with further releases. Also I am doing a little fine tuning, because the screens are still hard to implement and my first stab at it might not be the most efficient way to do it. By the way: the first tech demo is going to include the first three screens of the game, an easy start for me that still shows the potential.


Stay tuned for more...

[DDNI]

Hmmmm.... Intriguing! What could it be???

I hope the "copyleft" lawyers dont bog you down though!

/ DDNI volunteers to beta test!!

[gimbal]

IT ALL BEGINS WITH...

An idea of course, but my project began with the development of the game editor. Since JOTD has dropped his good work using Java and has switched to the more "standard" C++ side, I am continuing his legacy by building this game in Java. The editor I had to build from scratch, since the game is anything but tile based so I couldn't use my own mapmaker (sob sob).

The first iteration of the editor was finished in less than SIX hours. With MapMaker I learnt all the tricks of the trade and I could use a lot of code again. And the editor would be only for my use, so I didn't have to make it that pretty and I didn't have to make it intuitive to work with either; the editor expects all data files in a specific structure on disk and then I point it to it so it can do its magic. The editor and the game work on basically the same code, making them fairly tightly integrated.

(I will improve the editor so it is more user friendly, so possibly other people could contribute to this project should they want to)

However, while developing the tech demo I soon discovered that the editor in its current state wasn't working. The editor allowed me to place static screen items at 2D coordinates on the screen, plus special markers (player screen start positions, enemy start positions, waypoints, etc.).

Watch out for the big clue here.

However, the game is isometric, meaning that the character moves around in semi-3D. Actually it is all 3D because I use X,Y,Z coordinates, just not the way you would expect them. X is from the origin to the top-right of the screen, Y is directly up and Z is from the origin to the top-left of the screen. The origin in my case is the center-bottom of the screen.

So what is the big problem? It is insanity to mix two coordinate systems, especially since it is only possible to convert from one way to the other (3D to 2D). So I changed the editor so that all items were placed by moving them in isometric space.

Then came the second biggest problem: depth sorting. How do you know that your character is in front or behind a 2D flat object with no depth information at all, while the scene is actually in isometric 3D? Well I decided on a solution that works quite well; the character you are controlling is human. I selected four points in the feet of the character, for each of the four orientations that he (or she) has. I check these points against the objects that the character is overlapping with; if one of the foot-points is touching the other object, the character is behind it. Of course transparent space inside the images is ignored.

Then the third and last big problem: collisions. While the depth sorting is done in 2D space, the collision detection can only be done in 3D since there is perspective in there. Even though the on screen items are flat and have no depth, the depth should be faked. The solution: isometric collision boxes. I can draw them using the editor, stretching them as far and wide as I want. Each actor in the game also has a collision box surrounding his or her feet. I do a very simple comparison between two boxes to see if they are touching. By controlling the depth of a collision box around a static object on screen, I also control the depth of that very object. And so I turned a 2D object into something which appears to have a depth.

To see this in action, this is the reference I used to learn how to do all this stuff. This is in flash (and it has nice demonstration examples), but it is very easily translated to other languages:

http://www.kirupa.com/developer/acti...transforms.htm

and

http://www.kirupa.com/developer/acti...ic_hittest.htm

One problem I had was to find the correct isometric angle for my game. This tutorial assumes 26.5 degrees which happens to align perfectly with on screen pixels, but through trial and error I found out that my game needs an angle of 14 degrees.

The collision boxes give me many more possibilities. I define a number of different types of boxes. I am not giving away too much details here because it would become very obvious which game we are talking about, but lets say that I could define a box to be of type SCREEN CHANGE; when the character touches that box he will go to the screen that I assigned to that specific box inside the editor. You can imagine that using other types of boxes I could make the player climb, fall, swim, start an event, etc.

More details later!

[gimbal]

PROBLEMS PROBLEMS

Of course a project with unfamiliar technology (isometric view, game programming in Java) will create some problems. The most interesting one I ran into was at the very core of every game: the main game loop.

It is all about timing. You want to update and draw your game every N times a second, for example my game draws at 50 frames per second, which means that every 1000 / 50 = 20 milliseconds a new frame has to be drawn, meaning that all the work to produce a new frame has to be done in less than 20 milliseconds. Now this isn't much of a problem since the game is for the most part 2D and computers are lightning fast nowadays, but you still need a measurement of time; the game needs to do work and then sleep until it is time to do the next frame, otherwise the CPU usage is 100% (or 50% on a dual core), creating a nice warm temperature in your room, not to mention more work for the ventilators.

Then you run into a problem under Windows; the timing logic that Java uses produces a high latency under this specific OS! MacOS is fine, Linux is fine, but under Windows the method to check the current time will return values with intervals of... about 16-25 milliseconds! This means that when you call the function to get the time, like this:

time1 = System.currentTimeMillis();
time2 = System.currentTimeMillis();

And you would do

passedtime = time2 - time1;

you would expect passedtime to be 0, far less than a millisecond. But in stead it will be 16 or higher. Conclusion: it is IMPOSSIBLE to do accurate timing for a game loop using this method, leading to framerates that differ from system to system to system. On my own system it worked fine (dual core intel), but on the laptop of my girlfriend for example the animation varied between going way too fast to being simply choppy.

But Sun introduced a new way of getting the time in nanoseconds in stead of milliseconds since Java 5. Problem solved? Nope, because this way of timing is bugged on AMD dual cores, producing unusable results. The only way to fix that is to install a patch on the system itself that makes a change in the bios I believe.

So what then? Well the solution is to go native; I wrote a simple DLL using C that provides a timer function to my game that IS accurate; this DLL is of course only used when running the game on Windows, under any other OS the timing function of Java works just fine so I don't need to build libraries for each specific OS.

Problem solved? Yep, at least on the 3 system s that gave me shit before.

[StrategyGamer]

Translation: Java Sux.

[TCD]

I would rather translate it to : Maybe Java isn't (yet) the right platform for fast paced action games
But then again I guess gimby will prove me wrong

[gimbal]

why not? I fixed the problem so I can easily use Java without problems But you all are not seeing the true point of these posts, I am giving out silent hints That being said also, you are not reading the hints properly TCD, I never hinted at it being a fast paced action game!

And I don't need to prove you all wrong, JOTD already did. Like I said, I am only continuing his legacy

[Minuous]

Actually, I think the problem in this case is more Windows-related than Java-related. For example:

"Windows NT: The default precision of the timeGetTime() function can be five milliseconds or more, depending on the machine."

It's better (as most things are) under Win9x but still only 1-millisecond resolution, there's no way to get microsecond resolution like you can on the Amiga. Knowing Microfilth they probably have an undocumented equivalent function that works better.

[TCD]

When coding native Win32 or 64 apps you should definetely use high-resolution timers. Java isn't native, but is able to use the same functions in it's Bytecode interpreter. So maybe it's a problem with Java on Windows, but not with Windows itself

[Toni Wilen]

timeSetEvent() + timeBeginPeriod()/timeEndPeriod() have about 1-2ms resolution under XP and Vista (probably under win2k too)

[gimbal]

That is exactly what my little DLL does, and it uses timeGetTime() to get the actual time. The dudes at Sun can do exactly the same as I do; I guess the reason they (still) have the old quirky timing code in their Windoze implementation is that the high resolution timing was supposedly not available on all Windoze versions (95 perhaps?), but I don't even think the latest JVMs run on those old versions anymore, so they COULD theoretically change the implementation now to fix it...

But then another evil that they really take seriously to the limit of sanity rears its ugly head: BACKWARDS COMPATIBILITY. They will not change the way a method, that is so widely used and has been present from the first horribly inefficient implementation of Java, behaves. Period. I have to agree with such policy from a business application perspective, but for multiplatform gaming (or other time critical application) purposes it sucks But heck, the workaround is so easy anyway, why bring out the pitchforks and torches?

[Cammy]

Is this a PC game?

[gimbal]

BACK ON TOPIC

Problem solving is the core of programming. You are not mindlessly jotting down endless lines of code, you are ever and always solving problems. Programmers are not programmers, developers are not developers, they are all problem solvers. Programmers just solve smaller problems than developers do.

So developing a game is exactly that: the solving of a big pile of problems that results into a playable solution. So when you are doing an improved remake of an Amiga game, what are the basic problems you have to solve? In my opinion naturally.

1. get the original assets (graphics, sounds) or make new ones.

I am not a graphics designer nor a sound or music composer, so I have to make due with the originals. For the game I have chosen this is easier than one might think. WinUAE (all hail Toni!) and photoshop to the rescue; using screenshots and recorded videos provided by WinUAE make it easy to grab statics and animations and photoshop makes it easy to extract sprites and bobs from the screengrabs. It is a lot of work of course, but I find it a good thing to keep me busy while I am in no mood to do other things. The particular game I am working on has a special way of displaying its screens making it exceptionally easy for me to grab the statics, even when they are obscured partially.

As for music and sounds: the music I could download as mods and the sounds... well there aren't any really. Its one of those games that would use too much memory with sounds included I guess. It is an oldy, so it probably had a 512k limitation. One of the improvements I have added is that of soundpacks; you can provide your own sounds if you want, easily configuring the game to use it. The game will come with a default set of sounds that I think fit very well, taken from other existing action games.


2. build the levels/screens/etc.

To remake a game, you need the same content. You could use the original data files if you can reverse engineer them; I am not so gifted so I play the game with a trainer and I use the excellent save state function of WinUAE. Screengrab and my editor does the rest, with my help of course.


3. make the game (and the tools)!

Graphics, sounds & music, level design, programming, testing, marketing, story script. There are a lot of slices on the "game development process" pie chart and each deserve an equal slice in my opinion. Programming, although quite a big task, takes up only that tiny slice of the pie. Luckely doing a remake that I am not going to sell removes a lot of slices, leaving me only... programming. However, the original game did not really have a story (like a lot of older action games), well I am adding one. The game even has speech balloons now. They are optional however, if you want the game in its original storyless state to keep it moving quickly then you can have that.

The actual programming is easier than starting from scratch; there is an example to copy from. In stead of trying to code new things, you try to code it the way it worked in the original. However, the original had some pretty big flaws that I have fixed to create more fluent gameplay; hopefully it will be more fun to play. I know one person in this forum in particular who will be the judge of that.

[Minuous]

OK, I think I know what game it might be based on your hints. (Although you say it is an "action" (ie. arcade) game and the one I have in mind is not.) Am I allowed to guess?

[StrategyGamer]

Last Ninja

[gimbal]

nope But I like how the hints are being read. Please share all the information you have gathered to get to that conclusion StrategyGamer.

[TCD]

Well 'laffer' (bold letters in post 13) and isometric perspective strongly hint at Last Ninja

[gimbal]

That is true, I knew when I saw my post that this would be a very easy conclusion to make But there is more to find in these posts, some more subtle hints

[Shoonay]

arghhh, the suspense in killing me

[TCD]

Then I started to get interested in a little Amiga game that was mentioned many times in this forum that I knew I could improve upon in many ways. Doing remakes is fine, but I really like how for example JOTD tries to improve the originals and add a little more fun and value to the game.

Okay now we have to decipher this