IrrLichtRPG - Erring Light

[keless]

replaced "Server" type messages with the new ListenerRegistry system. only a half-hour's worth of work, but it shows I am putting in time when I can. Only 4 more types of messages to go, then its back to implementing inventories.

incidentally, a slightly longer description of the Listener Registry system can be found in the SF.net forum part of my project: http://sourceforge.net/forum/forum.php?forum_id=372852

[keless]

Fixed a potential bug where Listeners werent automatically unregistering themselves after being deconstructed. This left pointers to invalid memory in the ListenerRegistry, and when a new event would come in, these pointers would be dereferenced and.. *boom*

Continuing replacement of old messaging system.

That is all.

[Washi]

Work getting heavy Keless?

I hope your going to keep working on this as it was a very nice framework for people to start from.

I hope you get some time off to play around with it again soon

Cya later Keless

[keless]

Thanks Washi--

yeah, work is heavy. I've authored 1 full cell phone game, and put 2 into beta stages, and I'm also working on two more design docs as well as a networking module for my MQEngine (sort of like ICE for BREW).

[keless]

Finally! A little extra time off. I broke it off with my signifigant other, and work is just a tiny bit less demanding this week, so here I am warming up Erring Light again.

Still have a bug with Listeners not removing themselves from the registry, so I'll be fixing that right off, then continuing with the Item Inventory system.

Have a bad@$$ new computer comming in tomorrow too, which I'll configure to dual boot XP and Debian or Gentoo; which means I'll be making sure Erring Light works in Visual Studio, DevCPP _AND_ gcc. Perhaps even KDevelop.

EDIT: make that Fedora Core 2 instead of Gentoo, and Anjuta instead of KDevelop

[xhrit]

bling bling! sounds good. you should update your website, too.

[Washi]

Sorry to hear about your significant other, I hope all is going well.

bad@$$ comps are always good

[keless]

*slowly arises from the crypt*

I have arisen once again. Cant say for how long, but I've got some new tricks, and I'm going to clean up IrrlichtRPG with them, then begin pushing new feature development once more.

Miss me?

PS: I missed seeing Irrlicht at GDC! (I was there mon-wed) I cant believe it, argh!

[keless]

Okay, I've improved on ICE, and now I'm going to use that and take another whack at IrrlichtRPG. I've re-conviened and re-written my goals for this project. They are as follows:

Code: Select all

Project Goals:
1) provide a game engine that runs off of user or server-admin
   editable resources (no hardcoded experience)

2) attempt a small-scale online client-server architecture
   (including both coupled and de-coupled client/server code)

3) provide resource defined game system on top of pre-defined/
   efficient building blocks. (easily changed/updated)

4) Specifically, provide an RPG world/stats system

Project Considerations: 
1) scale of world
  * indoor only
  * outdoor only
  * indoor/outdoor
2) scale of players
  * single player
  * 2-4
  * 4-32 or more
3) persistance
  * instance only (save to file)
  * persistant (save to database)
4) game engine type
  * turn-based/stratedgy combat
  * action RPG
  * realistic world-sim

Milestones:
1) basic client-server architecture
  *Client
    resources: load hardcoded level
    core: accept user input
    network: send server request, recieve world updates
    graphics: show level graphics 
  *Server 
    resources: load hardcoded level
    core: accept client connection / disconnection
    network: send world update, recieve server requests
    physics: run physics on world/player avatar
  *Messager
    loopback only 
      (messages queued in preparation of networking)

2) client-server technical evaluation
  *Client
    resources: load resources requested by server 
		(res's assumed already present)
    core: improve user input/interface expand control options
    network: minimize net traffic, increase pre-emption
    graphics: show multiple entities in level
  *Server 
    resources: load hardcoded level, hardcoded entities
    core: run multiple entities in level (multiple levels)
    network: accept multiple client connections
    physics: run physics on entities in each level, 
	     send seperate world updates
  *Messager
    loopback and LAN TCP/IP
==evaluate: how fast does it run?
    attempt multiplayer?
    attempt indoor+outdoor?

3) assumption: fast enough for 2-4 players LAN 
  *Client  
    resources: downloads missing resources from server
    core: entity tree is filled out
    
  *Server
    resources: checks validity of client's resources
    core: entity tree is filled out
          user account system
    physics: make physics updates efficient

  *Messager
    internet evaluation of TCP/IP
    in networked module:
    compression of data being sent, decompression on recieve

-- end of IrrlichtRPG, beginning of Erring Light --
 -> evaluate game design based on IrrlichtRPG's capablities
 -> pursue artist and other team members
 -> define actual resources and timeline devotion

[keless]

more planning info on IrrlichtRPG:

Code: Select all

Server Components:
* NetModule
  - listener
  - connections[] (clientID, socketID)
  - file transfer (use libpdtp or libferit?)

* User Accounts DB
* Characters DB 
   (use SQLite for flat-file db functionality)

* LevelsManager
  - Level[]
    o Entities[]

-------------
Server Update() routine

1) process client request queue from NetModule
2) run world sim 
3) send world updates to clients

-------------
Client Requests
  ( square brackets [] indicate server response to client )
  ( always expect disconnect or timeout )
1) connect (username, pwd)
 [no] -> fail, expect (1)
 [yes] -> return list of avail chars, expect (2) or (4)
2) new char    or (4, below)
 [no] -> same state, expect (2) or (4)
 [yes] -> client will provide char create screen, expect (3)
3) submit new char 
 [no] -> expect (2), (3) or (4)
 [yes] -> expect (2) or (4)
4) select char
 [no] -> expect (2) or (4)
 yes -> load char db info, make sure level is loaded -> [send world update 1] expect (5)
5) client loaded world 

->->  in game ->->

[send world updates]

expect ingame requests:
  * log out char
  * disconnect
  * avatar commands (run, jump)
  * game logic commands (talk, inventory, use item, use spell)
  

[keless]

SQLite code builds easily (just removed shell.c and tclsqlite.c), and I'll be writing the initial user accounts code on top of it soon. I suggest it if anyone has applications requiring DB functionality (I may add it to ICE in the utility folder).

Right now I'm working on the procedural design (client connection to server, initial user account, char creation, then into game, etc) by writing stub code in the NetManager. This will allow me to get some structured code to start writing the backend technologies (networking, db, etc) underneath. Little slow at work, so I'm stealing company time Bad programmer. Bad!

On the good side, however, some of this stuff ports back into MQEngine (which is what I built for my work).

[keless]

Compiled in RakNet, working on first Client-Server connection sequence.

It might be interesting to take a snapshot of the code when thats finished and add it to ICE as a basic C-S framework option

[keless]

Have the client connecting to the server, and several initial interactions (log in request, log in response, send character list ) filled out. Working on de-coupling the current demo so that multiple clients can connect to the server. Soon after, I'll start some code to send player input to the server, which will send world updates back to the client which will effectively move the camera around. The next step after that is hacking in some entities to represent each player's position and letting them all float around where each player can see the other's entities.

I've got a friend working on implementing the SQLite interface for UserAccountsManager (currently the server just uses a hardcoded username/pwd). Later I'll be needing a robust system for setting up UI screens (possibly XML based) because it currently looks like arse on screen and in code.

Oh yeah, and I scrapped the NetManager class-- RakNet takes care of most of the things I was thinking it would handle, so there are packet sending/recieving functions and defines in the Networking directory, but for the most part the IRPG_Client and IRPG_Server are aware of networking code and send packets/pump the message queue as needed.

Anyhow, progress is made.

[Robo]

Glad to see ur making some progress

[keless]

Thanks. And speaking of progress, here is some more:

After much talk and work, one 6am 'all nighter' and one real no sleep 'all nighter' I hit my first milestone. This actually covers some from the first and some from the second goal as posted above as some things were easier than expected and some harder.

Firstly, RakNet is pretty good. Only problem I had was that it doesnt consider hton/ntoh in BitStream (but you cant modify BitStream because its used in some core layers). So I created my own IRPG_BitStream which takes care of that as well as allowing you to pass in ICE-integral types including IRRVector (with automatic truncation of 0,0,0 vector for smaller packets). So thats nice.

Things I _didnt_ do from milestone 1: Im not loading in meshes of any kind. didnt have time to write in proper mesh-avatar interface code so Im just using billboards for now. I'm also not doing any physics yet. I dont yet handle client or server disconnect, thats the next thing I'll be working on before releasing anything.

Things I _did_ do from milestone 2: I'm accepting connections and commands from multiple users. I also have support for running simulations on multiple levels (though thats currently not tested). I did test connections across LAN, but I havent tried across internet space yet.

There was a lot of discussion on the board for different questions I asked. Thanks goes out to mm765 and others in this thread: http://irrlicht.sourceforge.net/phpBB2/ ... 7&start=15