Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[axus]

actually in c-evo the way the game shared info was providing pointers to memory, and sharing the data structures so that clients can access them directly when they want and quickly.  The info that's sent is more like events to give the client a hint about what's up... it would request memory if it needed it.

c-evo development pattern is similar to dwarf fortress, where a single programmer works for years perfecting his game engine and shares it for free.  Steffen ended up open sourcing it after he got a real job, though  

[Armok]

I suppose if something like this was done it would only send what the player knows, for example it wouldn't send data on thing that are outside the line of sight in adventurer mode, I imagine for every tile maybe something similar to what you would get whit the [l]ook command, but somewhat more codeish and readable by a computer, somewhat like the raws, but I know probably even LESS about this "client/server" stuff than Toady. [/ridiculously long sentence]

[Serialized]

It would be very cool to have the rendering done in a DLL, specifically a DLL which has access to enough game state to draw in 3D. Perhaps the easiest way would be to allow the renderer to have pointers to most or all of game state. The internal game mechanics could be kept closed source, while the game data classes would be shown. A disclaimer, claiming no support (like Blizzard does with their map editor) could be made.

While making the renderer a DLL would be cool, it might not be realistic, at least right now. An excellent short term addition would be to complete Core 50 early, and that's my vote.

Core50, TILESET SUPPORT, (Future): Allow graphical tiles to be used for all game objects.

I think tilesets would open up the game to vastly more people than currently play. I'd love to see tilesets implemented next or soonish.

[Malenfant]

quote:Originally posted by Toady One:
<STRONG>*snip*
It could also just pass across a pointer to the object list and let them do all the culling, but then I'd have to publish all my object definitions, which I'm somewhat leary of, and I'd also have to maintain and update and explain that information constantly, which is a lot more work for me.  Or I'd have to set up a second object list with less information that gets sent across?  In which case the performance of DF in general decreases as this new data structure is maintained.  Or perhaps there's something else.</STRONG>

As a programmer I understand your learyness  

I think it goes without saying that if you did open up the game state data for 3rd party interfaces it would be done on the provision that no support is intended or implied. My whole idea is that this system would free up your time for the core game mechanics; not detract from them. Anyway supporting something like this would ruin the fun, we're supposed to endlessly muse over the inexplicable foo variable stored against all dwarves and mollusk objects.

As to how it is done, is it perhaps possible to filter the object data down to a smaller subset without having to replicate it in full? I'm not really sure but I would have assumed other projects have faced similar problems.

[Serialized]

quote:Originally posted by Malenfant:
<STRONG>

As a programmer I understand your learyness  

I think it goes without saying that if you did open up the game state data for 3rd party interfaces it would be done on the provision that no support is intended or implied. My whole idea is that this system would free up your time for the core game mechanics; not detract from them. Anyway supporting something like this would ruin the fun, we're supposed to endlessly muse over the inexplicable foo variable stored against all dwarves and mollusk objects.

As to how it is done, is it perhaps possible to filter the object data down to a smaller subset without having to replicate it in full? I'm not really sure but I would have assumed other projects have faced similar problems.</STRONG>

The DLL could have functions that take a pointer to an object of a class that contains all the necessary game data, (the Object itself would hold pointers to the game data, which themselves may be pointers to various game data classes). The game data interface would be exposed to the DLL. Toady would write his own renderer using this system, and the source for that could be released as a template. More game data than his renderer uses (all the renderable game Z levels, which could be used for making 3D clients, etc) could be exposed without any hit to performance, since it would only be passing a pointer to the game data object.

Basically:

gamedata.h contains the specification for the game data class which contains all the renderable game data, or possibly all the game data, for simplicity. This header is included in both the game engine source files (still closed source), and the renderer source files (Toady's could be given as an example, or not).

This may open up the game to easy memory modifications, e.g. mods, although cheats as well.

There's also inputs to the game to consider. The inputs to the game could be made more generic (and input could all be handled in the interface DLL along with the graphics), and then complete custom interfaces could be made. I think this is a Model, View, Controller sort of thing.

Better ideas are welcome, of course. Something like this would be great as a major development arc. For the short term, I really hope that each tile can be mapped to a different icon, as I believe has been done with creatures. What does Toady think?

[isitanos]

quote:Originally posted by Toady One:
<STRONG>It could also just pass across a pointer to the object list and let them do all the culling, but then I'd have to publish all my object definitions, which I'm somewhat leary of, and I'd also have to maintain and update and explain that information constantly, which is a lot more work for me.  Or I'd have to set up a second object list with less information that gets sent across?  In which case the performance of DF in general decreases as this new data structure is maintained.  Or perhaps there's something else.</STRONG>

I'd say, for now, just pass across a pointer to the object list and offload the Line-of-sight work to the client. Don't support third-party apps, just do your own client and maybe release the client source 'accidentally' every release. Someone may get the idea to use it as an example, but you didn't tell him to do that. Don't hesitate to completely break third-party clients on new releases: the game is in alpha, right?

Later, it may be better to make all LOS calculations server-side: as you said the client could call a function to request a list of objects in a certain area, and you'd do LOS calculations and return a list of pointers to all the objects that the player is supposed to see. You could do it either by making a second data structure and passing a pointer to that, or providing a list of pointers to the objects. Or else the client could call a set_area() function first, and then for every object it wants to acquire it would call a get_next_object() function,  which would return the next visible object available. So you would be essentially doing the LOS calculations server side, and let the client manage its own data structure - or display everything directly to the screen.

[Malenfant]

Mithaldu's 3D Visualizer is a brilliant example of the kind of things that could happen if the game state was viewable by a 3rd party app.
http://www.bay12games.com/cgi-local/ultimatebb.cgi?ubb=get_topic&f=2&t=001293

[sir monko]

this would be the most awesome feature for dwarf fortress ever. suddenly we would have true graphical clients (probably even 3d), nice interfaces with mouse and who-knows-what support,
at least simple multithreading (different client/server-app), less work for toady, more possibilities for the community. remember the isometric graphics set ( http://spriteattack.cator.de//df/show/ )? would'nt be a problem anymore - at least not toadys.

client/server architecture is not even hard to code. at least i think its way easier to write just the server than a intermingled app. toady defines what kind of data the client gets and let them worry about how to display it.

[catpaw]

Having a split between core and display communicating with each through RPC (remote procedure calls) or a custom named pipe would also be highly effictive for multiprocessor system. Since the OS could have the display application running on another CPU-core than the DF-coresystem. And since almost all modern CPUs today are going to be dual core at least, this would be a real speed gain. It would also allow people to write a 3d front end, which would not eat any of the cores CPU-time, since it would likely be runned from the OS on a different CPU-core. But even on the ASCII display it would be a benefection, the display alone likely eats CPU-time (hence all this partial draw stuff)

[dreiche2]

Ah, I was surprised to see that people discuss this here so calmly, but oh well, it's just a thread necro.

We had that discussion recently, and it was a huge huge mess. However, if you look just for Toady's posts in that thread, you can at least see why he his wary of this kind of approach.

[sir monko]

sorry for digging up that ancient corpse! i just searched for "client server architecture" and this was the only thread coming up, so i didn't know this was already settled. thx for the link, dreiche.

i'll shut up now.

[Granite26]

It's the lean set of outputs I was asking about.  Saying that someone would be able to make the game display in 3D would require a bit of work somewhere, depending on what you intend as the field of view.  Would the client ask for all the things in a given rectangle?  Where is the control on how much is sent (there can be hundreds of thousands of objects in the rectangle)?  I suppose the client could also send in an item cap or something like that.  Seems like it would be quite a bit of work on my part, and that I'd also essentially be in the position of supporting 3rd party app performance.  It could also just pass across a pointer to the object list and let them do all the culling, but then I'd have to publish all my object definitions, which I'm somewhat leary of, and I'd also have to maintain and update and explain that information constantly, which is a lot more work for me.  Or I'd have to set up a second object list with less information that gets sent across?  In which case the performance of DF in general decreases as this new data structure is maintained.  Or perhaps there's something else.<P>Regarding the DLL, I don't quite understand that either.  I know they were just examples, but when would the game engine ever use the dll to call something like drawDwarf?  I thought the engine wasn't in charge of that.  Does the game engine do more work with drawing game objects than reporting information about their type and location?  I thought the client would take the location/type information and do whatever drawing it wanted to do independent of the engine.  Or maybe drawDwarf was a name for the location/type report?  I guess it couldn't be drawDwarf, because dwarves don't exist outside the raws, so it would have to be something fairly general, and some of the issues raised above come up again.

I think taking a look at Blizzards WoW client interface might help, especially concerns about losing control of the project or being asked to support someone else's.  As long as you maintained the vanilla ascii interface, other people's would be no more your responsibility than the graphics sets or raws are now.

For DLLs (You can do something similar with Vanilla C), you don't expose the code, only a small set of functions.

At a broad overview, if I were going to write a 3rd party interface, I'd want :
    What's in this square?  (would only return what the player could see)
    Take a turn.  (Do everything you currently do on a turn)
    Get events ( Basically anything that you might want to pause on or display)
    Actions (Rather than the current menu system, you'd have a 'build' command with parameters)
        Build
        DwarfChanges (Create a public 'Dwarf' labour object that would turn stuff on and off)
        DesignateSquare (Force the UI to call once for every square.  This would allows stamps)
        Queue Workshop
    GetInfo
        GetLog
        GetStocks(Filter) *UI could then do all the work only displaying the right things
        etc.  (Note that this enables a separate window that does nothing but display your seeds!)
       
At the office, we do this (completely separate UI from business logic) whereever possible for the same reasons.  The smart guy can do the advanced work, while the new guys can make the simple interface changes without having to worry about them making million dollar errors.

Personally, I would think that it's good OOP practice to do something like this for your own sanity, even if you never let other people write the interfaces.

[Draco18s]

Things said by the Great Toad.

Stuff here.

You just quoted a post almost a year old in an attempt to re-start a year-dead argument.

[sir monko]

@granite26: like dreiche said, the whole topic was discussed on this thread in length:
http://www.bay12games.com/forum/index.php?topic=21806.0

i'm on page 10 now, and i can assure you, almost every possible pro/contra statement has been made. i'm a programmer myself, so i at least know a lot of very competent statements have been made by both the pro and contra factions (and, sadly, a good portion of trolling from non-programmers, who just didn't understand what all that was about, too). a client/server architecture has certain benefits, and certain disadvantages. while i think it would benefit the whole game a lot, others don't think so - and they did make some completely reasonable points.

so after page 10, every point i could have made was already made by way better programmers than i am. i know toady posted in this thread somewhere after page 10, so i assume he read all - and knows all - of it.

so if ANYONE really thinks he can add to this discussion, please read the whole discussion linked by dreiche before posting. i didn't know about it beforehand, because i didn't follow DF-dev closely and the forums search function didn't work as expected. now i feel guilty because i accidentially ressurrected an ancient zombie thread.

please, if you're interested about a client/server architecture, read the other thread, and do not reply to this one!

@Draco18s: the damage's done, i'm guilty and i'm sorry. my fault. won't do it again. please lock this thread.

[Geofferic]

This sounds to me like a sneaky way of asking for multi-threading!

IE, run the game on one core and the interface on another.

Of course, it also allows for the community developed interface...