FIFE forums

Please login or register.

Login with username, password and session length
Advanced search  

News:

FIFE 0.4.0 has been released on 15th of January, 2017!

Author Topic: Determining Feasibility  (Read 2270 times)

BubbaBrown

  • Newbie
  • Posts: 1
    • View Profile
Determining Feasibility
« on: February 11, 2010, 04:23:05 am »

I've been looking into using FIFE for a project concept I've been playing around with as of late.  The idea is to create a FIFE-based flexible client to a multiuser dungeon server system.  Imagine taking FIFE and using the concepts of XDMCP and MUD's.  The end goal would be to create the "F-MUD" client that has the ability to connect to "F-MUD" servers.   This would allow the ability for the client to load the graphical side of the server-based game while keeping a majority of the game logic on the server (very desirable in multiplayer settings).  The client would only have to worry about connecting to the server at the very least.

I'm still getting familiar with the FIFE system as a whole and understanding the general structure.  It seems to have a large number of features that I'm still trying to understand the scope and domain.  Currently, I'm trying to deduce the approach I would take if I used FIFE to create "F-MUD".  As it stands right now, the only major component that FIFE currently lacks is the networking ability and the "remote control" aspect.  With a decent amount of code, it seems remote control system could be put into place that allows a majority of API calls to be remotely done via a remote wrapper API on the server.

The only major obstacle that I see is management of game specific assets.  I'm guessing a network asset management system would be the ticket at this point.  This system would sit in front of the FIFE API's calls when it comes to loading anything.  It would check to see if the file existed and hashed the same as the server's, else it would download a new copy.  Other additional features would include asset check lists (developers could request hash checks and discover missing files) and calls to request batch download of game prerequisite assets.  (Load all the needed stuff before allowing the player to enter a level or game.)

So, I'm curious if there are any other examples on basic tutorials and documentation of proper techniques and methods from the developers.  API documentation is nice, but actual examples that are approved go a long way, too.  And any opinions, hints, or tip would be appreciated, too.  I'm trying to determine the feasibility of the project and feel out what are the better routes to take.
Logged

prock

  • Developer
  • Full Member
  • *
  • Posts: 236
    • View Profile
Re: Determining Feasibility
« Reply #1 on: February 11, 2010, 12:16:08 pm »

Hi BubbaBrown,

We appreciate you looking into FIFE for your project.  I believe I understand what you are trying to accomplish by creating an F-MUD client.  I'm not sure how suited FIFE would be for such a project for the very reasons you pointed out.  FIFE doesn't have any network support.  I'm not sure how difficult it would be to add support to FIFE.  I have heard of some APIs that might help make that easier.  We do not have any immediate plans to add network support to FIFE but we have talked about adding it in the future.

If you're willing to put the time and effort required to bring network support to FIFE it does provide a nice starting point for your project.  Keep in mind FIFE is still maturing and our API is changing fairly regularly.  We dont currently have any tutorials to get you on your way other then our demo (rio_de_hola).  There are a lot of features implemented in that demo game so I would suggest looking at it's code and start playing with the behavior a little.

If you have any more questions you can ask here or in #fife on freenode.   Hope this helps!
Logged

Skyy

  • Newbie
  • Posts: 3
    • View Profile
    • Personal website with portfolio of work
Re: Determining Feasibility
« Reply #2 on: March 12, 2010, 09:12:48 am »

A bit old thread but cannot help but to throw in my few cents, don't know how helpful this will be but here I go...

Anyway, about networking code and FIFE. Writing working and robust network (server/client) arcitechture code is hard and the choices done in the network code design always reflect the way the game works. Even though if FIFE had a generic network code, it might not work with certain types of games done with FIFE. Because the network code has to take into account certain things of how the game works. And writing an generic network code that would work for all situations is going to be pretty hardcore task.

So my best guess is to either you start using a network API on top of FIFE to run your network stuff through it (there are quite few good ones out there). Or wait until someone goes about writing network code for FIFE, which I cannot see happening in any near future if at all so using a ready API would be the best choice. Comes with a cost obviously, specially if it's a middleware.

But yeah, asset management server and object replication models on both server and client side (to name few required things...) but since you are thinking this I'm guessing you already know your network programming basics.

Logged
Name a programming language, I've probably used it. Sadly enough.