Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: One UI solution to end them all: UI API  (Read 588 times)

roothorick

  • Escaped Lunatic
    • View Profile
One UI solution to end them all: UI API
« on: March 30, 2013, 12:21:12 pm »

I think this is the best solution possible for the incredibly cryptic UI, that should still satisfy its supporters.

Compile a list of places where the UI code connects to the game engine. Anywhere there's UI code and game logic in the same function, separate it out so the UI and game logic are in separate functions. Depending on how well segmented the code is this could be really short and simple (if a bit tedious), or incredibly long and hard (and very tedious). The separate d_init.txt / init.txt files suggest you're already in decent shape here.

Organize all these functions into one or a handful of header files. Note any structs they need and put their definitions in those header files too.

Modify your makefiles/project files so that the UI is compiled as a separate shared object/DLL. Write up a quick loader on the game code side of things, that loads this object, optionally reading the filename from a config file.

Write up some quick instructions on how to compile one's own UI DLL, and release it along with the aforementioned header files.

What you have now is a workable API for people to make their own UIs and frontends to the game. Let the modding community go nuts with it and the arcane UI problem will solve itself.
Logged

Trif

  • Bay Watcher
  • the Not-Quite-So-Great-as-Toady One
    • View Profile
Re: One UI solution to end them all: UI API
« Reply #1 on: March 30, 2013, 03:09:31 pm »

Please search for existing threads before submitting suggestions. An API has been suggested many many times, and it won't happen. Here's an answer from Toady's AMA last week:

Quote from: Toady One
Quote from: kouteiheika
Have you ever considered making the UI external to the game, so that somebody else could take care of it while you'd be able to fully concentrate on the simulation aspect itself? By external I mean - export appropriate API to control the game, and import a few symbols from the UI SO/DLL so that the game would be able to interact with it. Considering the fact that the game already reacts to the user input (hence you have those entry points that need to be exported already well defined) creating such interface should be only a matter of finding the time to do it.

The community has already proven that they have the ability to deliver superior UI (Stonesense, Dwarf Therapist, numerous tilesets, etc.), so why won't you leave it to them? There are limits to what one can do with memory hacking; a real API would make it possible to make something like Stonesense, but fully interactive. Wouldn't that be awesome?
I've thought about it. It seems like it would take a lot of work to maintain. I ditched the crappy 3D graphics of Armok 1, and adding features is so much faster now. This seems similar. There are lots and lots and lots of data structures, and the API would not be a simple thing, and it wouldn't be something I could just do once and then forget about.

If you want a more detailed answer, there's this thread.
Logged
Quote from: Toady One
I wonder if the game has become odd.