next »

[Yxven]

I'm actually also programming my game with voice recognition because I hurt my arms in a much less interesting way (temporarily). I know a fair bit about efficiently programming with Dragon NaturallySpeaking, so send me a message if you would like to share tips.

[room101]

Hello, I wanted to let u know that I think this project is amazing. I think u are using Actionscript, and as an aspiring game developer and novice in Actionscript, may I ask if u can provide some details, i.e. what libraries or frameworks are u using, perhaps some information about the images and models used in ur project.Thank you!

Hi, thank you for your comment! You are correct, I am using Actionscript and related libraries/frameworks. In the current design, there are several layers sharing Stage3D, basically the background layer where the map images are rendered, the middle layer where the 3-D models are rendered, and the foreground layer where the UI is rendered.

The background and the foreground are 2-D. I use Starling library to render them. Also, the UI heavily uses Feathers framework for buttons, which is an extension of Starling library.

The middle 3-D layer is rendered using an Away 3-D extension called SEA 3-D, from a Brazilian team.  Their extension makes it easy to bundle various 3-D resources into one file, which can be imported at runtime, etc.

the visual components from this project belonged to the original games, the background layer images are from King's Road game, the foreground layer is from SWTOR mostly (the dialogue is from Mass Effect), and the middle layer is from KOTOR TSL

originally, the project started exclusively reversed engineered, mostly by throwing together in the same mix various existing libraries, but in time it became clear that I need to learn how to program a little bit so that I can bridge the gaps more effectively. :-)

Hope this helps!

I'm actually also programming my game with voice recognition because I hurt my arms in a much less interesting way (temporarily). I know a fair bit about efficiently programming with Dragon NaturallySpeaking, so send me a message if you would like to share tips.

Thank you, I will reach you on PM momentarily

[theotherone]

Thank u for this information! about the 3-D layer, how did u port the models, if I may ask?

[room101]

Well, the explanation may sound somewhat esoteric if you're not familiar with any of the tools I used. But basically it was a stroke of luck. :-). The original KOTOR games have a very good set of tools, and one of these tools is used to convert and import models into 3DS Max.

Once in 3DS Max, first I tried to use the SEA3D exporter, as is, but that didn't work because of some limitations of the way away3D handles the 3-D models, and it's not happy with multiple meshes sharing the skeleton, or something along those lines.

Now here comes the stroke of luck. I used ActorX Exporter from Unreal Engine to create one mesh over one skeleton. Then I used ActorX Importer script made by a Russian guy(Gildor) to import it back in 3 DS Max as one mesh and then use SEA3D exporter, and this time everything worked fine.

That's pretty much the 50,000 feet view of the process. In reality, there is still a lot of manual tinkering with a model in 3 DS Max, especially I had to manually convert certain custom modifiers that come from the original models as exported from Bioware Aurora engine into regular skin modifiers and manually add the bones.

Also handling the animation is not very intuitive, I used a tool made by an Italian guy (Khotarr) to migrate all the animation from the original s_* models into the converted ones. truth is, without this tool, would have been no animation in my project at all

at this point, in my project there are a very limited number of models and animation sequences, mainly because the process to successfully port them is pretty cumbersome. The current state of the project uses one female head, one male head, 2 female body ( Jedi and soldier), 2 male body( same),  2 animation sequences(idle and run), some textures and materials to spice up the pool, so to speak. Due to limitation in the way away3d handles certain things, the animation sequences are actually  4, because the animation cannot be shared, or at least I don't know how, between skeleton of different sizes. So I had to export the animation sequence for the female skeleton and separate for the male skeleton.

again, I apologize if some of the details are fuzzy… :-)

[cf2004]

Now here comes the stroke of luck. I used ActorX Exporter from Unreal Engine to create one mesh over one skeleton. Then I used ActorX Importer script made by a Russian guy(Gildor) to import it back in 3 DS Max as one mesh and then use SEA3D exporter, and this time everything worked fine.

Ha, good catch, I just learned something new! I'm playing with UDK in my spare time myself, and I am somewhat familiar with ActorX script. I see your project being Actionscript based, how did you end up using ActorX? I'm currently learning some collision detection in UScript and I'm having a lot of fun pressing random buttons and trying to wrap my head around its inner workings.

[room101]

I see your project being Actionscript based, how did you end up using ActorX?

Well, a few years back, when I was healthier, I did some fan videos in UDK, for example Mass Effect Swing dancing, with Shep and Ashley moving around, and I had to learn something, including but not limited to ActorX. You can click the image below to see the end result video on YouTube

http://dhkgames.com/stuff/mass_effect.jpg[/img]]http://www.youtube.com/watch?v=R_b_9qfmUTQ

[room101]

Update: groundbreaking milestone. :-). In the past few weeks I worked on changing the background design from 2-D to 3-D. The main reason was that in the previous  2-D design I realized I have a depth issue, when the 3-D characters are intersecting the X and Y coordinates, there was no  algorithm To handle which character is "in front". So I went back to the drawing board, put the pencil in my mouth ( literally, I can't use my arms remember), and doodle on some paper to understand how this magic 3-D/2-D projection works. Lucky me, I took some trigonometry classes in high school almost 25 years ago, And eventually I remembered  how to use sine and cosine, And finally I came up with an equation
 2-D (x,y) = 3-D(x,y*sin( camera_angle),y*cos( camera_angle))
 that fixed my depth issue. Unlucky me, due to my eyes issue, I couldn't use the Internet very well, so I was forced to rediscover America, so to speak, by myself, and it took a while, my doodling on paper to figure out camera angles  and plane rotation wasn't very easy to read, as you can imagine :-)
 long story short, now the background is 3-D, the 3-D characters are happily moving in a 3-D world and I also have the equation to project 2-D screen coordinates into 3-D world, so now the characters have apparent depth with an orthographic camera projection.YAY!

. I also added a light saber on the Jedi related classes, currently the light saber randomly picks a blade  color,Red, green or blue

 edit: forgot to include a picture


 on a side note, so far in the current design it seems that I don't really need physics In my world, so currently there is none. I may change my mind later on when I would work on some basic combat interaction…

[room101]

I added the code in a repository on GitHub, if you want to check it out

https://github.com/dhk-room101/kotor-online

Thanks!

[room101]

for the past few weeks or so I worked on implementing some behavior for target seeking and obstacles avoiding, and after poking around for a while, I ran into Eugene Zatepyakin's work http://blog.inspirit.ru/tag/steering-behaviors/

the result is basic and far from perfect, but functional nonetheless. Currently when the player clicks, the 3-D coordinates are evaluated, if the click is on the path, a blank hidden character is created and positioned at the same coordinates as the click, and all the other NPCs are treated as obstacles, while the blank hidden character is set as target for the seeking class. The behavior is the same if the click is on an NPC, said NPC becomes the target for the seeking class, and the remaining NPCs on the map are treated as obstacles.

So far in my tests I didn't test moving obstacles, but the class is implemented to evaluate the NPCs position per frame and the difference between source character and target character also per frame, so ideally it should work just fine. :-)

TO DO: for some reason I'm reluctant to use physics, unless I learn of a specific benefit that comes from implementing physics, I'll make due using classes such as the above. Also, some rotation when avoiding obstacles may be nice

I don't have a relevant picture for this specific milestone, if you want to poke around you can do so here http://dhkgames.com/games/ko/

other than that, I cleaned up a little bit here and there. Also I created an action queue, for example when you click on a character that has a dialog ID, but is away from the player, the action queue inserts MOVE as action before DIALOG, so the player moves near the NPC first, then initiates the dialogue( assuming the NPC has a dialog ID).