Reserving second post.

Townforge: open source and free crypto-MMO with BSD license

THE GAME IS CURRENTLY IN A TESTNET AND TESTNET CURRENCY WILL NOT TRANSITION TO THE MAINNET.

Please note that due to recent developments in Freenode, we have transitioned to using #townforge in libera.chat instead



Name: Townforge
Currency: gold
Type: Game built on a unique blockchain, with its own accompanying cryptocurrency
Base: Monero fork (heavily modified)
Mineable: Yes
PoW algorithm: RandomX (can be merged mined with monero), and possibly later hybrid RandomX + proof of stake style mining
Emission: Infinite (same system as monero, with a tail emission)




Hey all,
 
tl;dr: Townforge is a persistent blockchain game of emergent economics and unleashed creativity, where you build a town on a voxel based 3D procedular landscape, competing with other players for income.
It's a "play a bit every day, building up your economic empire" style of game. For others, it can also be a creative outlet.
You can create buildings, research new technology, farm, collect gold coins for prestige income, create companies, loan money for interest to entrepreneurs, play the in-game markets, or just chat in game.



Townforge is a blockchain-based persistent crypto-MMO, Nordic settlers arrive to Greenland during the Medieval Warm Era and scheme to establish a player-driven society with complex economics and react to in-game events stemming from the lore.
All in-game actions are stored in the blockchain with a decentralized consensus driving the game logic, with the core of the blockchain coming from a heavily modified Monero fork.
In-game player account creation is done by depositing some gold from out-of-game wallet (with a 1 gold fee for anti spam purposes), and currency can then be freely deposited and withdrawn from inside the game.
Most game functionality happens with deposited gold.
 
 
Players can build impressive buildings using Minecraftian creative-mode like mechanics (though this 3D building facet of the game is optional).
All construction materials are obtained from the decentralized markets along with food, labour, and other necessary goods for creating and upkeeping the buildings.
The game offers an infinite last resort supply of building materials at a high price.
The intention is that players start producing said goods (such as stone via stonecutters and wood via sawmills) and compete to undercut this baseline as well as compete with each other.
 
Players can research new tech that gives them an edge, found new cities and become their mayor, specialize cities to attract certain types of settlers, buy land from towns, trade items and land, create custom items, hunt, sow and harvest crops, obtain levels via badges (="achievements"), raise roleplay attributes via leveling, upkeep buildings by supplying food and repairs, pay land taxes to city treasuries, et cetera.
 
The economic side of the game relies on two main ways to get income: producing items and treasury payouts.

Some key buildings earn a share of the treasury coffers. The larger the land and the higher the building's economic power (a measure of complexity of the building built on that land), the larger a share the building will earn.
Various bonuses apply, such as placing a building on land best suited for a given role or for close proximity to supporting building types.

A fixed percentage of the town treasury is allocated to buildings of a certain type, and then divided between all buildings of that type based on their relative size/economic power.

Other buildings do not receive treasury payouts, but produce materials or food instead. The player can then sell these products via the built-in peer to peer marketplace.

Town treasuries are automated consensus driven accounts which cannot be manually withdrawn from, and form the basis of the game's circular economy: player activity causes treasuries to grow, and this money is then redistributed to players based on how well their buildings do.
This redistribution gives an incentive to play the economical game well. However, we also intend to encourage aesthetical gameplay, such as building pretty and complex buildings that go above the limits of minimum required cubes per building. Terrain is generated procedurally and it is practically endless.
 
The block target is 1 minute. All player actions such as 3D building or resolving trade orders are embedded in special transactions and are mined in every block, and checked by every other game player for adherence to game rules.
Every 6 hours (360 blocks) a game "tick" occurs, during which heavier game update logic is resolved, such as: inactivation/activation of buildings, consumption of food, building decay, awarding new badges, etc.
 
The game has a GM-account which takes a 0.1% cut of the Townforge gold going into the towns' treasuries.
This money is intended to be used for creating roleplay events and award players as an incentive, as well as compensate the devs along the way for their efforts in developing and upkeeping the game.
The GMs do not have god-like powers, althought they have the following privileges: they may push new quests to the chain for players to participate in (work in progress), create new badges as rewards for interactive roleplay sessions, define new roleplay attributes, and as a form of moderating flag buildings and players to be ignored by the default client (for example, due to harrassment/phishing) - however, these ignore flags can be turned off manually in the client.

The game has been designed to be exit scam proof: gold deposited into a player's account can only be touched by that player (ie, withdrawals are automated and do not depend on approval for a central party) or by game consensus rules (ie, land tax at game ticks, or another player filling a market order).
 
The in-game currency - gold - can be obtained via mining or trading it from miners. There will be no ICO nor premine, but moneromooo will be mayor of the first town to bootstrap the game.
Other towns may be founded by other players. Certain in-game badges will be awarded on mainnet to people who contributed, helped out, or participated in testing on Townforge's testnet(s).
 
The game is open source and free, with its source available via Git. Further, we also offer pre-compiled binaries made by trusted members of the Townforge community.
Communication happens mainly via the main IRC channel (#townforge on libera.chat), in-game chat, as well as social media (townforge.net with a forum, along with Reddit, Twitter, Discord, as well as this BCT thread).

The testnet may reset from time to time, and is intended to fix bugs as well as to check various aspects of the game's balance with many players. Mainnet will start when we deem it ready.



---

Some interesting facts of Townforge in no particular order:
- decentralized chat (based on txpool transactions that never get mined)
- decentralized marketplace
- tiny in-game transactions (~100 bytes is typical)
- pseudonymous in game transactions are separate from out private of game transactions (and thus do not affect the currency side's anonymity pool)
- merge mining with Monero
- complex voxel based world building connected to the player levels and attributes
 
Welcome to Townforge, fellow settlers! enjoy your journey, live long and prosper.
 

---
 
Team:
Moneromooo (implementation, design) (Please note that the 'moneromooo' BitCoinTalk account is no longer in his control)
Syksy (design)
 
URLs:
Home: https://www.townforge.net
Git: https://git.townforge.net
Binaries: https://townforge.net/download
Forums: https://forum.townforge.net/
Blockchain explorer: https://explorer.townforge.net/
Extensive gameplay manual: https://www.townforge.net/manual/
FAQ: https://www.townforge.net/faq/
 
IRC:
##townforge @ freenode.net (accessible e.g. https://webchat.freenode.net)
#townforge @ libera.chat

Social media:
Reddit: https://www.reddit.com/r/Townforge/
Twitter: https://twitter.com/Townforge
Discord: https://discord.com/invite/ygxGkfA
 
---

It's a great idea in my opinion, and I actually started out testing and exploring MUD-like approaches. I used to play BatMUD and ZombieMUD back in 90s, so I am very familiar with the concept, and I know there are ready engines for MUDs.

However the interface with MUDs and a blockchain was something that became something of a roadblock in my preliminary research. MUDs are ideally real-time, while blockchain implementation has lag in respect to what the tokens may represent and what information is contained within blocks. Further, it's really tricky to couple a ready MUD engine coupled with forking a ready crypto protocol. I couldn't find a "perfect match", and doubt there is.

But I definitely have not forgotten about the MUD idea. I'd probably build my own MUD engine though, as they're relatively simple. However, there are a lot of practical design questions that challenge the traditional MUD concept. Then again, nothing ever works out-of-the-box in such novel combinations

Cheers,
Syksy

Hiya,


I think I'm the only one currently planning anything new to be implemented. I'm not sure where the others have gone, or if there's a big revelation any time soon. Perhaps, there was definitely a prototype under development by Loaf & the gang with a preliminary web interface up. If the development is still active, I've been dropped out of the loop though, so I wouldn't know.



As for me, I implemented a basic grid-based world in Java that was saved in a SQL database that could've worked as a back-end for a game inspired by CK. Why I say "inspired by CK" is that I'd like to make a game with some similarities, but it's definitely not going to be "CK v2" per se this project is publicly on GitHub, but I'm thinking of retiring it as a dead end.

Since I developed my prototype, I realized that it's basically a very basic tile-based engine for a block world that doesn't really add much worth on top of all the other engines out there. In fact, it was probably much worse than some back-ends that I could've adopted straight out-of-the-box.

Since then I've been revamping my ideas of development; instead of going for such back-end for the game (based on e.g. SQL database or local copy of game state), I've been playing around with the ideas of developing a blockchain that could support such a game. Naturally a blockchain-emergent implementation comes with the pros and cons of a blockchain's inherent properties. The game would be fully functional based on a blockchain, which would make it unique. Storing data / (data) transactions on blockchain of course imposes severe limitations on what game functionality could be implemented, so I'm approaching it in small steps. I've been sketching out a "white paper" of my ideas, though I don't want to put a date on it. It's on Overleaf as a LaTeX document if anybody's curious, but it's really crude though.

Doing something similar to CK is a massive undertaking, and I'm doing it in my spare time on top of my post-doc / family life. I'd greatly appreciate if there would be volunteering enthusiastic individuals out there willing to contribute to such an open source crypto-related initiative, as this would increase the chances of success drastically. So feel free to poke me over a private message and/or IRC (Syksy @ freenode), and I can also give you my personal email.

Naturally I'd love to see others activate, even if they don't want to contribute to my particular approach on this. I'm already grateful to certain individuals, who have been kind enough to share their insight into such a project. I can't make promises as this project cannot take main priority in my life, but it's definitely something that I think is very interesting and worth pursuing in my spare time.



Nice to see old familiar faces around feel free to chat me up on IRC, though I might respond with a delay. I also have a Discord channel up for my various projects. I am anyway pursuing my hobbies as a game dev (just implemented an "Oregon Trail in Space" in Global Game Jam '19 a week ago, was refreshing to get to implement a whole albeit small game).

Indeed 2018's been a harsh year overall, and CK and its derivatives have also been more or less under hibernation. I think it's quite natural given the circumstances. But here's hoping for a solid 2019, happy holidays to all!

Cheers. I haven't given up on my engine despite my GitHub commit's having been focused on my research work focused projects and other hobby projects. There's a game jam on Jan 25-27, which I might be able to use as a playground for having this as the back-end, will see

Unfortunately no news from the Slack at least that I'd be aware of, there was a preliminary test version though.
My GitHub project is up and openly avaible though only slowly progressing, so I'll holler out if/when something notable happens on my end.

That is pretty surreal :/

It was quite widely covered in Finnish news; naturally, caught quite a lot of attention among people within these circles as expected.
At least the news said they suspect that the fire started from electricity equipment owned by some renovation team at site.
Of course nobody knows for sure yet - I don't think anybody's ruled out any more sinister alternatives either.

Thanks for the cheer-up, I was already getting the feeling of a bit apathy since nobody responded anything here or in Slack cheers.
Committed today some new stuff, but it's baby steps. I'll report when there's something truly interesting in comparison to the previous showcase(s).

Alrighty, so I promised a bit of a demo on what I've been working on.


So it's abstraction of a rectangle grid-driven world, basically a game engine, called Cipher. It is publicly available for any and all in Github, and I'd naturally love it if anybody would like to pitch in - though I suspect it'll be a solo project for the time being. It is a back-end, although I did for example implement a simple graphics render engine so I could showcase what's happening under the hood. The engine is built in Java, and I was planning to work on a front-end, but it's been on hold for the time being while the engine itself is tested on command line.

Below is an example run of creating a simple "world" with one building and a sort of a fence around it. The cubes (="tiles") or the walls (="edges") do not yet have characteristics per se, although their respective characteristics tables already exist in the database. I'm hoping to maintain a level of abstraction, so that the engine itself could be extended to suit many varying types of needs; let's say anything from a Crypto Kingdom like macro economy city sim to a 4X space game where e.g. solar systes are tiles or something.

Here's a run on the console as well as PNG output of what the example world looked like:


And the output of the command 'render map' is our tiny little "building" surrounded by a "fence", where I deleted an entry point:




Needless to say there's a ton of work to be done. I wanted to do things from scratch, so perhaps you will see more fancy stuff coming from the people who've been front-end orientated while I meddle with this little thing and adventure in the back-end side

Hmm, I definitely cannot be a one-man show   developing any kind of MMO is one of the most if not the most ambitious game development venues to pursue, with a notorious fame for being the classic "trying to bite more than one can chew"... My opinion is that as a group effort it can be done, especially if/when focusing it on a specialized aspect such as in-depth economics (and omit fancy graphics / hack'n'slash / whatever). Still, it's a great challenge.

I've been committing to https://github.com/Syksy/cipher as an open-source game engine prototype project. It's far from even "pre-alpha" type of stage, but I have a basic structure of the map complete and rendering of an isometric view to the world, albeit highly simplistic in terms of what is being represented. There are others working on more front-end orientated stuff, while I've been putting most of my thoughts into back-end stuff (such as this engine in Java that I've so far dubbed Cipher). Hopefully we can effectively merge these efforts in near future. I'll try come up with a proper showcase for the engine - I know I already promised this couple weeks ago, but there's only so little time and so much to do...

I think one of the main lessons of CK could be, that in general paying in advance is a very risky practice in software development. Some other reward system (e.g. milestone related game-bound monetary unit) that gives a more dynamic, over-time incentive, would be in my opinion a much more natural motivator for anybody to drive onward in a long-term project such as this. I'm not saying Speed ran off with 300$ (this hardly sounds like a sum worth scamming anybody over, and it could've legitly been lost in exploring options or practical arrangements), but giving anybody crypto or fiat for anything in advance especially in this context (unless you really know them) sounds like a very risky practice. That's also why I'm very hesitant to be on the receiving end in agreeing to any advance payments, wages, promised commitment or whatever, for developing any particular flavor of CK or a more generalized engine. This is mostly because I'm not entirely convinced whether I'd have the capability in terms of full-stack development skill or the required time, mental stamina and focus to drive forth a project as ambitious as this. I'm an inherent pessimist though, so don't let me put anybody down

Heya,


yup, I've been working on a little something-something on my limited spare time pro bono. I haven't yet hit a proper milestone where I would've felt comfortable showcasing it to others (as this tends to escalate exceptations), but I guess I could try summarize soon a bit on what I've been working on and what I've had in mind. It's basically full stack development, as I've simultaneously been working on a web-based client as well, but I'm by no means a full stack developer (or a web front/back-end dev in the first place), so it's been a bit bumpy road. But my overall idea is to get an open-source, community-driven thing going on, that could be then fueled by a larger group of enthusiasts after the initial fundamentals have been established.

I'll try to get back to this soon,

Cheers,
Syksy

Hello all,

indeed the budget of a ~0.5mil € sounds more realistic for a proper MMO game as ambitious as this (even then it's from the smaller tail end and could definitely use the leverage of an active community) - but I'd still also recommend considering the alternative of having heavily emphasized open-source, community-driven implementation. This approach would fit the crypto-scene like a glove. Sadly, I think many of the most productive programmers that played with CK have lost interest and moved on, but it also appears that new enthusiasm exists out there, waiting to be found.

I'm working in the background as a sidekick hobby thinking of possible mechanics, which I intend to offer for the use of CK or any other entity. So it's not a monetary investment, just an adventure of curiosity. Right now I've been testing out a genetic algorithm driven NPC-behavior based on discrete decisions. We'll see if it'll produce anything feasible in the end... I'll probably offer it in an open GitHub in any case when I got something to showcase, and it'll be in R (though I'm trying to design ideas for the implementation so that they'd be easily generalizable to other languages too - R just happens to be my go-to language).

I'll gladly leave any potential monetarization or tokenization discussions to those more experienced and wiser than me. My only concern is the conflict of interest between game dev and investment, but I guess that's obvious.

Hey all!

Sorry for taking my time, but I'll return with an elaboration to showcase what sort of a larger picture I have in mind. Thanks for the feedback, positive vibes and continued interest! I'll reply to each of you individually here as soon as real life stops grabbing me by the balls.
Just quickly addressing:


Do you mean the SWOT-analysis I did of CK in its state this January?
I could paste it as colored plaintext here, and update the pointers now some months after. Basically I raised multiple key issues that were important according to my subjective judgement and tried to dissect their priority when it should be done, how laborous it is to conduct, and finally broke the issues down using SWOT. Maybe it's even better presented here-in as then people can quote/reference particular segments of it embedded into the discussion itself.

Yup, this "Minecraftian" approach is quite efficient, especially given that it would be nice to have a 3d-world. In the old implementation, the lots were basicly polygons, and those can be quite difficult to build on design-wise. Also, there was effectively no z-axis, other than that each lot with a building in it had a separate value for how tall a building was, which as a design pattern is challenging as one is effectively detaching the 3rd coordinate axis to a fundamentally different system.

If there are experienced people around here that could comment on the potential bottlenecks in the proposed an approach, it would be very nice to hear at this point in case we pursue this further. Basicly the above data structures could hold pretty much the simplest game world, while allowing flexible expansion of it. I am just worried of if it'll become too intensive if multiple concurrent users don't scale well in its use.

One interesting tidbit of history is also that in early CK people used to create their buildings in Minecraft. They'd quite often post their videos showcasing the castle etc that they had built, and that served as the starting point before transforming these buildings into polygon-allocated building lots with certain characteristics in the game itself.

The good thing also with such a block design, is that we can effectively let people design arbitrary building schema in a separate building editor (I remember PJ already had some simple 3d-cube "builder" showcased in an early version of the Ultima), and then people can use that schematic to build new static world object (or even several). Those will then be appended to the existing list of world object, after player hovers over potential land (owned presumably by him) to select building that will then occupy the positions

Free resources such as skins/sprites/etc are of course a bonus, but they will be easy to add when the bones of such an implementation exist. I'm an oldfart in the sense that I'd love to take some inspiration from the freedomness in MUDs of the 90s, ASCII-games of near past (e.g. Dwarf Fortress), or otherwise simplified graphics (many free/indie RPGs using just pretty average top-down 2d sprites in showing the world), but in the long run I'd think either a free camera movement or some sort of a isometric view to the world would be a good compromise with utility and eye candy (a bit similar to e.g. how we discussed Transport Tycoon and/or Rollercoaster Tycoon.



Yeah, the diagonal movement can be a bit tricky in this case. For example, I showcased here the factor of movement between tiles, as this could generate the interesting economical aspect of logistics in an emergent manner. But with diagonal movement, one has to factor in such situations as:


Here is a 2x2 map with the lines portraiting edges, for example fences in this case. Player (@-sign) wants to move south-east, but technically according to the edges surrounding him, he'd be leaping through the fence at the junction where the fence takes a orthogonal turn. Should the player be able to move south-east? We can always add the multiplayer 1.414 (or its inverse if we decide higher value indicates higher speed) to moving from current position to the default land south-east. Some sort of additional logic needs to be implemented for the diagonal movement, e.g. defining that the diagonal movement always factors in the 2 edges of the current tile pointing toward the target tile.

But for now I don't think the diagonal movements are a major head-ache, and mostly it concerns how the edge-logic should work in such a case.




A side note:
It would be also interesting to know what sort of distribution of interested people we have (I consider the currently even semi-active following to be representative of the target audience) and to what extent they consider features important. For example a strawpoll of the level of graphics, depth of emergence (or hard-coded formulae), interface (API-driven with anybody capable of building their own client), etc.

Hello,

To put something on the table about thoughts regarding the game design;
I believe the hex-based idea has been discarded, so I've been thinking of the implementation of a square grid in the game, as I believe this was the latest consensus. I played around long time ago with backend Java + PostgreSQL, so this overall suggestion is inspired somewhat by it.

So I though we could utilize relational databases or similar data tables, though I am of not completely sure of the MMO- or web-scalability, but here goes.

Basically the world could be implemented using a 3dim array:
where first dim is x-axis, second is y and third is z.

However, I suspect much of the world be empty/default tiles in the beginning using the 3 axes, especially with z-margins containing very empty slices, so I would therefore think a scarce matrix representation would be suitable. The world would be saved in a data table with unique key *s of three elements and possibility for extensions (new columns as needed). If a unique key combo is not found from such a table, that tile behaves like a default tile (which we can arbitrarily decide what it is): The idea of a scarce matrix is to provide an efficient representation of the world map, when there's potentially a large amount of "empty"/"default" tiles in the 2-dim/3-dim array, and if the certain {x,y,z} location is not saved in the look-up table, any queries asking for the content for that particular tile return the default tile/instance (for example, a simple grass tile or such). * is used here to indicate the unique keys that need to be provided in order to access a certain row in the data table, yielding access to the rest of the fields, and duplicates of the key combinations are not allowed in the table itself.

Here's a small example world that can be represented to be of size {xmax,ymax,zmax} here as 6 * 5 * 2; notice that all key fields for accessing the table are unique combinations:

(lower you'll notice that 138 represents a particular pre-designed house and 1 is an ID for a generic cobblestone road)


So whole world map would be saved in a single table, where content could be sliced/queried accordingly. TileID refers to a key in WorldContent, where further columns could be presented in the future, but for starters:

where the types could be replaced with string constants e.g. 0 = ENVIRONMENT, 1 = ROAD, 2 = BUILDING, etc. Only "static" world objects would be saved this way. For example content designed as BUILDING ought to always be surrounded by edges that cannot be walked through, and are required to have at least one ENTRANCE-type of edge surrounding it in any level (e.g. a house without a door is presumably useless).

The naive world would thus represent the following ASCII world, if we wanted to present it using such (it's just a tile representation for which an ASCII representation is usually one of the easiest ways to start):

slice z=1 (ground level slice, where x ranges from 1 to 6 and y rages from 1 to 5
slice z=0 (e.g. basement level, same projection to the game world otherwise but one z-unit "deeper")

Further, edges between grid squares can be uniquely defined to model movement, walls, windows, obstacles, etc. For example, a fence in edge between {x=4, y=1, z=1} and {x=5, y=1, z=1} would prohibit movement from grid point {4,1,1} to the right. While the normal unit size would correspond e.g. to 1m x 1m x 1m cube, the scale could be made smaller to model the world in more detail. For example a carriage could be 2 units wide, 4 long and 4 high. . These need their own modeling schema as they could move while above scarce matrix representation was a thought for static world objects that cannot move.

Other use for edges could be determining a movement coefficient. A fence would basicly be 0, moving from grass to cobblestone 0.5 and from cobble to cobble 2 or something, with higher being more favorable in general and 0 preventing movement altogether. An another use could be lockable doors etc. It would be probably good to define a suitable class for 3-dimensional coordinates, but here I am still referring to the conventional {x,y,z} coordinates.

Table for edges could be something in lines of:

   

The separation to tiles and edges does not have to explicit over all the grid. For example, if an edge allowing entrance from a default to a house-tile does not exist, it could default to a 'move=0' tile (i.e. player trying to walk through a wall from grass into a building tile. This can be saved using a table of simplified logic which is overriden by EdgeContent-table. For example, with the FromID and ToID identifiers intenchangeable without losing the general logic:

      

Again a table with unique keys to EdgeObjects can be done similarly as for the tiles presented before.
While the amount of edges grows extremely fast, with the scarce matrix representation most would default to e.g. an implicit default movement "def, move = 1" and this would not have to be saved an enermous amount of times. Some of these specific IDs could be transformed into more generic types, e.g. moving from a tile type 'FILLER' or 'ROAD' to 'BUILDING' without using an explicitly defined door in table EdgeContent.



This is food for though; I am not so sure of this approach's scalability. Buffering the sides for panning or unit movement would help in avoiding clunky but continuous character/camera-movement. If built using a modular design, resizing into a smaller grid/3d-cubes can be arranged, but making them larger may create trouble as detailed functionality is tough to remove or simplify.

This is a rather database-driven approach, but I was just thinking conventional arrays would quickly become unfeasible for use and scarce matrices could very well suit this. I am here thinking that essentially the world would be deep-down modeled similar to e.g. Minecraft-tiling in 3d. I am however not a full stack dev (or a web programmer to begin with) so this implementation could have some obvious flaws I am not capable of identifying.


Other concise thoughts:

• I'd suggest that the front end could be HTML5 + JS (node, express, socket.io) after looking into various options, feel free to disagree and discuss. This would allow mobile gaming (in any device that can run a decent browser)
• Diagonal movement is a bit tricky with above (consensus of the 2 edges ponting to that diagonal tile?)
• Graphic representation at 1st stage could be rectangles and/or ASCII.
• Game-design cannot rest only on my shoulders, due to various uncertainty factors in life, if this project wishes to be as ambitious and as fast-paced as it is portraited.

Fun with potential factions...
Been experimenting with potential layouts of factions and their aims and/or motives and how they fit in the lore.
Here's a few world war -type posters that I made for kicks.
Notice that they're quite large, so unless you get 3 "posters" below the chances are imgur died while loading them.



Crown-Thorn Conglomerate:




The Free People:




Society of Conciousness

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

Hello all,

without having a particular strong opinion for or against any of the financial statements above, I'd like to pitch-in from a programming-/gamedev-level perspective on what route the game could go on - especially if it's made into a separate entity. This was just a basic oversight of concepts that I think ought to function as central nodes. Apologies that it's been ages since I did proper UML-charts or such, but I think those with programming experience can see the underlying overview (while it still is quite simple to grasp due to only modeling few of the key concepts):



A little bit about the classes:

The world map would be best suited according to my own opinion as a hexagonal grid on multiple levels; world-map level (most commonly used game style), local/city-level (kind of what you'd see in a jRPG or in old-school turn-based hex games like Panzer General or such), and then zoomed in -level (most vanity-level, mostly decorations, furniture, characters/pseudocharacters modeled).

The main division on character level would be to PCs (Player Characters) and NPCs (AI-driven player characters). Basically these combined create the base for supply and demand, while NPCs are much more abundant than PCs naturally. Still they'd belong to a family (="Guild") as well as a Faction of a sort (higher level than family, e.g. a nation; some time in future idealistically strong enough PCs and/or alliance of PC Families could create their own faction (=nation) and create their own set of rules such as who gets to pass, what road / sales tax they determine, etc etc.

The specific implementation of NPCs is a challenging one. I'd like to base them on a semi-individual level simulations, though what I was experimenting with cell automatons I don't think there could be easy way to incorporate those. As such, I'm leaning toward e.g. a random-walker based simulation per week (or distributed among a week = one year), to determine hotspots for markets, how long distances NPCs need to travel to aquire/buy food, whether they are close to a potential work place (such as a brewery, factory, farm, whatever...). Furthermore, instead of past implementations, NPCs would also require housing, thus rent/sold houses nearby hotspots of a certain kind also attract NPC renters/even potential buyers.

Events are quite vaguely defined, but they'd be the main form of actions taking place in the whole game world.

I know this is a very broad oversight and potentially unusable as it is, but I thought it'd be time for somebody to put something concrete in regards to how the gameplay emerges from the underlying mechanics. Feel free to give comments on what you think of it.

Dear Karl Hungus, Duke of OZ,

Sadly I am no longer in Crypto Kingdom, otherwise I might've worked on your effort for the Gringotts (with a quick glance it sounded interesting). However, I only now pop by to BCT randomly more seldom than perhaps once a week to see if there's anything in the posts that concerns me.
That being said, my genuine respects to you, and best wishes and blessings to your health. I hope the situation will stabilize. If it will not, I wish that you will be surrounded by your loved ones. We will all once take that journey on that strange and unknown path, but I hope each of us can depart surrounded by those close to us, with no regrets.




Kind wishes,
ex-Prince of Petrichor, Lingering Ghost of CK, Syksy Syyskuu

I would be interested in getting the withdrawal of 13.4 BTC to address 3E6zpE5aT4s6J8NPvdBhHVwAV4PsksWMoV
( https://docs.google.com/spreadsheets/d/1zR5PszQOQyqnmX7b1CR4XtskcGWAtsHeGbZAWOYgi_o/edit#gid=582306627 third from up after header; omitting the "With Interest BTC" and including here only "Non-Interest BTC")
This 13.4 BTC would be really essential for me and the family especially in this phase of my life.

I am 3rd in time-wise line (where 1st in line never posted his address), so at least if we go in time-from-withdrawal order I believe I would be in line for tomorrow. As you know, sadly as I am no longer present in any of the Crypto Kingdom game forks (this or the main thread), I cannot accept any in-game assets :/