webpage: http://www.skyesurfer.net/keless/IrrLicht/RPG/
okay, you may have seen the pre-cursor to this thread in Open Discussion. Its now at a point where I am willing to call it a project.
current version: 0.1.9
current features:
+ high-level message passing system
+ basic IrrLicht collision detection
+ collision-aware entity creation/removal
+ temporary entity Factory
+ 'floating' 3rd person camera
+ .md2 avatars
+ basic mesh 'level'
+ based on ICE 2.0
planned features:
+ saigumi's XML GUI
+ caLua scripting interface
+ ODE or Tokamek physics integration
+ basic scripted AI / NPC dialog system
+ SQLlite db for RPG stats
+ proprietary level format/editor
+ .x avatars
+ Audiere sound support
Im coming to a point where I am going to need some help. If you're familar with IrrLicht, and think you want to help out, please PM/AIM/Email me. I'll be needing GUI, Tools, Special Effects, AI programmers, and of course-- artists.
IrrLichtRPG - Erring Light
IrrLichtRPG - Erring Light
a screen cap is worth 0x100000 DWORDS
0.1.9e
Im getting close to a 0.2 release.
Currently I have encapsulated the model controllers in an RPG_Creature class, which contains hitpoints. I developed the CSN_Overlay and CGE_ProgressBar classes so that I could display a bar showing their hitpoints. This can be toggled by pressing 'tab' -- because one of the RPG_Event types is a 'Device' event, which basically allows you to sneak raw SEvents directly into the RPG code. Neccesary for such things as toggling in-game visuals. It is understood that the Device event is generated and passed only in "Client" code.
Currently everything is "Client" code, but I am trying to keep everything modular enough to be converted to a Client-Server model, should the time come.
My current priorities (in order) are:
* flesh out the event system further
* add basic AI agents to 'creatures'
* introduce scripting engine to control AI, RPG attack events, and 'special effects'
Currently I have encapsulated the model controllers in an RPG_Creature class, which contains hitpoints. I developed the CSN_Overlay and CGE_ProgressBar classes so that I could display a bar showing their hitpoints. This can be toggled by pressing 'tab' -- because one of the RPG_Event types is a 'Device' event, which basically allows you to sneak raw SEvents directly into the RPG code. Neccesary for such things as toggling in-game visuals. It is understood that the Device event is generated and passed only in "Client" code.
Currently everything is "Client" code, but I am trying to keep everything modular enough to be converted to a Client-Server model, should the time come.
My current priorities (in order) are:
* flesh out the event system further
* add basic AI agents to 'creatures'
* introduce scripting engine to control AI, RPG attack events, and 'special effects'
a screen cap is worth 0x100000 DWORDS
more high-level goodness
Now when creatures are 'attacked' they subtract a hard-coded value from their HP. If their HP drops below 0, they post an event "creature id death" to the level manager (who then removes that creature).
There is a slight problem with my hacked together 'attack' code-- currently it uses getSceneNodeFromRayBB() to find what node was attacked. But after attacking, it create a particle system (the fire the faerie attacked with), which means if you attack again in the same direction before the particle system is done, it will hit that node instead of the creature.
Basically, this all means I need to be limiting my collision search to only RPG object scene nodes, which I think was said can be done using scene node "ID" bit masks of some sort?
There is a slight problem with my hacked together 'attack' code-- currently it uses getSceneNodeFromRayBB() to find what node was attacked. But after attacking, it create a particle system (the fire the faerie attacked with), which means if you attack again in the same direction before the particle system is done, it will hit that node instead of the creature.
Basically, this all means I need to be limiting my collision search to only RPG object scene nodes, which I think was said can be done using scene node "ID" bit masks of some sort?
a screen cap is worth 0x100000 DWORDS
more high-level goodness
Now when creatures are 'attacked' they subtract a hard-coded value from their HP. If their HP drops below 0, they post an event "creature id death" to the level manager (who then removes that creature).
There is a slight problem with my hacked together 'attack' code-- currently it uses getSceneNodeFromRayBB() to find what node was attacked. But after attacking, it create a particle system (the fire the faerie attacked with), which means if you attack again in the same direction before the particle system is done, it will hit that node instead of the creature.
Basically, this all means I need to be limiting my collision search to only RPG object scene nodes, which I think was said can be done using scene node "ID" bit masks of some sort?
There is a slight problem with my hacked together 'attack' code-- currently it uses getSceneNodeFromRayBB() to find what node was attacked. But after attacking, it create a particle system (the fire the faerie attacked with), which means if you attack again in the same direction before the particle system is done, it will hit that node instead of the creature.
Basically, this all means I need to be limiting my collision search to only RPG object scene nodes, which I think was said can be done using scene node "ID" bit masks of some sort?
a screen cap is worth 0x100000 DWORDS
k, got that fixed.
I cut a playable binary. check the website: http://www.skyesurfer.net/keless/IrrLicht/RPG/
the demo features the creature events:
BIRTH, DEATH, MOVE, ATTACK, TAKEDMG
Buttons:
arrow keys, space, tab
Thats all for verison 0.1.9 -- all new work is under the version 0.2, yay!
First I'll be adding some basic AI so the NPCs are more fun to test with. Of course, I'll be trying to remove as much hard-code as possible, moving things to factories etc. Hopefully I'll integrate the scripting engine sometime in version 0.2 -- otherwise, 0.3 (but since these version numbers only take me about a week, it should definately be done in under a month
).
see how many bugs you can find in the demo. I dare you. I've counted about 4 in-game alone (and thats after squishing a few already). But at least its completely stable, and playable.
I cut a playable binary. check the website: http://www.skyesurfer.net/keless/IrrLicht/RPG/
the demo features the creature events:
BIRTH, DEATH, MOVE, ATTACK, TAKEDMG
Buttons:
arrow keys, space, tab
Thats all for verison 0.1.9 -- all new work is under the version 0.2, yay!
First I'll be adding some basic AI so the NPCs are more fun to test with. Of course, I'll be trying to remove as much hard-code as possible, moving things to factories etc. Hopefully I'll integrate the scripting engine sometime in version 0.2 -- otherwise, 0.3 (but since these version numbers only take me about a week, it should definately be done in under a month
).see how many bugs you can find in the demo. I dare you. I've counted about 4 in-game alone (and thats after squishing a few already). But at least its completely stable, and playable.
a screen cap is worth 0x100000 DWORDS
v0.2.0b
I added a 'triggerarea' entity.. this is a basic class which defines an area in the 3d realm that will react when other entities enter its bounding box.
I then created a 'bonfire' entitiy as a child of this class-- and replaced that particle system you saw before with it. Now when you walk too close to the fire, you take damage. Looks like I'll have to add some code to handle when the player dies now, lol!
I then created a 'bonfire' entitiy as a child of this class-- and replaced that particle system you saw before with it. Now when you walk too close to the fire, you take damage. Looks like I'll have to add some code to handle when the player dies now, lol!
a screen cap is worth 0x100000 DWORDS
okay, its been going a little slow do to my contract jobs. Also, I was at a point where I needed to sit back and think about design. Plan before coding, something Im trying to do more often since its vastly superior.
Im merging the gs_Main and gameController classes, and creating a 'interfaceManager' base class which will house GUI interfaces for different sub-states such as Inventory, Character Creation, Stats, etc.
That should be done by the end of tomorrow. Then I think I'll work on the creature entities more, adding some stats and Inventory. Afterwhich I'll add Item entities, and the ability to pick them up into your inventory. Should be done by the end of the week, depending on how many hours I put in. (Unfortunately, I recently got both Pokemon Ruby and Viewtiful Joe, which DEMAND several hours a day )
Im merging the gs_Main and gameController classes, and creating a 'interfaceManager' base class which will house GUI interfaces for different sub-states such as Inventory, Character Creation, Stats, etc.
That should be done by the end of tomorrow. Then I think I'll work on the creature entities more, adding some stats and Inventory. Afterwhich I'll add Item entities, and the ability to pick them up into your inventory. Should be done by the end of the week, depending on how many hours I put in. (Unfortunately, I recently got both Pokemon Ruby and Viewtiful Joe, which DEMAND several hours a day
)a screen cap is worth 0x100000 DWORDS
v0.2.1c
0.2.1c is a stable version, so if you've been wanting to get your hands on the latest-- go with this. I didnt do the major documentation, and some classes still may get pushed around, so be aware of that.
Anyhow, in this version I have put all ingame specific GUI inside of an 'interfaceManager' class (currently the demo code is in a class called interface_demo which inherits from it). Then I added the functionality to handle the Player's death, by adding a 'revive' button which posts a Player Birth event and respawns you. I also fixed a small bug where the camera was holding on to the dead player's node and leaving its HP bar up.
I think next I will begin working on fleshing out the creature class a little more, adding an Inventory then creating an Item entity and adding functionality for creatures to pick up items, add them to their inventory, and then to use them. I may also develop an equip system to that end.
This might all be happening before I plug in the scripting engine and AI, because I'm sort of nervous about how do to the scripting engine (which will run the AI). Im going to look for some examples before just blindly wasting my time plugging it in wrong.
Anyhow, in this version I have put all ingame specific GUI inside of an 'interfaceManager' class (currently the demo code is in a class called interface_demo which inherits from it). Then I added the functionality to handle the Player's death, by adding a 'revive' button which posts a Player Birth event and respawns you. I also fixed a small bug where the camera was holding on to the dead player's node and leaving its HP bar up.
I think next I will begin working on fleshing out the creature class a little more, adding an Inventory then creating an Item entity and adding functionality for creatures to pick up items, add them to their inventory, and then to use them. I may also develop an equip system to that end.
This might all be happening before I plug in the scripting engine and AI, because I'm sort of nervous about how do to the scripting engine (which will run the AI). Im going to look for some examples before just blindly wasting my time plugging it in wrong.
a screen cap is worth 0x100000 DWORDS
I have been planning out the Item system.
Firstly, there is a distinction between an Item and its 3d/entity representation. The representation is just a temporary vesel to hold an item until it gets picked up by a creature. Things that can be employed without taking them into your inventory are not Items.
So, I will be creating an entity who's job it is to sit and display some model as defined by an Item, and to wait for a creature to 'pick' it up into their inventory, at which time it will remove itself from the entity list (and from collision detection). Additionally, may even create an animator that will make the model jump into the air towards the player in an arc (sort of like bolts in 'Ratchet and Clank') before assigning itself to the player's inventory.
As for the Item class itself-- there will be a basic Item interface which will contain Name, Type, SubType, Default Stat ID, Instance ID, Script Handle, and Model/Entity Handle.
What makes different copies of this unique will be the Scripts they call (based on their Type and SubType) and their Instance data. The idea is this: a registry keeps a list of all different Item types with their default statistics, when an item is created, an 'instance' is made. This Instance can have its own stats, or can rely on the stats given by the default Item. So, a 'potion of healing' might have a 'health up' stat which uses the default 'potion of healing' statistic. Where as a 'sword' might have its own copy of the default sword's 'attack str' statistic which will go down when the sword is rusted or used too much.
When you perform any action on an item, that item calls it's script. The script handles the actual action-- be it to attack another player, to heal the current creature, or to do nothing at all for unsupported actions.
Firstly, there is a distinction between an Item and its 3d/entity representation. The representation is just a temporary vesel to hold an item until it gets picked up by a creature. Things that can be employed without taking them into your inventory are not Items.
So, I will be creating an entity who's job it is to sit and display some model as defined by an Item, and to wait for a creature to 'pick' it up into their inventory, at which time it will remove itself from the entity list (and from collision detection). Additionally, may even create an animator that will make the model jump into the air towards the player in an arc (sort of like bolts in 'Ratchet and Clank') before assigning itself to the player's inventory.
As for the Item class itself-- there will be a basic Item interface which will contain Name, Type, SubType, Default Stat ID, Instance ID, Script Handle, and Model/Entity Handle.
What makes different copies of this unique will be the Scripts they call (based on their Type and SubType) and their Instance data. The idea is this: a registry keeps a list of all different Item types with their default statistics, when an item is created, an 'instance' is made. This Instance can have its own stats, or can rely on the stats given by the default Item. So, a 'potion of healing' might have a 'health up' stat which uses the default 'potion of healing' statistic. Where as a 'sword' might have its own copy of the default sword's 'attack str' statistic which will go down when the sword is rusted or used too much.
When you perform any action on an item, that item calls it's script. The script handles the actual action-- be it to attack another player, to heal the current creature, or to do nothing at all for unsupported actions.
a screen cap is worth 0x100000 DWORDS
Hi, a ~maybe~bug I've discovered in 0.1.9f is, that the 3rd-person camera is not following the player fps-independent. In the lastest version, it is really slow, because it is now a fullscreen windowed app, which runs very slow on my pc. The 3rd-person camera nearly doesn't move. If the fps is high, it places always itself to the right position. Maybe you already know this, but I though it would good to post if not. 
More on Item System design
I've spent almost 2 days planning this and I'm almost finished.
The neccesary components I have outlined so far are:
1) a Registry of template items (one of each item)
2) a list of Item Instances (one for each item created in the game. Instance-specfic data such as 'uses' or 'sharpness' is stored in here, the rest can be retrieved from the item's default stats in the Registry)
3) entity vessel (an entity which represents the item in the 3d realm, and stores the Item object until a user 'picks it up', the entity vessel is destroyed when an item is moved into an Inventory, and a new one is created when the Item is dropped back into the world)
4) Inventory (a member of the Creature class, will keep track of what Items different Creatures have in their posession)
*Template Item
-name
-type + subtype
-2D representation {
>icon (an icon of specified size, for displaying in inventory list)
>graphic (a picture of varying size, for 'close up' examination)
>grid-icon (a graphic of size based on the tile-grid 'volume' an item takes up in a 'volume' based inventory. a stack of potions might be 1x1, and a sword might be 2x3)
}
-default script used for actions (when an item is 'used' the action type is sent to the item's script, which then handles the action. if the action type (such as attack, use, drop) is not handled, the script simply does nothing)
*Item Instance
-name
-index of item's basic template in Registry
-instance-specific stats (a +1 sword would keep the +1 information here)
-actual script used (a fire-brand sword would use a fire-brand script instead of the default sword script)
-information to create an Item Vessel entity from (when dropped)
*Inventory
1) tracks items
2) constrains ammount able to carry (by number and/or by volume and/or by weight)
3) display (a list w/wo icons, or a volume grid)
The neccesary components I have outlined so far are:
1) a Registry of template items (one of each item)
2) a list of Item Instances (one for each item created in the game. Instance-specfic data such as 'uses' or 'sharpness' is stored in here, the rest can be retrieved from the item's default stats in the Registry)
3) entity vessel (an entity which represents the item in the 3d realm, and stores the Item object until a user 'picks it up', the entity vessel is destroyed when an item is moved into an Inventory, and a new one is created when the Item is dropped back into the world)
4) Inventory (a member of the Creature class, will keep track of what Items different Creatures have in their posession)
*Template Item
-name
-type + subtype
-2D representation {
>icon (an icon of specified size, for displaying in inventory list)
>graphic (a picture of varying size, for 'close up' examination)
>grid-icon (a graphic of size based on the tile-grid 'volume' an item takes up in a 'volume' based inventory. a stack of potions might be 1x1, and a sword might be 2x3)
}
-default script used for actions (when an item is 'used' the action type is sent to the item's script, which then handles the action. if the action type (such as attack, use, drop) is not handled, the script simply does nothing)
*Item Instance
-name
-index of item's basic template in Registry
-instance-specific stats (a +1 sword would keep the +1 information here)
-actual script used (a fire-brand sword would use a fire-brand script instead of the default sword script)
-information to create an Item Vessel entity from (when dropped)
*Inventory
1) tracks items
2) constrains ammount able to carry (by number and/or by volume and/or by weight)
3) display (a list w/wo icons, or a volume grid)
a screen cap is worth 0x100000 DWORDS
for all you linux players out there, BradB has made a linux build which I have uploaded to the webpage: http://www.skyesurfer.net/keless/IrrLicht/RPG/download/
a screen cap is worth 0x100000 DWORDS
-
Guest