FrancoTAU
Cipher
What happened with the Ultima remakes? I thought they kept asking for permission from EA and got no responses. So, they just went ahead and did it anyways and EA still doesn't care. Am i wrong with that story?
-
Welcome to rpgcodex.net, a site dedicated to discussing computer based role-playing games in a free and open fashion. We're less strict than other forums, but please refer to the rules.
"This message is awaiting moderator approval": All new users must pass through our moderation queue before they will be able to post normally. Until your account has "passed" your posts will only be visible to yourself (and moderators) until they are approved. Give us a week to get around to approving / deleting / ignoring your mundane opinion on crap before hassling us about it. Once you have passed the moderation period (think of it as a test), you will be able to post normally, just like all the other retards.
FIFE - a cross platform isometric game engine
- Thread starter mvBarracuda
- Start date
bryce777
Erudite
FrancoTAU said:
Yeah you would have to be COMPLETELY stupid to ask permission to do a remake, and they would have to be COMPLETELY stupid to respond to you if you did so.
If they did respond, it would be to say no.
There is no 'yes' response that doesn't weaken any eventual case they might have if someone did something idiotic like make a game and call if Ultima X, but as long as you don't package the game itself or package modified artwork you are legally fine.
The modifified artwork will not cause any prblems most likely, either, so long as the game is still required....
FrancoTAU said:
Ultima 4 is the only one they officially allow to be remade from scratch, IIRC. It's okay to make engines that work alike so long as they require the original content.
Sarvis
Erudite
LCJr. said:
That's why they are <i>development tools</i> instead of, say, crayons.
bryce777
Erudite
Sarvis said:
Well, the mod tools I am making are designed for the average schmuck, in case I actually ever release them
Oarfish
Prophet
- Joined
- Sep 3, 2005
- Messages
- 2,511
Gwendo said:
Yep, its a scripting language designed primarily for embedding into applications - its compact architecture and simplicity make it a good bet for game scripting and application extension.
http://www.lua.org
mvBarracuda
Augur
- Joined
- Jun 7, 2006
- Messages
- 478
Fallout Zero is the first and only announced FIFE project ATM.Gwendo said:
But we're not really in the state where we can convince mods to change to FIFE yet. We hope to be at the point in about 4-6 months (depending on if we find new devs and how much time the current devs can put into the project). We're in contact with the FanMadeFallout mod (the project leader is DarkUnderlord, I guess you know him ;-)) and try to convince them to change to FIFE.
If the planned scripting feature and the editor comes along good, we feel that it won't be that hard to convince other Fallout mods to change to FIFE. But I woulnd't decide for FIFE ATM if I wouldn't be part of the team. The Zero guys used FIFE because some of their members are actually part of the FIFE team too. So they can judge the progress better than people from outside.
So with the editor beta test we'll launch another promotion offensive and hope to convince some guys to start working with our engine. We're confident that more people are willing to change as soon as the engine shows it full potential; unfortunately we're not at this point yet.
FrancoTAU
Cipher
Saint_Proverbius said:
I was thinking more along the lines of borrowing the license to even make the game to begin with. With Lazarus, you don't even need the original Ultima V. And they're certainly using copyright intellectual property. I guess you're clear to use Lord British all you want at least
Sarvis
Erudite
bryce777 said:Sarvis said:
Well, the mod tools I am making are designed for the average schmuck, in case I actually ever release them
Well, that's what the NWN toolset was for too. The problem was you got two kinds of modules: Really really good modules by guys who could handle the programming, and really really crappy modules by guys who could plop down monsters in the toolset.
Building a map is easy, though of course clearly more limited than in something like Quake. Placing monsters is equally easy, as is modifying their stats.
The problem was to do anything <i>interesting</i> you had to use the scripting language, which essentially ran into hordes of complaints that the toolset was too complex for non-programmers to use.
It's not at all hard to create a level designer for an idiot, we had that even back in the NES days with Excitebike. The problem is that if you intend for people to develop anything interesting, they need more complex tools to do it with.
bryce777
Erudite
Yeah, I plan to do things much more extensive than that and have already done a fair bit of it.
Basically, complete control over the rule system (mostly done), such as how items work, how leveling or skill increase works, etc.
In addition, I want to make tools to create quests that don't require any sort of scripting language.
Basically, complete control over the rule system (mostly done), such as how items work, how leveling or skill increase works, etc.
In addition, I want to make tools to create quests that don't require any sort of scripting language.
mvBarracuda
Augur
- Joined
- Jun 7, 2006
- Messages
- 478
As I'm new here: do you work on an engine yourself? Sounds like you're working on a RPG creation system or did I get something completely wrong?bryce777 said:
Hmm that sounds great but I'm still not really convinced if this will work out. I'm with Sarvis in this case: you could make a simple quest generator but these kind of quests will be always quite boring. You'll need a serious scripting language like LUA or Squirrel to give the modders the power to create some really good quests.bryce777 said:
But feel free to prove me wrong. I just haven't seen a simple RPG creation tool that doesn't sacrifice the flexibility for this easiness.
Will a use-based skill system be possible? Will it be possible to make it context sensitive to any game world situation?bryce777 said:
Why? If you don't want the bother of creating a language, or incorporating an existing one, that's fair enough. I don't think it's the best way to do things though.
A scripting language can make things much more versatile. If you have a scripting language, but allow people not to use it to create quests, you encourage people to stick to stuff that's possible without the language (which probably won't be too interesting). If you force people to use the language for simple stuff, they'll quickly see that it's actually not too complicated, and might use it to get more ambitious.
If you make it significantly easier to make formulaic, uninspired quests, then you'll get a lot of them.
Perhaps you can make tools which are as versatile as a scripting language (though I have my doubts), but that would probably end up being more work for you, and less user friendly.
bryce777
Erudite
mvBarracuda said:
It's all in the design. GUI is easy to make, but it's hard to design actual functionality to go behind it.
So far I have no engine, I am just working on the basic tools and when I feel that is ioned out I will worry about that part.
I may make it so it uses another actual engine - I plan to make an actual game eventually, though, not just a toolkit, and it will not be open source. At least, I do not plan that for now.
bryce777
Erudite
"Will a use-based skill system be possible?" Absoultely. Fallout is one of the template rulesets I am starting with.galsiah said:
"Will it be possible to make it context sensitive to any game world situation?" I am not sure what you mean. Do you mean tie it to dialog, run a check due to an arbitrary event etc.? This is definitely planned. Everything will be event based, with events including passage of time, npc proximity, entering a room, etc.
note I am not there in the coding phase (which I hope t restart soon) so I don't have every detail hashed out but I want to make it so that NO actual scripting is required. Instead you define an event, which can be tied to an npc, the player character getting attacked or getting killed even, an npc attacked or killed, then you tie a consequence to it, which can be monster spawning, health gain/loss for any character or pc, or basically any consequence/action I can think of. If people think up one I didn't, then I will add it if it's even marginally possible and sensical.
As for a scripting language, I am still pondering the pros and cons.
I think people have a certain idea about what's possible based off of current tools out there. Whenever I attempt a project, being the primadonna I am, I strive to make it the Ultimate whatever it is I am doing, that takes all cases into account and solved the problem completely so it will not need to ever be revisited by the client.
Mostly I have made the rules tools and some file format stuff, both of which I am still tweaking. Next up is quest creation. Any quest in fallout will be doable with the tools I have envisioned, as an example. Not only that, but doable very quickly, and in such a way that they are verifiable as valid completable quests with all failure conditions clearly spelled out. I can't verify all dialog makes sense, but I am also planning a graphical testing tool that allows you to actually play the whole quest out in an accelerated mode by puting all the relevant NPCs and items into a an area where you can talk to them or get the items, etc. etc. There are some kinks to work out, such as the accesibility of NPCs - say such and such a guy is in Big City and for some reason you can't ever go back to Big City after a certain point . So, the quest is uncompleteable. I think this is largely a matter of being good about informing the user that this could be a problem, though.
Basically, you will create the NPCs first, then any items used, then assign quest dialog for any of the NPCs involved, which is context dependent on what has been said to other PCs and items held or information known, and possibly player stats and skills, if the quest is designed this way.
For information, plan to have that as a creatable object as well. Then you can add in means of discovery; this could be going to a location, reading a book or journal or sign, gleaned from a conversation, or some combinations of all these means and perhaps others. Having a piece of information can then open up more dialog and can also be used as a general event trigger such as 'PC meets NPC 5 and knows NPC 5 killed his father' causes PC to shout "You killed my father, prepare to die!" and initiates combat.
So, does that sound good? Does it even make any sense?
With some of this, I am sure that only once people play with it 1) will I know if it actually works for a normal person and 2) will most people get what the hell I am talking about - or hopefully get it, depending how well I do.
Here's hoping you're very closed minded, or that's a recipe for disaster. If you're taking that attitude, you need a very precise, realistically restrictive definition of "the problem".bryce777 said:
It seems like you're adopting a totally object oriented framework, rather than a functional (i.e. scripted) one. I don't think that's a great idea. On some level, going to a functional view will always be simpler.
Take a choice between writing:
Code:
if (condition1 && condition2)
//do something
endifI'd go for the coded version any day.
Also, without very good organization, the object oriented view is going to turn into a complete mess once things get complicated. Scripts at least provide the opportunity for clients to organize things however they like within a script.
Of course you can get good / flexible organization, and you can get all the functionality of scripts by having a load of objects with possible connections to just about everything else. I just think that doing that well would be a lot harder than using scripts.
If you set the layout and relationships of all the objects yourself, then it'll probably lose out to scripting in terms of versatility. If you allow any layout / relationship between objects, you're basically saying to clients "Look, you don't have to use funtional programming - you just need to use object oriented programming.". For anything non-trivial, OO has a steeper learning curve than scripting.
If your aim in not using scripting is to make things easier for clients, then I think it's not a good idea (unless you're willing to sacrifice flexibility). If you're aiming for flexibility, but not ease of use, a more OO solution makes sense in an ideal world, but I think it'll take you forever.
It sounds like a good ideal solution, but I think it'll take a lot longer to get things working to your satisfaction without using scripting.
Sarvis
Erudite
Well, I'm not entirely sold on the concept that OO is inherently more complex to learn... honestly in some ways I think it makes more sense. If you have an Airplane object, it's fairly natural to expect to have methods like RetractLandingGear, and TakeOff.
Anyway, the problem is that the larger you make your objects/events the less flexible they are. The smaller you make them, the more complexity there is for actually getting anything done.
So, for instance, it's relatively simple to have an Airplane object and give that to a user to use. But then all the user can ever use is an Airplane. You could make the objects smaller, and have PassengerCompartment, LandingGear, Wings, Engines and Cockpit... then suddenly you have a bit more flexibility (perhaps use Wings, Engines and Cockpit to make a small plane, but Wings, Engines, Cockpit and PassengerCompartment for a larger aircraft.)
You can see though, that just to get the flexibility for two different types of planes you increased the complexity by a factor of 5!
Now, while just about anyone could handle the complexity necessary to set an Airplane.Fly event to a button press event, a lot of people might not be able to understand putting all those smaller objects together to create an airplane object that can fly.
Anyway, the problem is that the larger you make your objects/events the less flexible they are. The smaller you make them, the more complexity there is for actually getting anything done.
So, for instance, it's relatively simple to have an Airplane object and give that to a user to use. But then all the user can ever use is an Airplane. You could make the objects smaller, and have PassengerCompartment, LandingGear, Wings, Engines and Cockpit... then suddenly you have a bit more flexibility (perhaps use Wings, Engines and Cockpit to make a small plane, but Wings, Engines, Cockpit and PassengerCompartment for a larger aircraft.)
You can see though, that just to get the flexibility for two different types of planes you increased the complexity by a factor of 5!
Now, while just about anyone could handle the complexity necessary to set an Airplane.Fly event to a button press event, a lot of people might not be able to understand putting all those smaller objects together to create an airplane object that can fly.
bryce777
Erudite
"On some level, going to a functional view will always be simpler. " Simpler to do simple things, yes. Simpler in practice but also a great deal of work will have to be done. It's also work simple to you and me, but not simple to the average joe who is a gaming enthusiast but has never cracked open a programming book let alone done it for a living.
For me the scripting issue will have to be decided once I have a mostly complete system and ask myself "Ok, are there things I can't do? Can I make a way to do them? Are they doable in an easy, reliable way?"
Scripting big stuff is very time consuming, and making context sensitive dialog is not only a real pain in the ass but very, very buggy. Tons of playtesting would need to be done to make an rpg like that using traditional methods.
The problem with your code example is that you have to define each of these items, as well as define the conditions themselves. It is easy to mod an already existing game with hardcoded rules - the drawback is that you are largely stuck with these rules and I have seen that altering them slightly causes a ton of work - just look at the oblivion mods. The downside of the flexibility is complexity; not complexity of use as that is a design question, but complexity in what you are doing and checking. Doing it by hand would be very difficult with a complex ruleset. Also, you are coming from the perspective of a coder, not a layperson who wants to do some modding.
"Also, without very good organization, the object oriented view is going to turn into a complete mess once things get complicated." Well, the idea is that instead of doing mod tools as an afterthought over a weekend they will be the emphasis of the project from the very start.
'"Look, you don't have to use funtional programming - you just need to use object oriented programming.". For anything non-trivial, OO has a steeper learning curve than scripting.' I am not 100% sure what you mean, but the idea is to present things in such a way that no programming or really even logic is needed.
As to how difficult this will be, I don't have every detail flushed out, but I don't foresee much difficulty with making something that is easy to use.
The only real worry in my mind is strange special cases, but I am hoping that will just be a matter of adding in things as I go.
For me the scripting issue will have to be decided once I have a mostly complete system and ask myself "Ok, are there things I can't do? Can I make a way to do them? Are they doable in an easy, reliable way?"
Scripting big stuff is very time consuming, and making context sensitive dialog is not only a real pain in the ass but very, very buggy. Tons of playtesting would need to be done to make an rpg like that using traditional methods.
The problem with your code example is that you have to define each of these items, as well as define the conditions themselves. It is easy to mod an already existing game with hardcoded rules - the drawback is that you are largely stuck with these rules and I have seen that altering them slightly causes a ton of work - just look at the oblivion mods. The downside of the flexibility is complexity; not complexity of use as that is a design question, but complexity in what you are doing and checking. Doing it by hand would be very difficult with a complex ruleset. Also, you are coming from the perspective of a coder, not a layperson who wants to do some modding.
"Also, without very good organization, the object oriented view is going to turn into a complete mess once things get complicated." Well, the idea is that instead of doing mod tools as an afterthought over a weekend they will be the emphasis of the project from the very start.
'"Look, you don't have to use funtional programming - you just need to use object oriented programming.". For anything non-trivial, OO has a steeper learning curve than scripting.' I am not 100% sure what you mean, but the idea is to present things in such a way that no programming or really even logic is needed.
As to how difficult this will be, I don't have every detail flushed out, but I don't foresee much difficulty with making something that is easy to use.
The only real worry in my mind is strange special cases, but I am hoping that will just be a matter of adding in things as I go.
bryce777
Erudite
Sarvis said:
Well, that is why I will have some templates to start with that have some basic rule systems. GUI will be contextual based off of the rule system: ie if you ahve DnD you choose an NPC's strength, intelligence etc. with sensible defaults for most things - so you don't have to choose the strength for every inkeeper and serving wench in the world.
For events, you will need to create them at a fairly low level, but I don't think it will be difficult except when you have things that are complicated, and in those cases I don't think it will be any worse than trying to script it.
Sarvis
Erudite
bryce777 said:
Well, that's basically exactly what the NWN toolset is like, and a lot of people complained it was too complex to do anything interesting with.
Sure - the concept is simple to learn. It's implementation of a complex system using that concept that's hard.Sarvis said:
A good design for a mid-sized funtional program is helpful, but it's not impossible to code without much design by thinking "what do I want to happen next?". Functional programs have a fairly linear form, so much of the time you can just follow your nose.
With a mid-sized OO program, you can't do that. Without a much more structured, well thought out design, you'll end up with a mess. Perhaps the functional program would be a mess too, but I'd give it much higher odds of being a working mess.
I agree that it's a different perspective, but I don't think that simple scripting is beyond anyone with the capability of putting together a good design. I don't think your average joe has much trouble knowing what this means:
if ( conditionIsTrue )
// do something
endif
It's code, but it's hardly rocket science. The hardest thing for the average joe is to realize that scripting is not rocket science, and that quite a bit can be achieved without any previous programming knowledge.
Agreed - scripting dialogue is not the best way to go about it. With dialogue there's a lot you can assume, which allows you to reduce the complexity, and prevent errors. It's probably a good candidate to handle outside a scripting language - though you'd clearly need comunication between a dialogue system and any scripting language.
Oh sure - I'm certainly not suggesting that everything needs to be done through scripting. I just think that at some point it's the best way to go.
No coding, perhaps, but if you're arranging a versatile range of objects and defining connections between them and responses to events, you are programming - even if you don't think of it that way. The skills needed to organize a system of objects and relationships to form a working system are the same - whether you're clicking a button, or declaring a class.
The client is going to have to do all the same thinking - which is the hard part. He just won't be writing code - i.e. the easy, mechanical (once you've done all the thinking) part.
It makes sense to handle some things outside a scripting language, but that'll either be more restrictive (not necessarily a bad thing so long as the restrictions are reasonable), or it'll be a lot of work.
bryce777
Erudite
Sarvis said:
Well, at a certain point you have to have a cutoff for who your tools are for. If they are too stupid to push the picture of a hamburger and take your order, they are not going to make much of a mod anyhow.
bryce777
Erudite
Galsiah -
Well, yeah, you still have to design your rules and if they suck your game will suck. Nothing will ever change that.
I am not dead set against scripting being possible, but it is something I want to evaluate once I have a basically finished product and see what issues are outstanding.
As for it being programming, I think you are getting too caught up in the event 'programming'. The complex stuff will be the rules and to a large extent the dialog. The events should generally be very easy - most of the time you will make one check and have one consequence. The whole idea is to try and have the basic potential checks and consequences already predefined according to your ruleset so all you need is to plug in some numbers or occasionally make a compound check that works slightly different.
As for quest complexity, there will be no templates for actual quests.
The way I see quests working is you would find/create the npcs and objects involved, then you would go through and set up the dialogs you want and then set some dialogs to be context sensitive IE have you completed the mission/quest, if so you get a success dialog and some sort of reward. this includes having lots of dialog that opens up due to talking to this person or another first. It is actually sort of jelling in my head as I type, but I am still a long way from solid on all the details.
Well, yeah, you still have to design your rules and if they suck your game will suck. Nothing will ever change that.
I am not dead set against scripting being possible, but it is something I want to evaluate once I have a basically finished product and see what issues are outstanding.
As for it being programming, I think you are getting too caught up in the event 'programming'. The complex stuff will be the rules and to a large extent the dialog. The events should generally be very easy - most of the time you will make one check and have one consequence. The whole idea is to try and have the basic potential checks and consequences already predefined according to your ruleset so all you need is to plug in some numbers or occasionally make a compound check that works slightly different.
As for quest complexity, there will be no templates for actual quests.
The way I see quests working is you would find/create the npcs and objects involved, then you would go through and set up the dialogs you want and then set some dialogs to be context sensitive IE have you completed the mission/quest, if so you get a success dialog and some sort of reward. this includes having lots of dialog that opens up due to talking to this person or another first. It is actually sort of jelling in my head as I type, but I am still a long way from solid on all the details.
mvBarracuda
Augur
- Joined
- Jun 7, 2006
- Messages
- 478
Sorry for the long delay guys :-/ I've been pretty busy with university lately.
Our coders were hardworking last week and we're proud to bring you yet another experimental FIFE release of the new 2006.2 branch.
New features:
* Optimized AsyncSM
* New camera mode for smooth scrolling
* Fixed many memory leaks
For a complete changelog:
* https://mirror1.cvsdude.com/trac/fife/engine/timeline
Grab the win32 binaries here:
* http://members.fifengine.de/bin/FIFE_r673_win32.exe
Linux users simply check out our SVN repository and compile the TRUNK/core branch from source
* http://wiki.fifengine.de/index.php?titl ... repository
Our coders were hardworking last week and we're proud to bring you yet another experimental FIFE release of the new 2006.2 branch.
New features:
* Optimized AsyncSM
* New camera mode for smooth scrolling
* Fixed many memory leaks
For a complete changelog:
* https://mirror1.cvsdude.com/trac/fife/engine/timeline
Grab the win32 binaries here:
* http://members.fifengine.de/bin/FIFE_r673_win32.exe
Linux users simply check out our SVN repository and compile the TRUNK/core branch from source
* http://wiki.fifengine.de/index.php?titl ... repository
As an Amazon Associate, rpgcodex.net earns from qualifying purchases.