Welcome, Guest. Please login or register.

Pages: [1] 2 3
Print
Author Topic: Searching for a programmer for engine evaluation  (Read 17507 times)
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« on: February 23, 2009, 12:25:56 PM »

Just to inform you about the current status of engine evaluation. We decided to give FIFE a try but to not set things in stone before we found a programmer who would like to help with engine evaluation to see if FIFE would be suited for the purpose considering the compiled engine requirements.

One programmer found the project via our advert at happypenguin and was interested to get involved. However he didn't show up at the IRC channel lately so it's possible that he lost interest. We're currently advertizing at gamedev.net as well as at sourceforge (just posted the advert there today). I'll bump our thread at gamedev.net via the blog posting today and mention in the news update that we're still searching for a programmer.

While we can actually go on without a programmer and continue to flesh out setting and game mechanics, it would be useful to find somebody for the programming department as soon as possible nevertheless. I'll advertize the project at a couple of (game) programming forums over the course of the week and let's see how it will work out.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #1 on: March 18, 2009, 04:36:58 PM »

I'm interested but I'd like to know about what is needed before I go and do anything.

I've been programming for the last 25 or so years so I know a little about the subject. However, I live in China so IRC meet-ups could be a problem. Having said that, I'm usually free all day Monday and Friday from 4am - 4pm GMT.

Let me know!
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #2 on: March 20, 2009, 08:39:43 AM »

OK, so I've got everything installed and I'm slowly wading through the demo code.

I had a look at NPC's and I've written a quick and dirty guide to NPC's, which I put in the wiki http://wiki.parpg.net/Quick_%27n_dirty_guide_to_NPC%27s_in_demo

Next I'm going to look at the map editor and see how that works. I'm intending to build up a different demo from the one given.
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #3 on: March 20, 2009, 10:25:47 AM »

And for those interested, here's a (very) simple guide to the fife editor: http://wiki.parpg.net/A_Quick_Guide_to_the_FIFE_Editor
« Last Edit: March 20, 2009, 02:43:27 PM by mvBarracuda » Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #4 on: March 20, 2009, 02:37:13 PM »

Well, after more looking and talking with others, I'm of the opinion that some of the bad stuff I'm not happy with is more to do with the code of the Rio demo, not Fife per se.

I'm aiming to produce the 'Rio demo' for PARPG so I'm going to dig more and see what needs ripping out / staying in. Will update when I have more
Logged

Science is open-source religion
mvBarracuda
Admin
Community member

Posts: 1308



View Profile Email
« Reply #5 on: March 20, 2009, 02:41:59 PM »

Sounds good to me maximinus :-) The Rio demo is surely not the best example what can be done with FIFE. Feel free to check out Unknown Horizons. This team works on a FIFE-based real-time strategy game / economy simulation:
http://unknown-horizons.org/site/
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #6 on: March 22, 2009, 03:36:02 PM »

Well I now have a completely bare fife program working. I will work on adding a map that can be scrolled around tomorrow and put a guide up into the wiki.

If anyone has been working on the GUI side of things please PM me cos I'd like to add your code to the whole mix.
Logged

Science is open-source religion
maximinus
Community member

Posts: 694



View Profile Email
« Reply #7 on: May 19, 2009, 10:38:46 AM »

This programmer can now report back from the trenches. Please don't take this as a flame against Fife, it's my opinion so far.

Problems with Fife:

  • The documentation is not great. There are very few guides or how-to's
  • Pathing is done by tile and not per pixel, so it looks a little stiff
  • Objects larger than one tile are an absolute pain to handle
  • Pychan GUI looks ugly
  • It offers quite a few features that are not THAT relevant to game coding
  • You end up with a massive number of gfx and XML files, and there are no scripts to help you
  • Code not that well documented in places

What does it have? You can load a tile-based map and dump objects on it fairly easily, and it interfaces with Python OK.

I have to say that I would use a simple 3D engine (probably Ogre) and then wrap the functionality in Python. There are plenty of GUI's for 3D engines, and they almost all allow collision detection and blitting 2D images over the top, so that's most of what Fife does covered for us.

Anyhow, that's my 2c, given after swearing at Fife for the last few days at my inability to print a line of text on screen!, so I may not be in the best mood  Angry

I'd sure be interested in what anyone else thinks on this matter.
« Last Edit: May 19, 2009, 05:13:12 PM by maximinus » Logged

Science is open-source religion
zenbitz
Community member

Posts: 1164



View Profile
« Reply #8 on: May 20, 2009, 01:10:47 AM »

I don't think anyone is married to FIFE.
Did you have a look at the open source infinity engine?  GemRB I think?   We would have to rip the mechanics (D&D) out.
Logged

We are not denying them an ending...
We are denying them a DISNEY ending - Icelus
maximinus
Community member

Posts: 694



View Profile Email
« Reply #9 on: May 20, 2009, 01:46:29 AM »

I looked at GemRB but that has issues of it's own  Tongue

The alternative would be to go for 3D, since all the artwork is being done in 3D anyway. It would also allow bonus things like fog and dynamic lights. We'd just use an ortho projection to retain the isometric design.

To be honest I've been mulling this over recently because I seem to be spending more time fighting Fife than actually using it. I might, over the next week, whip up a technical demo using Ogre, using C++ as the 'view' but with all the game logic in Python (or just use Python-Ogre but last time I checked this was not easy to get up and running).
Logged

Science is open-source religion
qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #10 on: May 20, 2009, 02:02:58 AM »

In my humble opinion openFrag died from doing it's own engine and DungeonHack's development is extremely slow because of that too. jClassicRPG took a year to get where it is (one programmer fair to say) an it's still not ready for game production. Radakan was working on its own engine and decided to do text-only after a while. How long is FIFE in production?

All this means however, is that creating an engine takes time, not that it's impossible and doomed to fail.

I am more interested in it being possible to add content and shape it into a game rather than having an engine that satisfies all the wishes. I agree that tools need to exist though. Working with it should not be a pain in the behind.

My first idea is to try to find compromises with the existing engines.

What about the option of taking FIFE or GemRB and extending them or changing them?

Anyways, I'll try to understand you better:

    * The documentation is not great. There are very few guides or how-to's
    * Code not that well documented in places
I can't say anything about that. Adding documentation to FIFE instead of creating own engine which you will have to document too sounds nicer. IANAP (I am not a programmer Wink )
    * Pathing is done by tile and not per pixel, so it looks a little stiff
What does that mean? Pathfinding? or do you mean the tiles? - if its' the latter, it's rather simple to pre-render textures, even automatically. Not as simple as if the code handles it, but still simple.
    * Objects larger than one tile are an absolute pain to handle
Is an object an image? In that case it should be cut into tiles I assume.. Couldn't one work around in code and create "id"s that objects can carry so then it's clear they're the same thing?
    * Pychan GUI looks ugly
It probably can be made look better. This seems like to be more anger than an argument Smiley (IANAP, I didn't even try what you tried so I don't know the horror ^^)
    * It offers quite a few features that are not THAT relevant to game coding
The problem being that you think its bloated?
    * You end up with a massive number of gfx and XML files, and there are no scripts to help you
Pre-rendered will get you there Wink What scripts do you need? Even I can help writing such.
Logged
Sirren
Community member

Posts: 365


View Profile Email
« Reply #11 on: May 20, 2009, 02:08:07 AM »

I do agree that nobody's married to Fife.. I'm a bit worried about the 3d turn.. Secondarily becouse I don't like it very much.
There's another more important reason though: with 2d you work with pre-rendered sprites. With 3d your 3d stuff gets rendered right there on the spot: polycount/textures size and number/kind and number of bones the model is rigged to start to really matter.  For Fife I simply make a texture and play with the material settings before rendering.For a 3d game I should make at least specular and bump maps. Maybe a normal map too, I don't know. It's a ton more work.
In addition to this I have 3 years experience with 2d. Going 3d dos not mean I'm starting from zero but..
I don't know, this is something to be considered carefully.
Logged
maximinus
Community member

Posts: 694



View Profile Email
« Reply #12 on: May 20, 2009, 05:08:51 AM »

In my humble opinion openFrag died from doing it's own engine and DungeonHack's development is extremely slow because of that too. jClassicRPG took a year to get where it is (one programmer fair to say) an it's still not ready for game production. Radakan was working on its own engine and decided to do text-only after a while. How long is FIFE in production?

All this means however, is that creating an engine takes time, not that it's impossible and doomed to fail.

By no means would I suggest an engine re-write  Shocked I'm just thinking that what you get in fife is not a lot more than what you already get in Ogre, a 3D engine (and Ogre gets you a load of other features as well).

Anyways, I'll try to understand you better:

    * The documentation is not great. There are very few guides or how-to's
    * Code not that well documented in places
I can't say anything about that. Adding documentation to FIFE instead of creating own engine which you will have to document too sounds nicer. IANAP (I am not a programmer Wink )

Agreed, but I have to try and understand it before I can document it  Wink

    * Pathing is done by tile and not per pixel, so it looks a little stiff
What does that mean? Pathfinding? or do you mean the tiles? - if its' the latter, it's rather simple to pre-render textures, even automatically. Not as simple as if the code handles it, but still simple.

The gfx only moves along the edges of the tiles, rather than by pixel, so the pc rarely looks like they are going in a straight line. I know that this is partly due to using 2D graphics.

    * Objects larger than one tile are an absolute pain to handle
Is an object an image? In that case it should be cut into tiles I assume.. Couldn't one work around in code and create "id"s that objects can carry so then it's clear they're the same thing?

Yes, they can but cut in tiles, and yes, a work-around in code could be used. This is why they are a pain to handle  Sad

    * Pychan GUI looks ugly
It probably can be made look better. This seems like to be more anger than an argument Smiley (IANAP, I didn't even try what you tried so I don't know the horror ^^)

Not real anger, the PyChan FAQ states that one the problems with PyChan is that is looks ugly!

    * It offers quite a few features that are not THAT relevant to game coding
The problem being that you think its bloated?

Not bloated but that they should have concentrated on 'what do you need in a game'. There's virtual file systems, for example, and I've never need them in a game that I've written before.

    * You end up with a massive number of gfx and XML files, and there are no scripts to help you
Pre-rendered will get you there Wink What scripts do you need? Even I can help writing such.

Minor quiblle, it just seems that you end you with a very complicated mess of many many small files.
« Last Edit: May 20, 2009, 08:26:50 AM by maximinus » Logged

Science is open-source religion
Dave Matney
Community member

Posts: 230


29640090 naveofhearts@hotmail.com naveking matneyx
View Profile Email
« Reply #13 on: May 20, 2009, 05:12:18 AM »

I don't think anyone is married to FIFE.
Did you have a look at the open source infinity engine?  GemRB I think?   We would have to rip the mechanics (D&D) out.

D&D Rules aren't THAT bad.  GemRB runs old 2nd ed. rules, which are a bit more complicated when it comes to dice rolling, but might actually work better in a video game.  If it runs 3rd, like Icewind Dale 2 did, we'd have immediate supporters from the d20 crowd.

But I'm getting a D&D tattoo, so I'm a bit biased.  Wink

In any case, it sounds like there's already a proposal to write a unique combat system, which would require reprogramming combat no matter which engine we use.  I say pick the one that the coders like the best ('cause they'll be doing all the work, anyway), and everyone else can just deal with it.
Logged
qubodup
Admin
Community member

Posts: 261



View Profile Email
« Reply #14 on: May 20, 2009, 11:12:53 AM »

Hm. DungeonHack and OpenFrag used/use OGRE. (And Radakan and jClassicRPG used/uses jMonkeyEngine)

I say pick the one that the coders like the best ('cause they'll be doing all the work, anyway), and everyone else can just deal with it.
Seconded!

If 3D will be considered: see if scoure's engine might do the trick. There's also Warzone 2100 and Glest.
Logged
Pages: [1] 2 3
Print
Jump to: