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...
[Rep]

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

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

/ DDNI volunteers to beta test!!
[Rep]

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!
[Rep]

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.
[Rep]

Translation: Java Sux. :-)
[Rep]

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 :-)
[Rep]

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 :-)
[Rep]

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.
[Rep]

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 :-)
[Rep]

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

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?
[Rep]

Is this a PC game?
[Rep]

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.
[Rep]

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?
[Rep]

Last Ninja
[Rep]

nope :-) But I like how the hints are being read. Please share all the information you have gathered to get to that conclusion StrategyGamer.
[Rep]

Well 'laffer' (bold letters in post 13) and isometric perspective strongly hint at Last Ninja :-)
[Rep]

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 :-)
[Rep]

arghhh, the suspense in killing me :-)
[Rep]

Okay now we have to decipher this :-) :-)
[Rep]

Well it does me good that so many people take the time to read my long posts, even if the topic is not exactly for everyone :-) I am running out of things to rant about without becoming too technical though, but I do had some fun writing this. Perhaps for my next project I will do the same, only I will put more effort into the hints. It is a fun little game :-)

I would examine post #4 more for the hidden clue. It is in there twice.
[Rep]

It's a bit cheeky to post a guess without explanation but what the hell... Gauntlet III ?
[Rep]

noooooo, way off :-)

Alright, if people do not guess it after this one I am going to flat out say which one it is.

The original Amiga game had serious flaws in the gameplay and had big performance issues, which the version for the first original system did not have. So the Amiga version was a very bad port, only with better graphics.

Come on StrategyGamer, you must know it :-)
[Rep]

It's a System 3 game isn't it?

Myth perhaps...?
[Rep]

yes it is :-) Well done reading the clue, either or the two of them :-)

But the biggest clue was that the game is isometric and myth clearly isn't, nor does it have any blatant issues. Also remember that I am a huge git.
[Rep]

Hey gimbal, i like your long posts btw!
I made some cool stuff in X3D but i lacked the programming habilities to go further, and the guys from Web3d Consortium take so much time to standardize new stuff that most people just lost interest. So i´m in a kind of sabbath vacations...:-)
Btw have you ever considered Xj3D?
[Rep]

Xj3D??? No, I don't think I would ever consider that :-) Besides, I am more comfortable doing 2D in a true 2D environment, even 3D isometric games (which are only fake 3D anyway). Call me old fashioned, I just like pushing pixels in stead of polygons.

But thank you for your nice words!
[Rep]

*sigh* if it's LN2 then I incorrectly took you at your word regarding subtlety.
[Rep]

I should have mentioned I'm a git earlier :-) Yes you are correct OddBOd, the game actually is...

LAST NINJA 2

Sorry StrategyGamer, you were really close but I didn't want to make it that easy :-)

The game with horrible slowdowns, terrible jumping, a lack of sounds, stupid combat, even more idiotic enemies and very harsh punishments when it comes to making a mistake. Some improvements I aim to make ( + = I already did it)

+ every action is bound to a key in stead of to an insane joystick direction + button press. The game has keys for punching, kicking, picking up things/activating them, rotating items, rotating weapons and jumping. Special weapon attack moves will still be done with a combination of pressing the punch key and an arrow movement.

+ movement orientation is changed a little. For example, moving forward is now straight up in stead of moving diagonally (left+up or right+up). I think this works more intuitively. When moving in the opposite direction you still walk backwards.

- better AI and enemies may even roam from screen to screen if I allow them to. Enemies will have behavior patterns, like being aggressive, protective or simply whimpy. They may change their pattern even, for example they may go from aggressive to whimpy if they have only their fists and you come at them with a sword, or the other way around if you punch them relentlessly.

- enemies are dead after killing them once, no resurrection madness

- either health pickups in the form of hamburgers, or slowly regenerating energy. Don't know yet exactly.

+ fixed the damned jumping. I even split jumping into two modes; if you stand still and jump then you do a shorter and heigher jump, if you run and then jump you do a lower and farther jump. More realistic that way. I may add backwards jumping also, which will only be a short jump.

+ add a story mode with comic like text balloons. As said this is optional.

+ added 'active texts', simple words that appear above the heads of actors when "something" happens or changes. When an enemy spots you for example a "!" might appear above his head for a few seconds. Other possibilities are "flee!", "aggro!", "thinking...", "kill!", etc.

- falling in water or off a cliff does not kill you outright, it will reduce your energy in stead. The height you fall determines the amount of energy you lose, so if it is too high you may still die.

- climbing is more forgiving, the ninja will automatically put a weapon away when climbing down for example, in stead of just stupidly falling.

- better combat. I don't know how exactly yet however, but I aim to make it less mindnumbing. I was thinking about adding combos, knockdowns, sneak attacks... Enemies may have an 'aggro' effect where they do a knockdown attack if you do not move away quickly enough. Lots of possibilities to consider. I have to be careful, because by assigning keys in stead of joystick movements it is now only too easy to keep attacking relentlessly.

- I was thinking about adding a feature where you cannot simply walk into water, the ninja will take a step back one time when you try to. If you do it again... splash.


Not everything will be in the first tech demo, just enough to see what the new additions feel like.
[Rep]

(if you have ideas of your own or are absolutely not agreeing with one of my suggestions, please let yourself be heard right here :-) )
[Rep]

since I'm home again since today (sob sob) (and relearning how to use my own keyboard, been using the rediculous Spanish layout for five weeks!) I hope to release the tech demo within the next week. Need to flesh out a few more things, but I'm going to leave some quirks in there so other people can give their opinion about them.

First of all, here is the basic project page I have for all my projects:

http://www.xs4all.nl/~gimbal/projects/ln2.htm

And I have four screenies of the editor to show you the current state. I can show screenies of the game, but I think everybody here has a fairly good idea of what the game looks like.

Image

This is a basic screen. On the left you see a bar with all the items you can place in the level. The editor will sort them by depth based on their position. In the top-right you see a very uninformative area which holds the items that are actually already painted. It gives a unique ID that is used to for example match a key to a door opening event. The checkbox allows you to make an item visible or invisible; if an item is saved as invisible it is actually invisible in the game as well, but can be made visible programmatically (in an event).

Image

This shows the same screen only with the collision boxes visible. You can draw them, edit them and delete them from within the editor. Different colors have different meanings, the red ones are simple 'block' boxes so you cannot go past that point, the light blue one represents a screen change, if you touch it you go to a different screen. As you can see it can become quite a chaos, but this is actually one of the more complex screens in the game to do. Other screens contain far less boxes. I am not done with this screen yet, I need to slice more foreground items from the background (so you can move behind them) and tinker with the collision boxes.

Image
Simple enough, this allows you to select a different screen to edit from any level. It only shows the background image without any of the foreground images.

Image
This screenie is really uninteresting, yet it is the most powerful function of the editor. Because the editor and the game are basically the same code, you can start the game from within the editor on any screen you want. You simply select the entry point in the screen and run it and voila, the game starts instantly with the ninja in that position. in the future I may need to make it possible to allow the selection of what items you want to start with, or you may not be able to properly test some screens.

As you can see the editor is quite primitive and user unfriendly at the moment, but for now it is sufficient for only me :-)
[Rep]

alright folks, LN2 Tech demo 1 is up and downloadable here:

http://www.xs4all.nl/~gimbal/projects/ln2.htm

The default keys are also listed on that page, and I made a list of what I think is still wrong with it. It is far from perfect, but I got it to the point where I think it runs very decently. Also there are no enemies yet in it, that is going to be tech demo 2 stuff.

Be sure that you have Java 6 installed and to run it on a flavor of Windows. Linux could also work, but I simply cannot test it (yet). The game uses no 3D, so any graphics card should work, including crappy intel chipsets.

Try it (only the first three screens for now) and tell me what you think. Be brutal :-)
[Rep]

Can't wait to test it :-)
In about 1 hour I'm home and tell you all the bugs :-) :-)
[Rep]

thread title changed per request :-)
[Rep]

Sorry gimbal, but the version wont start at all for me :-) I get a window which is completely black. I waited for over a minute and nothing happened. I thought my JRE might be too old, so I updated it and run the test. Here's the result :

Image

I noticed that the soundpack is missing in the archive (found this in the gameconf.xml '<soundpack>sp_dd2.zip</soundpack>'). Could that cause the problem?
Can someone else check if the game runs on his PC?
[Rep]

nope, the soundpack is disabled because I don't have one yet, and there is nothing in the game that plays a sound yet.

TCD: could you try this. Open a command prompt, navigate to the directory where you installed the 'game' and run this:

java -jar ln2.jar

and see if that produces an error.

The strange part here is that I tested this on a laptop that is quite shitty and it worked flawlessly :-)
[Rep]

Yup, produces the following error :

Image

I tried to redirect the output (pipe it with '>') but Java still writes to the console window :-) Seems like something is missing in the jar.
[Rep]

Eh? Do you have the 'lib' subdirectory??? It must contain two files, ln2res.jar and xom-1.1.jar. Java is complaining that it cannot find a class inside the xom-1.1.jar file.
[Rep]

:-) Bloody zip format. Sorry, I just drag and dropped the files in one directory and didn't look at the folder structure. Works flawless now. Gonna eat something and test it then :-)
[Rep]

*whipes sweat off forehead*

No worries, I will get the 10 years back that I just temporarily misplaced. No permanent damage done.
[Rep]