[test] some sort of RPG engine ( calling for Blink, Strille, Andree ? :))

Quote:

---

Originally posted by VENGEANCE MX
I've got a 450 Mhz G3... 512 MB of RAM, 8MB of VRAM. Ouch. On a PC with equivalent specs, it would run A LOT faster.

---

It doesnt run much faster on a PC with equivalent specs...I have a 600 Mhz Pentium III, 256 MB of ram, and 8 MB of video ram, which is very similar to yours (but PC of course). I get 10 fps when moving and 12 fps when standing still.

And of course on my other computer which is a 3Ghz P4, 2gb ram, Radeon 9800 Pro- The fps was the same as Santuria.

Also, this tutorial on 3D stuff might be interesting.

~MD

Well, I brought one of my Flash games into school with me. We've got _crap_ computers there, but it runs a lot better on the PCs than it ever has on my Mac.

Hey look it's WoW!

:D

All apologizes Lux...

I couldn't find it. :(

I will keep looking because I'm sure I had it.

-pXw

DAMN! That's awesome! Can I have a source file for that?

Hello Lux. I've been a lurker on this board for many years and never felt the need to post until today. :) Your post hit close to home so I figured I'd contribute.

I develop full-scale flash applications as the lead artist/developer for a government education agency. I do alot of AA education games and whatnot for distribution to schools/students, and have attempted something similar to this on a project about a year ago. I made a lot of headway with it, but ultimately had to drop it for a top-down 2d engine due to minimum PC specs (school computers are often lacking) resulting in low framerates.

My first attempts at this type of engine utilized some of the same concepts that have been suggested by others in the post; essentially, tiling out the worldmap into many small pieces and bringing in the pieces on the fly with their corresponding content. This worked fine until I started adding more functionality to the engine, such as collision detection and NPC interaction. In order to minimize the situations in which collision detection would operate and decrease/eliminate the CPU power required to render the many map tiles in an aesthetically pleasing way, I came up with a new concept I liked to call "content islands". This practice has been used in many other ways before most likely.

Basically, the way I generated my world was to create a static ground texture for an entire region (or zone in MMO terms). For example, if it were a recreational park, the most common ground surface would be grass, and therefore I made the world surface grass for that zone. I then created individual content modules that contained the data for a unique ground texture (with the edges doctored so they'd always mesh in with the universal ground texture) and any content within them (buildings, NPCs, etc). I then built a coordinate array that held the locations for these "content islands" to dynamically load into the generic world map. The beauty of this is you can reuse these "content islands" as needed, for example, a batch of trees and rock. They can be any size as well, to a reasonable extent.

This essentially solved two problems, the second of which was resource/fps hogging. First, you could disable world collision detection until a player entered a "content island". Secondly (and most importantly), you can bypass all the inherent issues in getting the many ground tiles to line up and appear seamless. This opens up a great deal of the processing power to the engine.

I wish I could pass on to you the work/engine I developed to assist in your own efforts, but I'm afraid that I am unable to do that for contractual reasons (anything I make at work, belongs to work). I'd be happy to assist in any other ways though. I've been wanting to resurrect this engine on my own time for awhile now, but haven't gotten around to it.

G'luck :)

I also meant to comment that visually things can get kinda wierd when using large asymmetrical billboards (such as trees). When asymmetrical objects rotate on turning axis, they exhibit a wierd wobble effect that plays with your depth perception. Rotating a symmetrical (or close to) billboard is easier on the eyes because the object doesn't seem to be rotating off center weight-wise. Keeping the base/footprint of these objects small also helps to minimize this. You can use symmetry to your advantage for file/texture sizes by cutting objects in half and displaying two of them side by side, one flipped, to create a full object. Granted, this is all personal preference and doesn't bother some people.

Again, G'luck.

Hey bogeybot, First of all, welcome on Flashkit...

Your ideas sound really interesting, and, if i understand that you cannot re-use the engine, i was wondering if there was any way to see a version of it online ...just to see how fast ( or slow ) it is ...

I would be glad to cooperate on such a project : as i stated previously, for now, i haven't really thought of a game system, i was just playing with an idea, but if something productive could come out of this, i would want to be part of it :)

About the weird angles on asymetric objects, i am aware of the problem : i do have two different stances to adress it :

1) for simple, decorative objects, such as grass, trees, rocks etc, i think the 2 D sprite will be better, even if it ruins a bit the visual aspect : because there will be likely several trees in the map, i'm afraid the engine won't afford dealing with the different points of view ... now, the current graphics in the engine are totally temporary, i will be carefull, once coming with the real ones, to make them "equilibrated" enough so that the effect will be less visible ...

2) for more important objects / landmark, i'm trying to port the superSamourai calculations on Blink's engine ( waiting for him to come back and throw in some advices / help :))
This method would allow the engine to pick the correct angle of view on a pre rendered 3D animation, according to the camera ( player ) position and target

I've started to do some simple 3D models like this one :

http://grafikdezign.free.fr/flashkit/model.htm

( Don't make fun, i'm just starting 3D :))

By limiting the number (on the map), the size and the available angles of these objects, we can make it light enough to be an acceptable download for a broadband connection

These type of objects could counter-balance the 2D effect, and increase the overall 3D feel of the whole engine ... but of course, we are still lying to the player, at the end :)

I know, the game, overall, will be quite heavy, and slow, but i really feel like trying to at least come up with something valid game-wise, even if it stays a demo or an engine ...

Well, bogeybot, if you have some time to dedicate, please contact me via PM, so that we can exchange mail to discuss our possibilities ...

bogeybot,
All of your ideas are awesome and very logical. I haven't heard of most of them. If you and luxregina teamed up you'd be unstoppable. Great work.


luxregina,
if you stayed with this project for long enough and put enough into it, you could easily top the guys at Jagex (Runescape). If you end up finishing it, PM or E-mail me and I'd be happy to spread the word as far and wide as I can. By the way, your 3D models are awesome. Good luck.

is that the pivot3 link?
http://users.nlc.net.au/oceana/games/pivot3.html
http://users.nlc.net.au/oceana/games/pivot3.zip
coz i think that's what you need but it looks like your using that already. i wouldn't worry about z sorting, just use the z value to set the depth (mabey multiply it by 100). anyway if you need any help just ask;
ablinco
compuserve
com
awesome work dude. i've been waitin for someone to go left field on that engine.:)
ps: sorry for the delay, been fishin
pps: i have some thomas glynn code that explains the angle adjustment for perspective so just email me.
ppps: i found that putting some kind of stain on the ground (like a discoloration) where the trees met the ground made it look like the trees were really planted there and not floating above the ground.

Lux. Unfortunately, based on my employment contracts, I am not allowed to claim ownership, in any way, of products created/developed at work. I can't even link to the program and tell you that I made it. I couldn't even put it in a resume. It's that strict ... and I like my job, so I'm not gonna mess :) Sorry. The engine was fairly quick (32 fps on high end), but on the minimum spec test machine (600mhz PC with 256ram) at the time, the thing chugged between 7 to 10 fps. To be honest, for a hobby / independent game, I don't think its worth worrying about anything less than a 1ghz machine with decent ram.

So, with that in mind, the best I can do is start fresh from home. Either that, or we can start with what you have already. Essentially, the engine works the same way, it's just that its methods are applied in a different fashion. It's not very difficult or complicated either. Instead of loading a single large texture map centered at 0,0 (where your character starts, center of map), you load smaller parts spread around on the coordinate field. You build those smaller parts so they will always blend well into the pre-established zone texture you've chosen. When you walk around, all you're doing is moving those individual pieces around (like tiles), but the entire floor isn't completely covered with them. The zone texture is your "ground" when you're walking in areas that require no collision or special ground texture. The pieces can be whatever size or shape you need. So, what you're basically doing is limiting detail to only the areas that require it. You can throw in a few grass billboards randomly around to facilitate the sense that you're still moving (even if there's no content islands in the viewfield).

As far as the 3d rotatable object demo you showed me, I have a few comments/concerns/questions. First off, that model is actually rather nice considering you're just starting 3D. From what I can see there's an efficient use of polygons and whatnot ... prior to my current job I was a 3D artist for a multimedia company working with Lightwave. Did stuff for Hershey and Bubble Yum (that punk duck mascot). Great stuff, I miss it :) Anyway, my concern is that since we're really simulating 3D using a swapping/rotated render like you've shown me, how do you define the collision for that object? Since that building, for instance, is longer than it is wide, depending on the angle you're viewing it at, you should be able to walk closer to the rotational axis from some directions than others ... and in that case, the actual collision shape would be an oblong/oval, not a rectangle. I'll continue to think about that, but I have no current solutions off hand for that problem. In the game I was developing, I made sure that all building faces were at the edges of my maps, so that you couldn't walk around them ... think South Park (or old Western movies) fake building facade style. To develop an adventure world of the sort you describe, I think you'd be forced to use something like that interior engine you posted for building exteriors. Some sort of hybrid system of the two might work?

I'd be interested in collaborating on something. I've never had the opportunity to work with someone who could also design and code. Our art styles seem fairly different from what I've seen in your other games (retro). A combination of styles may prove to yield something unique though. I'll PM you my email address to discuss further.

I made a game with 3D vectors but it does not use objects and is too slow to work propperly, but you can have the source if you want to.
3DPreview

Joshman_123 > Thanks man, though, i would like to stress that the result so far is the result of a community work, so i have absolutely no grace aside putting new GFXs on it ... second, we will still be far from Runescape, as this one is full 3D ...this engine is more about "pretending" doing 3D than actually doing it

Blink > Welcome back :) ... The pivot3.zip is the source I am currently working on.

What I am looking for is your next source, with the little moving character ( or the updated version, because mine doesn't have the moving character, nor Z-sorting, nor the superSamourai calculations ).

Please tell me to go to hell if you don't want me to use your source :) ...but as it was public before, i assumed i could still try to ask for it :)


bogeybot > Well, i really want to make sure that uou know I CANNOT CODE :) ... i can play with existing files, i can read and understand what is going on code wise but i'm perfectly unable to come up with new ideas or new concepts : i'm the classic follower that leeches other people genius and put its tag on it ( though, i always give credit where it is due :))
But there is one thing that i know, it's that i will never get someone to work with me without a prior test engine that shows what my ideas are ... so i'm used to tweak existing engines to show what i'm up to - so be aware that if we were to team up, i wouldn't be the coder in the team :( ...

However, here are some thoughts on your questions / remarks :

- The collision test would be planned to be on a rather large radius circle : as the prerendered building are still 2D, they function as a landmark : you cannot get inside, nor too close to ( when i mean too close, i mean not as close as a tree ) Circular collision seems to make sense in the system we are in and shouldn't be too hard to implement, nor too processor intensive

//-------
- About the "game system" ; well, positive feedback made me dream a bit : i basicly would imagine the Zmapping engine used in the outer world, where you walk from a region to another : there, you can meet some NPCs that would give you some quests, maybe fight a little ( though, i am still not sure how to handle the fights in the Z-mapping engine : FPS disparities might make it hard to keep it realtime, and i'm no fan of turn based fight engines ... well, still some time to think about this )

The 2D world would include some specific "tile" ( likely a glowing circle ) that would teleport you "inside" a dungeon once stepped on

We would then switch to the Raycasting engineto render the labyrinth - with a blurry enough floor and ceilings, wich should be able to keep the raycating vertical - so it would be an engine OR the other, not a combinaison of the two ( that would be processor hogging )

Fights there could be handled a la Dungeon master / eye of the beholder / ultima underworld

The use of a specific color map / textures could still give the player he is in the same "zone" as outside : gfxs small gimmicks tend to work quite well in that situation
//-------


Now, the problem is that the only raycasting engine I had my hands on ( Strille's one ) doesn't allow an easy process to create different maps - i know there is an open source engine from Andre Michelle, but as it is in Flash MX 2004 format, i cannot open it ( i'm still working with MX )



So, for now, i have set aside the question on raycasting, and i'm trying to focus on creating a "believable" world using Blink's engine

I actually came across an interesting version of it, made by Tyg :

http://members.tripod.com/hrealm0/Go3.htm

The pre-rendered angle calculations seems to work quite well, but i couldn't find any open source version of his engine to test it : anybody knows if he still comes on the board, and if he is willing to have his engine worked on ?

Anyway, this thread make me believe more and more that something could be possible here :) ...


P.S : is it only me, or FK has become a real pain to post on ? between slooooooow coming pages, and error message such as "server too busy" it takes me a good 5 minutes to browse subjects, and another to post ...

P.P.S [edit] : Thanks Ihoss, but this engine is mainly based on Sprites, so all the complicated, slow, 3D vector calculation you do for your engine would be useless here :) but your engine sure looks impressive :) remind me my old CPC Star Wars game :)

Blink > i forgot : yes, i totally agree : the 2D map on the floor should set elements so that the Sprites spawn on to of it doesn't look out of place ( like "bringing the tree location" on the floor )
The engine showed here is really a quick example : i am working on something much more finalized, where attention to such details will be more obvious :)

sorry for the delay dude. i'll add some stuff (npc's/objects/depth) to the pivot3 demo and post it tomorrow.

Quote:

---

Originally posted by luxregina
Joshman_123 > Thanks man, though, i would like to stress that the result so far is the result of a community work, so i have absolutely no grace aside putting new GFXs on it ... second, we will still be far from Runescape, as this one is full 3D ...this engine is more about "pretending" doing 3D than actually doing it

---

Shhhh... no one will ever know. But seriously, if you could get some serious gameplay into this (eg. killing a monster) it would be awesome. Show us when you do, OK?

Quote:

---

Originally posted by luxregina
I actually came across an interesting version of it, made by Tyg :

http://members.tripod.com/hrealm0/Go3.htm

The pre-rendered angle calculations seems to work quite well, but i couldn't find any open source version of his engine to test it : anybody knows if he still comes on the board, and if he is willing to have his engine worked on ?

---

I think source of his older engine is still here:
http://www.flashkit.com/board/showth...hreadid=458449

Lux - I wasn't implying that you'd be the coder. I was just stating it would be refreshing to work with an artist who had some actionscript experience. Even if your programming skills are not advanced, knowing the capabilities and limitations of flash/actionscript go a long way to making good flash art.

As far as the engine goes, I was thinking about it last night and remembered a game I was very fond of many years ago: Might & Magic: Clouds of Xeen. I didn't get a chance to find the thing on the internet and check it out yet (my original program disks are floppies and I don't have a floppy drive anymore), but it was very similar to what we're trying to do. It used a z-mapping engine for outside, and switched over to a raycasting engine when you entered a town, dungeon, or special location. It really was a great game, and it would probably do us well to study how they handled some of the complications we've been discussing. The biggest difference was combat was quasi-real time and movement was limited to rotating left/right, and taking a defined tile-like step forward.

Additionally, it addresses our discussion of exterior buildings in the z-mapping world -- they didn't try to simulate a full size building in the world, they would put a rendering of a town (micro size) on a billboard and rotated it to face your direction. When you walked up to the town or location it asked you if you wanted to enter ... entering would switch to the raycasting system. Seeing that this game ran solid on a 486 dx/33mhz system with 4mb or ram ... I'd say it's definately doable in flash :)

As far as Andre's OS engine being in MX2004 ... shoot me a link to the FLA and I'll take a look at it. I can convert it down for you.

Nice work lux, an rpg using a combination of the zmapping + raycasting sounds great!

In terms of the zmapping side of things though, I think the biggest problem will be the limitation of map sizes.

Using the zmapping engine, adding additional movieclips (tiles) to the single ground plane drastically reduces performance. Just one tile will practically half the speed at which the ground can be rendered.

bogeybot: did you manage to get around this performance issue with tiles, or did you simply just put up with it?

How many tiles did you have on average on the screen at once?

Strilles method of having larger maps is the best method in terms of performance, but unfortunatly requires multiple large bitmaps which will make the games filesize very large.

Due to the size of a typical RPG's landscape I guess the best option would indeed be to try to use tiles, reusing one main plane as bogeybot suggests and putting 'feature' tiles over it, but unless bogeybot knows something Im not aware of, performance will suffer :(

Pea

just incase you're using an older version of blinks engine, you can increase the performance significantly by changing the code in which the 'strips' of ground are added.

If you find the loop that adds the ground pieces, you'll probably see that the first ones added are the smallest, and placed at the lowest depth.

in the attachMovie("pic","pic"+a,depth) line, chance the depth part to something like 1000-depth.

This will give the smallest ground bits (the bits in the distant) a higher depth than the large ground pieces (foreground).

Theres a reasonably performance gain doing this because if its the other way around. Flash redraws the large pieces over the entirity of the small pieces before they are masked.

Making the depth of the largest pieces behind the smallest pieces means that its the smallest pieces that are drawn to screen last, and as such flash only redraws parts of the biggest pieces behind the smaller ones.

if that makes any sense :)

anyway, if its a more recent version of the engine, it might have that anyway. You can test it by simply putting the 1000-depth in the attachMovie() line and seeing if you notice a speed increase, or decrase.

Pea