I think if people want to extend the OHR, they're better off writing a branch. Not only do they not have to worry about cross platform shenanigans, but you also avoid DLL hell on Windows.
Maybe a different idea would be what I was going for with the Aileron prototype and break the engine into modules. This way you could seperate out the battle system into a module, so if somebody wants to program a new battle system they can pull out the 'classic' battle module and drop in their new battle module and recompile, or have the engine load the module as specified by the .rpg file. This keeps the .rpg files inert, maintains cross platform compatibility, and so on. As it is I'm afraid most DLLs would be just used to do things the engine shouldn't be really doing in the first place, like how most extension DLLs for Game Maker were '3D game dll!111'. At some point you're just better off writing a new engine on itself without the restrictions of the .rpg format On Fri, Jun 12, 2009 at 6:18 PM, James Paige<b...@hamsterrepublic.com> wrote: > On Fri, Jun 12, 2009 at 03:48:45PM -0700, Jay Tennant wrote: >> >> James Paige wrote: >> > >> > On Fri, Jun 12, 2009 at 03:08:43PM -0700, Jay Tennant wrote: >> > > >> > > -------- Original Message -------- >> > > > From: James Paige <b...@hamsterrepublic.com> >> > > > Sent: Friday, June 12, 2009 3:28 PM >> > > > To: ohrrpgce@lists.motherhamster.org, hierand...@crazyleafgames.com >> > > > Subject: Re: [Ohrrpgce] Plotscripting plugins >> > > > >> > > > On Fri, Jun 12, 2009 at 11:15:15AM -0700, Jay Tennant wrote: >> > > > > I read Mike's discussion of building plotscripts plugins. I think >> > > > > that's a great idea. I've been working alot with developing plugins >> > > > > for scripting operations. >> > > > > >> > > > > In the discussion posted at: >> > > > > http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_plotscripting_plugins >> > > > > >> > > > > Mike suggested a manifest, dll, and so for the plugin package. The >> > > > > manifest was used to define every function's info (name and param >> > > > > info). However, I've been experimenting with building plugins that >> > > > > tell the scripter what functions it has and all their info, without >> > > > > needing a manifest. Of course, I've only been using windows >> > > > > procedures on dll's, such as GetProcAddress() and GetModuleHandle(). >> > > > > And this is all in C and C++ (The code is C compatible). >> > > > > >> > > > > The benefit to not needing a manifest is less files--one need not >> > > > > have to write the manifest. The downside is that native calls from C >> > > > > are slightly more cluttered. >> > > > > >> > > > > ----Building the plugin architecture: >> > > > > How does one craft the script function importer? What about the >> > > > > dll's themselves (or SO's)? And how can one successfully call these >> > > > > functions from the scripter? >> > > > > >> > > > > Please see my discussion at: >> > > > > http://www.win32developer.com/phpbb3/viewtopic.php?f=4&t=152 >> > > > > >> > > > > What are your thoughts? >> > > > > >> > > > > hierand...@crazyleafgames.com >> > > > >> > > > (What follows is not my final word on anything, it is just my gut >> > > > feelings about the subject) >> > > > >> > > > I would really not want a plugin feature to be supported by the main >> > > > OHRRRPGCE distribution. I'm not saying you shouldn't do it if you think >> > > > it would be cool, but it would have to be on a branch, I would not >> > > > integrate a feature like that. >> > > > >> > > > My main beef with a plugin feature would be that it would break >> > > > sandboxing. >> > > >> > > I agree. However, plugins are a singular file in addition to the RPG >> > > file. They should be a superset of functionality. And if the plugin is >> > > absent, a graceful fall-back mechanism could be in place. >> > >> > But if a graceful fallback was possible, what would the purpose of the >> > plugin be? >> >> I don't know. Perhaps performing special screen effects, special sounds, >> playing movies. A graceful fallback could be just not performing those >> items, but not crashing the engine. I guess the game designer would have to >> watch for that, like a web programmer building pages for ie, mozilla, >> chrome, safari, opera, and all their iterations. > > I really want to avoid making game designers worry about different > featuresets being available. That is why backwards compatability is such > a high priority in each new update. > > As for special screen effects, I think the best way to do that would be > as a built-in feature. > > I see no need for special sounds, since the built-in sound effect > support is already good > > As for videos, again, if we were to support videos, I would want it to > be a built-in feature that would work the same for all games. > >> > > > It would allow people to make games that execute arbitrary >> > > > code, which means that an RPG file could become a vector for malware. >> > > >> > > But on the other side of the blade, you have extensibility. It's been >> > > discussed about adding support to plotscripting for user created >> > > functions. This is one solution to that. >> > >> > User created functions have always been available in plotscripting. >> > Maybe I misunderstand your meaning? >> >> I'm sorry, I was thinking about user structs. This wouldn't support that >> either. > > Ah, the plan for eventually adding user structs would be an extension of > this plan: > http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_dynamic_types_in_HamsterSpeak > >> > > Besides, extending the ability of the app is already being done, with >> > > officially supported releases. I remember when windows 32bit sound >> > > became supported. Perhaps officially supported plugins could also be >> > > released. Perhaps other restrictions/warnings could be imposed on the >> > > non-official plugins. >> > >> > Now if you are talking about plugins for music and sound and video as an >> > alternative to the current statically linked music and gfx backends, >> > that seems like something different than the feature suggestions of >> > plugins bundled with RPG files. >> >> Not totally. For instance, if a graphics api is referred to in script, >> perhaps the user wants to load a specific visual effect (in directx, .fx >> files). And maybe they control the params from script. > > Unfortunately direct access to directx effects could never be done in a > cross-platform way. > >> > > Further, if you wanted to contain a dll's calls (I'm just using dll's as >> > > example) to only within itself, you could impose something like Detours >> > > API from Microsoft Research: >> > > http://research.microsoft.com/en-us/projects/detours/ >> > > That would prevent outside apis being called. >> > >> > That sort of containment is a VERY difficult task. To do it in a cross >> > platform way is an EXTREMELY difficult task. >> >> Actually, detours made it pretty easy. The cross platform part makes >> complications. >> >> > I read a little about detours, and it sounds like a tool for >> > instrumenting windows api calls. I don't think it would be practical to >> > use it to sandbox dll files. >> >> Well, the Detours docs say you can write in the assembly header of the >> binary to not load any dll's, not just windows apis. And really, this was >> just a suggestion if worried about security. > > So with detours, so you just just use it to block all api calls in a > list of known unsafe functions? Or can you block everything and then > only enable known-safe functions? > >> > > > My second beef with this feature would that it would be difficult to >> > > > keep portable. Right now, cross-platform comptability between Linux and >> > > > Windows is a high priority, and an important goal is portability to a >> > > > wider range of platforms, including portables. I'm not saying it would >> > > > be all that ahard to keep a plugin portable, but it is a possible >> > > > concern. >> > > >> > > Sounds like you're having a cow with this. (knee-slap) jk. Seriously, I >> > > know nothing about Linux, SO files, and portables. >> > >> > Hehe Mooooooo! >> > >> > > > My feeling is that while plugins are not a bad idea at all from a >> > > > game-making and game-distrubtion point of view, they are really at-odds >> > > > with the purpose and goals of the OHRRPGCE >> > > >> > > But the purpose of OHRRPGCE is to make games, and currently many games >> > > are transferred via compressed folders, which carry the game and >> > > sometimes text files, and sometimes other stuff. Perhaps I'm missing the >> > > point. >> > >> > Well, what sort of plugins do you have in mind? If there was a plugin >> > feature in the OHRRPGCE, what would you do with it? What would you >> > expect other people to do with it? >> >> Making the scripting extensible has many applications. The mentioned >> graphics, sound, and other service apis could become available and >> controlled. > > Can you be more specific? I mean, can you describe how a game might use > these things? > >> But I was thinking about initiating a server and client set of commands, >> allowing network games with global scripts and local scripts. Extend >> OHRRPGCE into multiplayer, or mmo, type of games. Even if it's just simple >> chat in game. > > Network commands for multiplayer have come up for discussion before. > > I really think of the goal of the OHRRPGCE as to make retro 2D single > player games. > > For making multiplayer games, I feel like one should be working in a > totally different engine. There are actually a decent selection of RPG > engines and game making engines available that are focused around > networkable games. > > I guess what I can see being a reasonable fit for the OHRRPGCE would be > simple exchange of data, not so much oriented towards simultaneous > multiplayer, but maybe something to facilitate data sharing, kinda like > what happens in Pokemon games. > > Despite my misgivings about networking, I am willing to discuss it as a > possible built-in feature for some future version, but I don't like > platform-specific plugins as a method of implementing it. > > --- > James > _______________________________________________ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > _______________________________________________ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
