It looks like a reasonable topology, yet the logical attribution of the order matching isn't mentioned, neither is the api. So possibly ht sees no benefit in third party additions? Or possibly just focusing on the system as a standalone game for the sake of presenting the topology?
I mean have we considered the reality that some NPCs could just be made as player accounts and bot whatever needs to be done through a third party? I mean with everything changing this can all be different and nocs could be a part of the server of course. I guess we were kinda doing that before with the npccs, having their own player accounts and such.
Also lore really intrigues me also, so we got a lot of stuff to draw off of. Do we have any kind of distance or logic set up with regards to a player interacting with a square/hexagonal world grid?
Also I'm confused what he means by 'pseudolanguage for in game modifications ' does he mean he'd like the gm side of the game to be more automated? Like just type in a command like ' create win 500 yellow ..' and have 500 yellow wins appear in an inventory or is something else being discussed here?
Thanks for the comments! It was a very broad overview, so many aspects of it are still vague. It was just one proposal to get the wheels turning.
Specific responses:
"It looks like a reasonable topology, yet the logical attribution of the order matching isn't mentioned, neither is the api. So possibly ht sees no benefit in third party additions? Or possibly just focusing on the system as a standalone game for the sake of presenting the topology?"1)
Aye, apologies for vagueness on some parts. It's a kind of an "opener", so I just wanted to lay down maybe some of the most important differences. I do acknowledge the background aspects that are important, even if I don't enumerate them here yet explicitly - but I acknowledge e.g. the importance of a well functioning item-trade and API; on this oversight they just weren't yet included. In my proposed approach, items and characters would be time and location bound. Therefore order matching (I suppose you mean here how to do actual trades) has to happen locally (or by acknowledging that certain goods are located in an another position) and is more complicated as we wouldn't have the always-accessible universal type of Agora market. I think this has potential to make certain emergent phenoma such as trade hubs, "trader-career", "logistics-career/services", "highway-robbery", etc.
2)
API is obviously an important aspect; I'd say we ought to implement a similar level API e.g. which was usable by Saddam's IRC-bot in the past. The coordinate/time-bound aspects do bring new challenges, but definitely a strong API-support is important.
3)
As you can notice this whole new system only briefly even addresses e.g. Item-class and Event-class (which prob would include subclasses Trade, Give, etc events), so if the overall topology looks feasible I could delve deeper into the details.
"I mean have we considered the reality that some NPCs could just be made as player accounts and bot whatever needs to be done through a third party? I mean with everything changing this can all be different and nocs could be a part of the server of course. I guess we were kinda doing that before with the npccs, having their own player accounts and such.1)
In my vision, there would ideally be no distinguishing between PC and NPC. Only in practice there would be; nobody wants to play the NPC that goes to work and returns home with a cabbage to feed his family, nor was there real incentive to do so. We could see an extreme tilt in the active player base in the old game, where basically anybody who was even remotely active were (high-end) nobles, and even the middle-class was lacking, even if in theory the levels tried to portrait all hierarchies of such a society. The only time lower level chars made an appearance was when people were abusing the free CAN gift to spam accounts and then sell the CAN...
2)
In this new proposition, at least according to the PC/NPC hierarchy you can see that they both inherit from the main upper classes, belonging to a family etc. While NPC families (or houses or whatever you want to call them) would be only minor, at least in theory somebody who wants to set up and run a company of say masons could do so. By leaving a bit of lenience between the borderline of PC and NPC, we could end up in a world that's entirely habitated by PCs (majority of whom are the "peasants"). Main thing is I'd suggest inhabitating a large quantity of NPCs into the world with a certain logic AI (be it stochastic or deterministic) that would allow us to have a living, breathing world to begin with. Say, these NPCs would naturally look for a place to rent/own, a work that would suit their attributes, stay healthy (i.e. buy a variety of edible goods).
3)
I think the biggest difference here in comparison to the old world is that instead of running the whole supply/demand market based on "expert-curated formulae", where the NPCs were either embedded into the yearly fees (e.g. farm-items) or to NPC-items (like the soldiers/butlers whatnot with fixed fees per year), the system would be emergent based on the largely NPC-inhabitated world (at least first). If the game catches wind under its wings I don't see a reason why the whole world wouldn't eventually be habitated by PCs mainly (I'm a bit sceptic of this though).
P.S. I'm a big fan of emergent phenomena
"Also lore really intrigues me also, so we got a lot of stuff to draw off of. Do we have any kind of distance or logic set up with regards to a player interacting with a square/hexagonal world grid?"1)
The lore is going to be quite a large divider of people, some of whom wanted to model specific non-fictional history (which was CK's early history), but it deviated more and more going as far as Dragons, Unicorns and whatnot, though the game did model a country somewhat similar to renaissance-era Baltic country/countries.
2)
I like writing fiction, and would most definitely be up for writing the background premise. Most likely it would be steampunk'ish fic with a twist of dieselpunk, depending how we'd want to model future development of potential technology. This might be off-putting to some people who'd like to stick to strict historical premises, but I think the game's gone far past that already years ago. My preliminary idea was some sort-of a post-apocalyptical rebuilding of society in an alternate universe (i.e. not bound to real world map or how historical progression truly happened in neighboring counties). I think this would be highly beneficial also for emergence-driven gameplay, as we'd have pretty much no historical bounds to work within, except the ones we want to incorporate.
3)
Yup, I've worked quite a bit of with hexagonals. I think the main questions are:
Continuous or discrete world space? Both square and hexagonal grid are discrete choices, which obviously affect the gameplay a lot. I see more benefits in a discretized world rather than a continuous {x,y} coordinates (or possibly even {x,y,z}), but this can be of course debated. This was just a starter.
If we go with a discretized world:
3a) Square grid's main advantage is that it's easier to implement and often more intuitive, and to a degree easier to draw using conventional graphics (many pre-existing assets, and we don't have a paid artist so that's a bottleneck if we want to make a visually appealing game)...
3b) Hexagonal grid has the main advantage that it's more realistic geometrically, thinking about i.e. the Manhattan-type distance from location A to location B. For example in square grid moving diagonally is basicly sqrt(2) worth of {x,y} movement, while vertical or horizontal movement is worth only 1. I might be a bit biased towards hexagonal grid because many of games I've liked have functioned using such an implementation. Hexagonal grid can be modeled using mainly two different coordinate systems, for which an excellent article can be found here (covers also path-finding algorithms and other essentials for a functional game):
https://www.redblobgames.com/grids/hexagons/3b) In terms of player-interaction with the world, I think I might've abused the notation with the WorldTile, LocalTile and ZoomTile, but the basic idea depth of vision is described like:
- Grid doesn't necessarily have to have a unit distance between each grid element; say, moving from a tile with a cobblestone road to an adjacent cobblestone road tile ought to take less time units than moving from heavily forrested area to rocky and snowy terrain.
- WorldTile compromise of say woods, town district blocks, major roads, mountains, lakes/rivers, etc. Basically the typical world map you see in many hex-based games.
- LocalTile goes deeper into say a town district. It'll show minor/major roads, shops, factories, homes, etc and this would most likely be the level where most of the NPC simulations would occur. For PCs, they might still want to go a bit deeper but for major actions such as navigating from a major building (say, the home of the Family/Guild) to an another (say the Auction Hall) would happen on this level. I'm also thinking if/when there would be battle-conflicts, they would occur on LocalTile-level.
- ZoomTile would be a bit of vanity-level detail or inspecting micro-level details e.g. for NPC behavior or fine-tuning your houses/guards/etc.
Basically what I was initially thinking of, is that for example characters would consist of a 3-tier "location":
{x_world, y_world}>{x_local, y_local}>{x_zoom, y_zoom}.
For different actions, one might have to use the world-level (say pre-plan on which way to expand to), for others (say trade for example) local-coordinates could suffice. For more detailed actions, like emotes or discussing on game map, this could occur on zoom level, or if you want to make sure your character is at a certain position for example in regards to an upcoming potential battle or something.
I know this level is still very vague, but I could try find the time to draw example tiles on each level and see how they'd look like visualized. I think I was one of the few who contributed original graphical assets to the game in the past, but if there's an artist among us willing to contribute then of course that'd be very welcome.
"Also I'm confused what he means by 'pseudolanguage for in game modifications ' does he mean he'd like the gm side of the game to be more automated? Like just type in a command like ' create win 500 yellow ..' and have 500 yellow wins appear in an inventory or is something else being discussed here?"Sorry I was way too vague on this. Yep, you're pretty much right: basically I'm thinking of a scripting language that would allow for GM's to make changes to the real-time world. Say, spawn item, monster, alter terrain/building, etc.
Some of this functionality was readily available in past versions like CREATE command with a list of pre-determined parameters to create a new item with certain name, id, description, item_type, quantity, ckg_contained, etc fields. When there were bigger flaws, basicly the way for anybody trying to game master was to go through GM -> || Barrier ||-> HM -> || Heavy filter ||-> PJ. Maybe it's because of my experiences as a GM in the past implementation that I wanted to bring this issue up already now; maybe it's not one of the first things to implement, but it would lessen the burden on people working on code level to share it to the people creating content, refuting blatant abusers/cheaters and making sure the world's on its tracks (=GMs) who'd need it to be able to function in the first place.
I am by no means a zealot in regards to any of the particular choices in my suggested overview, so feel free to propose other alternative routes. I don't think I'll be the one in charge of making the ultimate decisions anyway, as I'm more of a game dev hobbyist trying to contribute in my own fashion (albeit I've always only worked on single player games). Although given the game's history, the "game dev" stamp will usually end up on people who seemingly volunteer to such by thinking about/contributing to such things
Cheers,
Syksy
For example, probably the most developed module was the "health game," and all that was was a single admin page where the values were changed manually on a per item basis. Even for something like that, some degree of automation should be possible.