Topic: CryptoKingdom Uncensored - page 8. (Read 69695 times)

Yellow May motherf-ckers!

http://listenonrepeat.com/?v=QhhT0tBPM-I#Aikakone_-_Keltainen

Where is the Man?
Where is the Master?
Where is Risto?

Who are the STO-dudes, can you explain what you mean bro, or are you another bot?

On the contrary now is the time to take action with any incarnation of CK that exists at all, which is the version Loaf has devs working on at the moment, waiting for risto to return, or someone to revive the current version with PJ as dev looks like a hopeless cause.

I hope STO-dudes would take a break from all incarnations of CK (try to sell your assets to see the extent of damage

If the supply is the same as in Crypto Kingdom (4 trillion) how does Town get 10%?
Doesn't town get the same assets it has already ingame?

As amusing as it is to see you raging in such apoplectic puerility, I will not succumb to the temptation of sending barbs in hopes of eliciting further embarrassment. You know where to find me if you find yourself again in a state where you can have a cogent conversation.

I prefer to participate in bounty rather than invest in ICOs. Yes, both are risky, but the only difference between the bounty is that your investment is just your time and effort.

As amusing as it is to see you raging in such apoplectic puerility, I will not succumb to the temptation of sending barbs in hopes of eliciting further embarrassment. You know where to find me if you find yourself again in a state where you can have a cogent conversation.

Pretty sure this person is just posting random stuff to up their forum activity. So not sure if this was a legitimate question

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.

Minecraft based design is perfect, all millenials instantly can navigate that landscape, and devs can easily design third party clients and custom setups for things like battles. Even if Syksy can't do all the work himself due to time commitments it would be fantastic if he can act as project manager and oversee other devs.

Any chance of getting the initiative copied here or on some Google doc? I can´t open your Google Drive link without logging into a Google account.. I have no account and do not want one either

A nice thing about the cubic 1 meter blocks is that about 2 stacked up could constitute a basic "floor" (2 meter = 6.4 feet). So say I am looking at the ground floor and I am in a 3 meter (9.6 feett) room. +1 on the z access would still show the same ground floor, and it wouldn't be until I am on +3 on the z access that I see the 1st/next floor.


A|.
-B-
...

In this, it appears that A is blocked in via fencing, so cannot make it to B. If fencing makes up the lines going to a diagonal vertex, it should be blocked (though maybe they could "jump" the fence for an additional action cost).

Look at this one:

A|.
.B-
...

In this case, even though there is fencing on the lines up to the vertex, it is not completely blocked, so the user can go diagonally (perhaps with the implied idea that they do not run into the fence at the vertex as they aren't going in a perfect diagonal).


I think a base 1 meter cube for the game can get us there. The issue in old CK was no base unit for design. While, yes, the game may look minecraft-y, this is easier to code and even possibly start with an ASCII design if needed.

Awesome, so good to see your ideas Syksy!!

It would be great to see other people with aptitude and interest in Game design chipping in with ideas, unfortunately, it's an area I know very little about, but my general feeling is there are two parts to CK:
- economic game
- interface

The economic game could still be played on spreadsheets if need be, and that is where the real attraction for me is (i.e monopoly with crypto money). My feeling is if the economic game is really well designed and 'immersive', then the interface can be super simple, but to attract new players having a great interface with graphical elements is a real advantage. We should strive to have the best of both, great economic game with great interface.

My personal preference would be to concentrate on the economic game first (i think that was what Speed said he was doing last year with his proposal), but that requires people with skills in economics & history, like risto had.

I think risto made a very good attempt at creating an economic 'machine' that replicated the real world (real estate, equity, debt, banks, dividends, loans, consumption, factors of production, labour, agriculture, manufacturing etc etc), and for me that's where the real appeal of CK is, in the 'economic game', but we need to simplify some things a bit, and rewind some complexity that can unfold as CK mark 2 evolves from the new starting point.

The interface design is very important, but a great economic game can survive without it, but it would be great to have both!




Graphics can evolve over time, definitely would love to see a cutting-edge graphical design eventually, but if it takes a while to achieve no worries, we can survive with something simple at the start. The economic game doesn't need graphics, but role-playing aspects are much better with a good graphical interface.

I prefer hard-coded formulae as much as possible for the basic economic engine, but try and strip the rules down to a just a small number, like Chess and many classic card games. IMO the best games are ones where you can explain the rules and setup to a 10 yr old child in a few minutes, but the best strategy for playing 'well' takes a lifetime to master, like Chess.

Similarly, if the economic engine is simple it would be great to have multiple clients, so API-driven sounds great! I personally would play a non-graphical version like the current version, but I'm old fashioned that way!

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.

This sounds like a great setup, and similar to what we were discussing in the Slack. Additionally, Minecraft is built on a 1m cube system, so using that in CK could mean that more art assets/skins/etc are potentially available.

While a lot of games just make diagonal versus orthogonal tiles all the same distance from each other, if distance matters, we could have something like movement costs have a 1.414 multipler for going diagonal, as you cover more distance diagonally, assuming movement from the center of each tile.

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.

the airdrop will bring the community together again,

The game needs to be simpler but overall Risto had a good structure.

Can we restart health challenge and payouts for NPC and buildings? That will get people playing and thinking about games design again.

+1
We need people with game design skills & experience, airdropping on those communities and offering bounties for contributions is a great idea.

Truth is if you pay peanuts you get monkeys, if you pay nothing ... you probably get nothing useful in return. Time to use the game funds to offer bounties and prizes.

HIGH!

Love to see that the CK thread still has some activity/discussion, but what would really be helpful is talk regarding game design.

Yes, we plan on doing a community airdrop, but would really like to have some of the basic gameplay online for CK before that.

As there is the plan long-term to "blockchain everything" for CK by the game operating with its own token, we would really like a solid concept before moving things forward and then having to re-tweak everything.

Honestly, if anyone is involved pretty deeply in the digital or physical board game scene, so for example, a long-contributing member on boardgamegeek.com or the board game reddits, get in touch on Slack as it makes sense to reach out to those communities and we also may airdrop some CK coins to those users as well. And it will be a LOT easier to airdrop in the board game space and be sure each send is going to unique users as there are far fewer "bot" accounts in those communities

Again, new CK slack link:

https://tinyurl.com/ckslack for Slack signup

This will let you sign up automatically Feel free to join and just chat