the Magicball Network Forums

the Magicball Network Forums (
-   Little Script Adventure (
-   -   Main Discussion (

David 2009-07-02 20:19

That's the point, I don't know if it's worthwile. Why not make things easy and create a complete game ?
Here is the question.
Also we are not professionals (well me first !) It's all amateur work.

Kitarii 2009-07-02 20:29

Well I think the people that can use this program will be perfectly able to deal with the third dimension, and certainly the end result (if done well) will be more impressive. Perhaps you could first do the two dimensional engine; how difficult would it be to continue working and add the third later on?

David 2009-07-02 20:45

Should be awesome. Starting simple, and adding stuff in the future like slopes, scales, multiple levels, lifts, platforms etc... I think everybody will agree with that.
If I see many level designers ask for it, I'll add it.
by now, let's see if we are able to make some maps and their script.

David 2009-07-02 20:55

I remember playing Zelda years ago on gameboy during hours and hours, and game engine was surprisingly basic !!

Kobold 2009-07-02 21:04

Yes, but we're talking about LBA here. The only somewhat flat place I can remember in the game is Desert Island. By removing a third dimension, you would make this engine like the early 2D top-down games. But I don't see the connection to LBA. :?

Jasiek 2009-07-02 22:44

Well, one thing we won't be able to make will be the "catwalk" above the entrance to the harbour, also the grass above the place where the robot is will not be possible. Not to mention whole level parts where there are floors on top of each other, like the Citadel and the Library. There's just too many places like that in regular and simple lba maps to not have it. Elevators are also an essential lba thing, used for sewer entrance among other things.

Imho, getting that done in the beginning should be better. It's better to have all the basic stuff worked out in the beginning. It's a crucial part of lba gameplay.

Rincevent_123 2009-07-03 10:47

Personnaly, I would not mind not having lift.
But I think at least you should be able to handle stairs and ground going up/down.
With that you could already enable lots of possibilities and it should still be fairly easy to program path finding.

Darkflame 2009-07-03 11:21

Actualy, I dont think a lot of the elivators that go just up/down will be a problem; Once twinsun is standing on them, its effectively just an animation isnt it?
No need for any true z-scripting there, just a "elivator goes into the ground" animation, which would cut to the next scene.
So "true" z controll ver scripting isnt needed there really.


Originally Posted by david38 (Post 383991)
the problem is not collision detection, but path finding (AI), platform mechanism, scene description, and actually game scripting in general.

Pathfinding shouldnt be a problem, just ignore z untill it comes time to draw the sprite then work it out the same way as the player.

So the scripting deals purely in 2D, but as a last step the game engine checks for vertical alignment.

The only issue I see would be if there is a ncp on a different level to twinsen, then you might get false positives as to collisions etc, as it only checks in 2D.

oh, and saving the game would need to save the current z-axis too, else you might magicaly pop ontop of objects you were under.

But cant we simply avoid those case's ?
There isnt many bridges in LBA, we can simply not have enemys in those locations.

Of course at the end of the day this is your engine, and you should do what feels best (and keeps you interested!) but if possible its best to build as much flexibility into the engine at an early stage as you can :)

Rincevent_123 2009-07-03 14:51

No, actually pathfinding becomes a much bigger problem as soon as you go on 3D.

For example, imagine than twinsen is on the upper level of a room. Then there is an enemy on the lower level.
If the enemy has seen twinsen and want to go after him, he will need to find a path which allows him to go up (e.g. he need to take the stairs).
So that can become pretty tricky to find a good path there (you can not simply just fly).

Bot13 2009-07-03 15:14

Then what about enemies that can't use elevators/stairs? They just stay right beneath you. You'll deal with them when you get at their level.
Also, say you've used a ladder to get somewhere higher. If they chase you, you'll need an animation of the enemies climbing a ladder. Bleh, is more work.

Jasiek 2009-07-03 15:29

I don't think ine LBA enemies had path finding like that. They could only shoot at your direction if you where low enough. Imho they should only scan for you you not higher then their own height, and if you're not on ground level just shoot at you.

What I want is for Twinsen and npc's to be able to walk on floors that are on top of each other(like in the citadel) and for Twinsen to be able to climb moving platforms (again, like in the citadel) and like one npc to be able to use them. However, the npc's won't move on the elevator, they will walk onto it and "freeze" won't scan for anything, won't do pathfnding - will just loop in the standing animation, and will unfreeze when the elevator touches ground.

Imho all of that sounds feasible. Just so that there are floors on top of each other and those simple elevators.

Kobold 2009-07-03 17:35

LBA enemies had no pathfinding whatsoever. Every enemy has to be coded individually in LBArchitect. You can make an enemy follow Twinsen, but then he would only follow him and run in his face. And if there's something blocking his path, he will make no attempt to dodge the obstacle.
That said, most enemies only calculate the horizontal distance between them and Twinsen, not vertical the one.

LBAWinOwns 2009-07-03 21:03

Kobold is right.

(though I don't understand what he means with v v v)


That said, most enemies only calculate the horizontal distance between them and Twinsen, not vertical the one.

Kobold 2009-07-03 22:58

1 Attachment(s)
This is what I'm talking about:

Jasiek 2009-07-04 03:52

And this is what I'm doing right now.

Warwick 2009-07-04 09:00

Height maps, for the Z part, sigh..

As of collision, well, collision between several "actors" is easily done.

The harder part is indeed redirecting them onto another path - can be done by checking where are other "actors" located in comparison to the colliding character - if some are 45, 20 and 75 degrees to the character's "face", redirect the actor 180 degrees, like, into the most opposite and actor-free direction possible. You also need to be able to measure distance.

David 2009-07-05 21:09

I'm still confused about the degree of complexity LSA should be. It would be nice to put even more ideas about how you would like LSA to be. Actually, one day, it might be you who make your own map and lua script.
Until things get clearer, I'm animating Jasiek characters.

Darkflame 2009-07-05 21:58

I think LSA should, at a minimum, do what LBA1 could do. But apart from that, it should be as simple as possible.
It can always be expanded in the future.

Jasiek 2009-07-05 23:46

Yeah, my thoughts exactly. It already is quite awesome though.

I'll be going camping for a few days, be back "at work" on the 14th.
The outside map is a real pain in the butt.

Here's what I got so far, I'll finish it when I'll get back. All those arches are really lo poly, just some trickery done on them to fake the higher poly look. I'll add some of my stuff onto that map, like the telepods and some other machines I made.

David 2009-07-06 10:45

looks good ! I'm thinking about how to easily set LBA features
Have nice holidays !

Jasiek 2009-07-15 19:00

How's stuff going in here? I'm still working on that map, trying to keep the polycount as low as possible, but at the same time trying to make it look cool. Once I have everything ready in there, making new maps using it's parts shouldn't really be hard.

David 2009-07-15 19:37

hello !
I'm glad you continue making that map
Before continue coding, I want to be completely sure of how to setup physical engine
I got amazed how close is LBA physic engine from Light Crusader
take a look at this :
The big question is : How to make that ?

Darkflame 2009-07-15 22:35

Well, thats obviously completely sprite based, so its not quite equivalent.
(I'm always impressed what the Tony Hawk games pulled of on the GBA, incidentally;
About as far as you can get from LBA gameplay wise, but the engines doing similiar stuff in terms of gourand polygons on iso-sprite backgrounds).

As for physics, well, we need basic collisions, and magic-ball physics.
I dont think we need more then that?

Basic collisions is just a question of looking ahead at where a charecter would move, and if it hits something imovable, then dont move the player at all, and if it hits something movable, move the player and the object the same amount.
(while doing a similiar test on the object being moved, you can be recursive here with your testing if you want block-pushing-block ability...but that isnt really essential, imho).

Meanwhile for magic-ball stuff, its basicaly
s=ut+(1/2)at^2 isnt it?
Where s is the height displacement, a is acceleration down due to gravity,t is time (/frames into the chuck), and u is the speed/starting speed. (note; this is vertical speed).

When s = the ground (ie, ball hits the ground), you simply flip the u value (u=-u) and take away a pecentage from it. If I remember my maths, this will give you a realistic bouncing ball motion :)

This, of course, only gives you the z location of the magic ball.
The x/y will have to be worked out with billard-ball type physics, angle of incidence = angle of reflection, more or less.
I think this could be just aproximates though. Just have head on collisions and 45 degree ones. LBA didnt have true ball physics from what I remember.

David 2009-07-17 18:36

that remembers me old formulas from school !
Actually I'm supposed to know this for the job I'm doing, but I actually never used it yet. Maybe one day who knows ?
Shall I also consider ball bouncing on moving platforms/lifts ?

Darkflame 2009-07-17 19:43

oh, thats a good question.

If you know the height of the platform, and use that formular, it should be fairly simple to support. (so, rather then "when s = the ground " you have "when s = the ground or equals the height of the platform at that point in space/time")

So I dont think getting the ball to bounce off platforms moving up/down is a problem.
a) Look at the balls overhead location (x/y).

b) See if this is where a platform is

c) If true, test that ball height will become less then that platforms height, while not being less then it already. (ie, it will bounce of the platform if the platform is under it, but if the platform is higher, then it can just ignore it and act like it isnt there).

d) If the platform is higher already (so the ball just goes under it), or there isnt a platform, bounce off the ground.

Umm...Ive probably made that sound more complex then it is. But trust me, its fairly easily.

The harder part is determining if the ball hits the side of the platform I think :-/
That is, the ball hits it going horizontaly, rather then merely lands on it and bounces.

All times are GMT +2. The time now is 22:07.

Powered by vBulletin®
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2021, the Magicball Network