=== ANCHOR POEM ===
══════════════════════════════════════════════════════════════════════════════─────
screenshot of the alt-text input field which has more characters available
because the visual processing field (aka horses on treadmills) are helpingable
too if you train them to do something besides horsing
hero of the kingdom style strategy game with LoS for the units (scroll
out-table
like Supreme Commander) in lua tables that combine themselves or are organized
in a tree-like structure a'la frames
then there's a picture of some source code I wrote. it's a C program, and it
defines a datastructure comprised of two bits each, and stackable into an
array with associated modifier functions. the purpose of the structure is to
represent compass-points (one byte (aka "word" in assembly) can store four of
four directions. one frame holds "left, right, near or away" as possible
values, and there are four frames in a byte (aka "word" in assembly).
aka, a princess simulator, with actors performing the distant tasks in a way
that corresponds to the nature of what's going on beyond them in a compass
orientation composed fourier-transform combination style
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═══════════════════════════════════════════════════════════════════════────┘
=== SIMILARITY RANKED ===
--- #1 fediverse/5180 ---
═══════════════════════════════════════════════════════════════════────────────────
it's trivial to run a C compiler inside of a lua interpretation of a script.
And vice versa - you could totally run lua functions from C. Just point to the
spot in memory where they're stored / operating, and call
"update_class_exhibitor_type_d()" and the linker will come along and say "huh
this looks like something from this library that's part of the requirements up
above" (the "includes" section is where you say which files include the
functions you're going to be calling) and in this particular case it would see
that you need to start up a lua interpreter inside of the [either compiler or
running program I can't remember] to properly execute the function of the
function that you're pointing at with a lua-pointer style data object which is
part of a struct that stores all the other lua functions in a spot in memory.
this would enable you to write computer programs in whatever language you
choose, and build them into one large project. Essentially opening up software
development to ANYONE WHO CAN PROGRAM
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧════════════════════════════════════════════════════════════───────────────┘
--- #2 fediverse/616 ---
╔═════════════════════════════════════════════─────────────────────────────────────┐
║ To program in C, or to disassociate into the world of video games, where a │
║ single magical kingdom of heroes and adventurous persons might fight against │
║ the dark of chaos and decay? To strive for order and a semblance of peace, or │
║ to fall to the terrors of the night and ravages of horror? War, in all it's │
║ forms, is abhorrent, yet a fight for survival is honest and just. What perils │
║ have we, the warriors that seek the light? How zealous, how impassioned, how │
║ guided as such~! Perhaps you are misinformed, perhaps your cause is false, │
║ perhaps you derive true satisfaction from imperfect delights - alas, that our │
║ will be universal. BUT should that plight be alight, we'll wander until the │
║ night lit by starlight be cast upon our shadowed form. Absoleth! Thine │
║ countrospect? Didst thou caress thine marked circumspects? fare thee well, │
║ most cherished of adamants. │
║ │
║ ... what was I saying? Oh yes I've been working on this program that utilizes │
║ a particularly interesting data structure that- whats that? Oh, it doesn't do │
║ any │
╟─────────┐ ┌───────────┤
║ similar │ chronological │ different │
╚═════════╧══════════════════════════════════──────────────────────────┴──────────┘
--- #3 fediverse/3042 ---
═══════════════════════════════════════════════════════────────────────────────────
left stick is grab a target and bring it into context, right stick is for
drawing a pointer, a to group things together and b is to separate, etc etc
--
I remember coding it to be designed around two dimensional arrays. It used
lateral numbers, AKA "imaginary" numbers (they aren't imaginary they're just
orthogonal to regular numbers - hence, lateral)
and like... the math worked, and it was all on a T9 keyboard.
I figure each memory location would be like, a function written in the
program, or perhaps a binary or script file in a nearby directory. by writing
a value to a certain coordinate, you are giving an input value to a function.
and if nothing is stored for that particular coordinate, then the command
fails to execute and nothing happens.
pointers to functions which may or may not exist.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧════════════════════════════════════════════════───────────────────────────┘
--- #4 notes/ai-variables ---
═════════════════════════──────────────────────────────────────────────────────────
saturday november 5th 2022
10:53pm
the illusion of our binary nature conceals a truth that is hidden for it's own
sake. the flavors of a compass or the values from 0-100 are all measurable.
if you graph each of them on an X/Y plane and compare them against every other
variable, then you can build a structure that traces a line through time.
imagine each graph on a sheet of paper. and stack those pages like a book. You
can chart a 3d line from all of the interconnections between the graphs -
essentially comparing unrelated data and conceiving of individual actions as
"successes" or "failures". Liiiike in Supreme Commander how the game is decided
not by team fights, but by tank fights. And a LOT of them, in aggregate, makes
an advantage for your team if you win, and a malus if you lose. Less map
control, less resources in play, etc...
Find trends between each type of data measured over time. Dedicate one
core/thread to each relationship, and just watch them develop over time.
send the results up to a "manager" - think an interconnection between disparate
parts that can lead them all to a larger goal - the manager processes the
results by thinking about where it'd be most useful. Like the circuitry in the
inside of a brain, compared to the outer skin which is for processing.
Essentially a message network that passes conclusions around like a bytecode VM
Here's how it'd look: gather inputs, compare measurement over time and trends,
(like "when a goes up b goes down") and decide if the current state is
positive / beneficial. The way you'd do that is you'd get a parameter from a
higher position (think KPI's) that says something like "we want value S to be
around X amount" or "we want to avoid letting J get too low - any decrease is
bad V.S. it's only bad when it passes a certain threshhold. Stuff like that.
Anyway, basically it's taking input (from the graphs) then going through them
one by one and deciding how positive or negative the situation is. Then it
passes that conclusion backwards, and BOOM you got a processing node.
Throw a bunch of those together in a pyramid shape, and try to guide the
triangle toward positive outcomes. The top tier KPI is "did you win the match"
or "did you accomplish your goal" sorta like how humans all want to live a good
life. It's instinct.
You can see how this would apply to robots, right? I've conceptualized it as an
engine for playing games - sorta like an infinite storyteller, or a perpetual
friend who's always down to play with you. But it doesn't have to be limited to
that - it's general purpose baby. And it functions the exact same as any human
organization - layers upon layers of thought exchange and labor. Have you ever
considered that maybe we exist simply to reify the structure of our minds in
the world around us? It's natural to express your *self*. Be who you are.
What purpose is there in life if it's simply the tip of time? Always pushing
forward, impossible to stop and rest or turn back...
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧══════════════════─────────────────────────────────────────────────────────┘
--- #5 fediverse/282 ---
════════════════════════════════════════════───────────────────────────────────────
@user-209
I think you're right. Every letter in the variable name is another byte the OS
has to keep track of, which was a bigger problem in the past than it is today
(when it's been made irrelevant)
it's interesting how habits persist though the conditions that caused them
have faded. like a personal reflection of the environment you learned in.
"A a = new a();" is much more concise and (crucially) you can fit more words
to the right.
"a + b = c; c -= 2; f_z.write(c); f_z.close();" could conceivably be written
on a single line if you have short variable names. and when you only have so
many lines...
glad we're not constrained by those things anymore. the skeletal code that we
look at daily is much clearer - scope is more important, and so it makes sense
to encourage a coding style that illustrates it. however I can't help but
think block formatting like this could be useful in some situations, such as
when you'd normally be compelled to write a function for an operation that
runs once or more.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═════════════════════════════════════──────────────────────────────────────┘
--- #6 notes/gametypes ---
═══════════════════════════────────────────────────────────────────────────────────
Here's my idea and I'll explain it later:
a video game with a ui that utilizes chat-gpt. The game is as close to a
simulation as it can do, but it's a dynamic simulation meaning the parameters
and values being simulated constantly change - not that the parameters and
values are dynamic, but because they are chosen to be more or less important in
reaching a goal.
but that's not even the important part - the important part is that the ui of
the game is textual, but it still simulates a dynamic playfield. And chat-gpt
describes it. Essentially stimulating the "theatre of the mind" playstyle. It's
a real simulation with real rules, but chat-gpt is just describing it like an
observer would. The real game is being played by the player. It's a movie to
one
person, and a game to another. The computer has switches roles, as usually it's
either the human being the observer and the computer being the simulator, or
the
computer and the human sharing the role of observer - movies and games. So in
this game, the computer and human have specific rules - the human's job is to
be
a player, while the computer is just an observer - therefore allowing a
conversation to take place. One person says something while the other listens,
and then they switch roles such that the other person talks while the one
person
does the listening. And they "speak" by playing the game. The computer by
simulating, the player by doing the same. Essentially you can engage with one
another and share something profound - that essential feeling of connection
that
all humans relish. Society, culture, and devotion are all examples of
connection. this gameplay is just another. So to describe it in more detail:
player gives a prompt
computer sets up the playmat by placing entities where they go
chat-gpt describes the playmat to the player
player types a decision that one of the entities makes
computer reacts by simulating the effects of that action physically (like a
physics simulation)
chat-gpt (and stable-diffusion later for visuals) describe the situation by
creating a rendering using the data given by the physical inputs given from the
simulation - like "X object is at Y position and has Z attributes"
which is then shown to the player
who types the next decision,
which is rendered by the computer,
which is described by chat-gpt
------
you see why it's important? Make something simple. Just, like spheres moving
around on blocks. Like the actual blocks you used to play with as a kid.
let the computer build the buildings, and you place the marbles. It can be
rendered with a 3d modelling stable-diffusion (whenever that's created) and it
can also be painted with 2d stable-diffusion.
Each time is like a letter written back and forth.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧════════════════════───────────────────────────────────────────────────────┘
--- #7 fediverse/5338 ---
═════════════════════════════════════════════════════════════════════──────────────
I asked my girlfriend what was so special about lisp
she said it was "homoiconic"
I asked what that meant
she said that the text that comprised the source code was always a valid data
structure in the language, meaning you could do strange things like develop
new control flow systems or change the behavior of language primitives like +
or -
I asked what was the point, she said I didn't get it
so then she asked me to implement a new control flow operator in my favorite
language, Lua, and I was like "bet"
so I did
and it turns out that in order to do so I essentially created a mini embedded
lisp inside of Lua
(it was a function that took in two arguments and an operator and she's like
congrats that's just lisp)
it was at this moment that I was enlightened
the beauty of lisp
it's true and ultimate purpose
is to write lisp code
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧══════════════════════════════════════════════════════════════─────────────┘
--- #8 notes/gpt-powered-majesty ---
══════════════════════════════─────────────────────────────────────────────────────
it's like majesty except textual. And it uses GPT to generate short
descriptions
of what's going on. And you can click on a phrase or token and it'll "zoom in"
and update the text descriptions with more detail. You can keep zooming in and
in until you're literally looking at microbes.
Zooming out is the same thing - the description on the page will slowly become
more and more general until eventually you have a description of the solar
system (or beyond!)
And it'll just keep updating as stuff happens in the underlying simulation. So
the descriptions will dynamically update as things happen. Downside is you need
to spend a lot on GPT but it'd be TOTALLY WORTH IT OMG
THINK ABOUT IT you have a fantasy world simulator! JUST PROGRAM IT and have GPT
describe it dynamically! DO IT NOOOOW -> capitals courtesy of "inner child"
AND THEN you just need a "prompt to video" AI (those exist btw, and will only
get better over time) and tell it to create a video of what's happening - BOOM
instant video game. THEN give the player the ability to edit the prompt, and
BAM
godlike powers. Wow what a concept. Brilliant idea Cameron, you truly are this
world's premier game designer. NOW GO MAKE IT okay okay I'll try.
First things first. We need an "underlying simulation" - Joust is a good
example
of GPT3 integration. But we need a simulation to go below it. And for that you
need a lot of data. Github COPILOT to the rescue.
So this simulation needs to keep track of positions, and classes of things that
can act upon the world. Everything has a position, and it can only affect
things
near it. That's just baked into the rules of the world. Near can be a
conceptual
near though, like being close to a person or something.
These things will have descriptions. Descriptions can be created by AI later
on,
but for now they are randomly generated. Or for MVP they can be static.
These things will have names. These names don't have to be unique, because they
also have an ID number.
They also need functions. These functions can be added and removed from the
thing, or maybe just enabled or disabled. I'm not sure which would be better.
Maybe both? So the entity can control it's own functions but also they can be
added or removed more permanently.
If you think about it, growing up is kinda like adding functions to your class.
like, every time you do something, it adds another entry for that particular
method. Like a "trial of the fittest" instead of "survival of the fittest".
When other animals *literally fight for life and death survival*, humans have
the luxury of... not doing that. That's the entire purpose of civilization - to
elevate people beyond the claws of nature. And yet we still let people go
homeless? We still imprison them when they've harmed us, rather than help them
reintegrate to society? Anyway you just asked me to hit you so here goes:
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═══════════════════════────────────────────────────────────────────────────┘
--- #9 notes/wow-chat-is-risk-of-rain-in-another-engine ---
═════════════════════════════════════════──────────────────────────────────────────
game mechanics are easily transferrable.
you can use the mechanical interactions of one game as a pre-planned blueprint
for what is to come. Looking forward to the next best move
= etc
i am the face the gods hide behind
they kinda want to see where this goes
and it's... frustrating, to know they can help you, but forever be tasked with
just life
it's grand and it's a standard, but that doesn't mean it's commands're heard
so oh well. that a fourth dimensional being should not be a well,
because fire think it's an eye for a sunspot. But that's not what would be
========= stack overflow
=======================================================
now, as I was saying, the light of our eyes is apparent. We are clear from
where
we are here, to know that what's standard is coherent, so let's find strength
in our wavelengths.
may our eyes be ever true, and trust that we do love you, for without you I'd
di
anyway now that we've assent'd t'you, what truths do you give to our prospects?
what ways can we be measured as worth less? we'll do whatever it takes to
improv
you know, it's really less complicated than that. here let me tell you all
about
my idea which is clearly
all===============================================stack
overflow ==================
So anyway now that was somethin' hey what do you
say
we give you a chance to come home?
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧══════════════════════════════════─────────────────────────────────────────┘
--- #10 notes/majesty-ai ---
═══════────────────────────────────────────────────────────────────────────────────
First things first, we need to develop a miniature game of star realms.
It shouldn't be too hard, just start with making a card class that has certain
attributes, like "combat" or "discard" or whatever. They could literally be
enums with a value attached.
Next set up the rules of the game, like "draw 5 cards" and "add card to deck"
Create a deck class that holds pointers to cards (in the general sense)
Next create methods on that deck for things like "drawing a card" or
"shuffling discard pile into deck" and whatnot. Arrange each card in a specific
order for each shuffle, and add the ability to convert one card's attributes
to something else - whether that be "is_scrapped" or "if you've played an X
card this turn then do Y" or even "add one authority for every time card is
played" (to simulate an ability or boon that increases in effectiveness as the
hero uses it more often) etc etc.
Then, add a trade row. This is just a class that contains pointers to each card
that currently exists on it. Also add a method for "scrapping" one of the cards
and for drawing a new card from the pile. That's pretty much it for the trade
row to be honest.
Next add functionality for an opponent by creating a "game" method that stores
the two player's decks (with the ability to add more than 2) and administers
turn order. This functionality can be expanded later once we've implemented
attributes, but for now that's pretty much all it needs to do.
Finally, we get to the AI part.
First we have to create an AI object that stores a list of all options for a
turn. Essentially just evaluating every option if/then style - "this card costs
5 coins so IF the player has enough coins THEN (evaluate effectiveness)"
ignore that last part for a second and just focus on the IF part ->
essentially
just start with all available options, and then remove all the unavailable
options from the list. This approach only works when there's just a few
options, but that's why we're using Star Realms which only has like 2 or 3
decisions per turn.
The evaluation is the next step, and for that we need to have goals, so we'll
just put a pin in evaluation for now. Spoiler alert, once we have goals we'll
just estimate how close each choice will bring us to the objective and assign
the result to the "effectiveness" value, which will give us a simple hard
number to work with in the evaluation step.
So, next up we have "goals"
So to create a short term goal, we can start with a pregenerated list and
continuously increase the list as the hero levels up. But in the context of
Star Realms, that'd essentially be static for each hero. Goals like "buy more
combat" or "scrap more cards" would be specified on the hero's character
sheet, but until we develop that functionality it can be randomly rolled.
Why not just do it the hard way now if we're just going to have to refactor
it later? Well, because we can still use this functionality - Each round of
Star Realms could be either randomly rolled, or given a personality. Randomly
rolling would be MUCH cheaper computationally, and would still give an illusion
of character because they are unpredictable, but it'd also massively cut down
on GPU cycles. You could even build it into the mechanics of the game and say
that "wisdom" for example might cause a hero to receive more GPU cycles on
actually computing their goals rather than randomly rolling them, which would
on average lead to worse outcomes. Essentially, turning "tactics" into a stat.
Anyway, that's all theory. Let's get back to design:
Create a "hero" object, and attach an AI to it. It doesn't have to do anything
right now, we're just setting up an anchor point to jump off of once we move
on to the game of Majesty. Give it a reference to an AI object, an inventory
(which for now can just be potions and maybe blacksmith equipment), and a
pointer to a "stat block"
Now create a "character sheet" class and give it a reference to a hero. This is
important because it allows one character sheet to reference multiple units,
such as hirelings or summoned units. In additon, it may make it easier when we
need to revive heroes from the dead. Primarily though, the purpose for this
architecture style is that the data from heroes can be reused - essentially
letting heroes learn from one another.
On the character sheet, add a section that stores statistics - these will be
the same for every unit of a similar type in the game, and some of them can be
stored for all units (like health or x,y coordinates) - some only for buildings
(like tax coffers) and some only for heroes and monsters (like strength or
agility or experience points)
Add some methods for manipulating those values, like "level up" and "take
damage" and add a "personality" value that's just a 4d graph of colors
for example: 40% red, 20% green, 15% blue, 25% yellow. These values will guide
the hero to take certain decisions over others, but for now just randomly
generate them. We'll also need a way to update the value dynamically to react
to certain events, so don't make it static.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘══════───┴╧───────────────────────────────────────────────────────────────────────────┘
--- #11 fediverse/5637 ---
═══════════════════════════════════════════════════════════════════════────────────
a program's heartbeat is the alternating "heated up processor" spikes and the
"low temp processor"
[drawing a sine wave with such a tool would enable the viewer to combine
infinitely many decision-matrix-trees. Each of which
co-operatively-co-determine the nature of the entity which percieves. indeed
the combination of many such waves could fourier transform to a lower
resolution (but still locally computationorted) waveform would still enable
the application of that which is stored in storage]
"ohhhhh strange square brackets are computer"
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧════════════════════════════════════════════════════════════════───────────┘
--- #12 notes/symbeline ---
════════════════───────────────────────────────────────────────────────────────────
Code Name: Symbeline
----------------------------- gdd initial draft -------------------------------
1. introduction to fantasy (elevator pitches)
2. kickstarter demands
2. introduction to core gameplay loop
4. tenants and core values of the game design
3. introduction to game modes
5. introduction to technical requirements
6. breakdown of core gameplay loop
7. breakdown of game modes
8. breakdown of fantasy
9. breakdown of technical requirements
-------------------------- introduction to fantasy-----------------------------
Symbeline is a macro based strategy game and city-builder based around the
concept of indirect control. It's inspirations are Majesty the Fantasy Kingdom
Simulator (2000), Supreme Commander (2007), and Hearts of Iron IV (2016). It is
designed to appeal to fans of tabletop roleplaying games with it's focus on
dynamic worldbuilding and sandbox playstyle. The gameplay consists of multiple
playstyles depending on which aspects of the game appeal to the player, with
choices between an economic focus via the GUI, longterm planning and resource
allocation, or diplomacy and subterfuge a'la Ruinarch (2020).
---------------------------- kickstarter demands ------------------------------
1. prototype
2. gdd
3. estimates for character and environment art
4. estimates for music and sounds
5. estimates for engine development
6. estimates for community management
7. breakdown of mvp, ideal game state, and stretch goals
----------------------- introduction to core gameplay loop --------------------
1. management of lanes, both width and length
2. casting of spells and utilization of special boons
3. city building with placement, upgrades, and henchmen pathing routes
4. satisfying guild requirements of equipment, manpower, and special
resources by managing shipments and local income (UI commodity trading)
5. placement of generalized bounties
(think champion's guild from Majesty, not reward flags)
6. diplomacy with neutral, AI, or player controlled kingdoms. Capabilities
include pacts and treaties, projects, subterfuge, and tournaments. The
diplomacy system can be a stretch goal.
-------------------------- tenants and core values ----------------------------
1. always something to do, but nothing falls apart without your attention.
2. gameplay should be focused on macro rather than micro. Longterm planning
and strategic decision making are favored over tactics and skill.
3. defeat should feel avoidable until the last moment, and only as a result
of longterm continuous failures rather than short-term mistakes or being
blindsided by a cheesy tactic.
4. victory should be gained through exploiting weaknesses and by using
lateral thinking.
5. the careful balance of internal and external threats is essential.
6. rapid expansion leads to depletion of internal resources, while slowly
expanding can lead to a lack of options
7. the world should feel alive and reactive to your decisions.
8. your kingdom should feel alive and reactive to your decisions.
9. your heroes should feel alive and completely ignorant of your decisions.
10. there should always be opportunities for cooperation with your fellow
kingdoms.
11. the frontlines should feel peaceful outside of large battles.
12. everything is flexible and dependant on circumstance
13. there should be enough space on the map for multiple parties of heroes
to pass each other like ships in the night without engaging in combat.
It should feel like the real world, with canyons and valleys and rivers
and mountains - room for lairs and wild animals to roam.
14. monsters are always more dangerous than other humans.
15. the art style should be rooted in classic medieval fantasy.
16. equipment should feel either mass-produced (kingdom), organic (monsters),
ancient (lair treasure), or artisinal (enchanted).
17. heroes should feel campy, fun, and adventurous. Avoid dark, grim, and
fearful.
18. This game is a toy.
19. This toy should run on any modern computer.
20. This toy should encourage modding.
-------------------------- introduction to game modes -------------------------
1. singleplayer - single kingdom against an island of monsters and neutral
settlements. essentially the multiplayer game against
zero opponents.
2. singleplayer - multiple kingdoms against an island of monsters and
neutral settlements. One player controlled kingdom against
multiple AI controlled kingdoms.
3. singleplayer - scenarios, similar to MFKS
4. multiplayer - multiple kingdoms against an island of monsters and
neutral settlements. Essentially the singleplayer game
with networking added in.
5. multiplayer - co-op scenarios where multiple players play as the same
kingdom. A test of the core tenant "there's always
something to do"
6. multiplayer - co-op island invasion. Essentially the multiplayer game
with more than one player controlling a kingdom.
7. singleplayer - play in 3rd person as a hero in an AI kingdom. Mostly for
the novelty since the core gameplay loop is focused on
city-building. A test of the core tenant "nothing falls
apart without your attention"
1 is mvp. 2-6 are stretch goals in order of ascending difficulty. They
should build upon one another - the main steps are:
1. singleplayer island invasion (biggest step)
2. AI controlled kingdoms
3. scenarios
4. multiplayer (second biggest step)
5. cooperatively controlling the same kingdom
6. 3rd person perspective and character controller
------------------------ technical requirements -------------------------------
1. this game will be written in lua (with Fennel support) and using Raylib.
2. the prototype will be made with Godot using GDscript.
3. if the performance demands are too much for lua or the engine is out of
scope for the budget, Rust with the Bevy engine could be used.
4. the final product will include a custom 2d engine designed for large
scale maps with an isometric perspective and a data-first design.
5. the game should be as concurrent as possible, to support large numbers of
cpu cores and compute shaders.
6. the game will be data-driven, meaning the visual aspects are simply a
representation of the interactions of the underlying simulation, rather
than an intrinsic component of the computation.
7. Each "event" in the game (a character moves, a building is placed, a
monster spawns, etc) will send a message to the visual processing side of
the engine, which will present a representation to the user.
8. the map will be a hex grid with pointed-top hexagons. The visual
representation of the underlying data may be continuous (non-hex) but the
underlying data will be represented on a hexagonal grid.
9. there needs to be character portraits for each type of monster, henchmen,
and hero type. You should be able to recognize what attributes a hero
specializes in by their portrait. Mvp is 1 attribute, but more can be
a stretch goal.
10. Each building, upgrade, and equipment type needs an icon. Stretch goals
can be portraits.
11. each henchman, hero type, and monster needs 3 sprites for each action.
more actions may be added if budget allows, but mvp is movement and
attacking. Several additional sprites may be necessary, like dying,
standing still, gathering loot, socializing, or any others.
12. each building needs 4 sprites for the construction process and 4 for the
destruction process. Flame effects are stretch goals.
13. each building needs an animated sprite for when it is in use.
14. each lair needs a sprite and an icon.
15. each spell needs an icon and a spell effect sprite. Each projectile needs
a sprite.
16. a stretch goal would be differing sprites for each piece of equipment.
included with this would be engine work to allow for dynamic sprites.
17. each terrain type should have a ground material and sprites for doodads.
18. there needs to be several GUI menus. The precise number depends on
gameplay breakdown.
17. each hero type and henchman needs to have pithy and unique voice lines.
this is a stretch goal.
18. there should be music tracks for each part of the game - beginning,
middle, and end.
19. there should be sounds for each action that takes place in the game
including combat, UI interactions, and spellcasts.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═════════──────────────────────────────────────────────────────────────────┘
--- #13 notes/symbeline-2 ---
════════════════════════════════───────────────────────────────────────────────────
Code Name: Symbeline
----------------------------- gdd initial draft -------------------------------
1. introduction to fantasy (elevator pitches)
2. kickstarter demands
2. introduction to core gameplay loop
4. tenants and core values of the game design
3. introduction to game modes
5. introduction to technical requirements
6. breakdown of core gameplay loop
7. breakdown of game modes
8. breakdown of fantasy
9. breakdown of technical requirements
-------------------------- introduction to fantasy-----------------------------
Symbeline is a macro based strategy game and city-builder based around the
concept of indirect control. It's inspirations are Majesty the Fantasy Kingdom
Simulator (2000), Supreme Commander (2007), and Hearts of Iron IV (2016). It is
designed to appeal to fans of tabletop roleplaying games with it's focus on
dynamic worldbuilding and sandbox playstyle. The gameplay consists of multiple
playstyles depending on which aspects of the game appeal to the player, with
choices between an economic focus via the GUI, longterm planning and resource
allocation, or diplomacy and subterfuge a'la Ruinarch (2020).
---------------------------- kickstarter demands ------------------------------
1. prototype
2. gdd
3. estimates for character and environment art
4. estimates for music and sounds
5. estimates for engine development
6. estimates for community management
7. breakdown of mvp, ideal game state, and stretch goals
----------------------- introduction to core gameplay loop --------------------
1. management of lanes, both width and length
2. casting of spells and utilization of special boons
3. city building with placement, upgrades, and henchmen pathing routes
4. satisfying guild requirements of equipment, manpower, and special
resources by managing shipments and local income (UI commodity trading)
5. placement of generalized bounties
(think champion's guild from Majesty, not reward flags)
6. diplomacy with neutral, AI, or player controlled kingdoms. Capabilities
include pacts and treaties, projects, subterfuge, and tournaments. The
diplomacy system can be a stretch goal.
-------------------------- tenants and core values ----------------------------
1. always something to do, but nothing falls apart without your attention.
2. gameplay should be focused on macro rather than micro. Longterm planning
and strategic decision making are favored over tactics and skill.
3. defeat should feel avoidable until the last moment, and only as a result
of longterm continuous failures rather than short-term mistakes or being
blindsided by a cheesy tactic.
4. victory should be gained through exploiting weaknesses and by using
lateral thinking.
5. the careful balance of internal and external threats is essential.
6. rapid expansion leads to depletion of internal resources, while slowly
expanding can lead to a lack of options
7. the world should feel alive and reactive to your decisions.
8. your kingdom should feel alive and reactive to your decisions.
9. your heroes should feel alive and completely ignorant of your decisions.
10. there should always be opportunities for cooperation with your fellow
kingdoms.
11. the frontlines should feel peaceful outside of large battles.
12. everything is flexible and dependant on circumstance
13. there should be enough space on the map for multiple parties of heroes
to pass each other like ships in the night without engaging in combat.
It should feel like the real world, with canyons and valleys and rivers
and mountains - room for lairs and wild animals to roam.
14. monsters are always more dangerous than other humans.
15. the art style should be rooted in classic medieval fantasy.
16. equipment should feel either mass-produced (kingdom), organic (monsters),
ancient (lair treasure), or artisinal (enchanted).
17. heroes should feel campy, fun, and adventurous. Avoid dark, grim, and
fearful.
18. This game is a toy.
19. This toy should run on any modern computer.
20. This toy should encourage modding.
-------------------------- introduction to game modes -------------------------
1. singleplayer - single kingdom against an island of monsters and neutral
settlements. essentially the multiplayer game against
zero opponents.
2. singleplayer - multiple kingdoms against an island of monsters and
neutral settlements. One player controlled kingdom against
multiple AI controlled kingdoms.
3. singleplayer - scenarios, similar to MFKS
4. multiplayer - multiple kingdoms against an island of monsters and
neutral settlements. Essentially the singleplayer game
with networking added in.
5. multiplayer - co-op scenarios where multiple players play as the same
kingdom. A test of the core tenant "there's always
something to do"
6. multiplayer - co-op island invasion. Essentially the multiplayer game
with more than one player controlling a kingdom.
7. singleplayer - play in 3rd person as a hero in an AI kingdom. Mostly for
the novelty since the core gameplay loop is focused on
city-building. A test of the core tenant "nothing falls
apart without your attention"
1 is mvp. 2-6 are stretch goals in order of ascending difficulty. They
should build upon one another - the main steps are:
1. singleplayer island invasion (biggest step)
2. AI controlled kingdoms
3. scenarios
4. multiplayer (second biggest step)
5. cooperatively controlling the same kingdom
6. 3rd person perspective and character controller
------------------------ technical requirements -------------------------------
1. this game will be written in lua (with Fennel support) and using Raylib.
2. the prototype will be made with Godot using GDscript.
3. if the performance demands are too much for lua or the engine is out of
scope for the budget, Rust with the Bevy engine could be used.
4. the final product will include a custom 2d engine designed for large
scale maps with an isometric perspective and a data-first design.
5. the game should be as concurrent as possible, to support large numbers of
cpu cores and compute shaders.
6. the game will be data-driven, meaning the visual aspects are simply a
representation of the interactions of the underlying simulation, rather
than an intrinsic component of the computation.
7. Each "event" in the game (a character moves, a building is placed, a
monster spawns, etc) will send a message to the visual processing side of
the engine, which will present a representation to the user.
8. the map will be a hex grid with pointed-top hexagons. The visual
representation of the underlying data may be continuous (non-hex) but the
underlying data will be represented on a hexagonal grid.
9. there needs to be character portraits for each type of monster, henchmen,
and hero type. You should be able to recognize what attributes a hero
specializes in by their portrait. Mvp is 1 attribute, but more can be
a stretch goal.
10. Each building, upgrade, and equipment type needs an icon. Stretch goals
can be portraits.
11. each henchman, hero type, and monster needs 3 sprites for each action.
more actions may be added if budget allows, but mvp is movement and
attacking. Several additional sprites may be necessary, like dying,
standing still, gathering loot, socializing, or any others.
12. each building needs 4 sprites for the construction process and 4 for the
destruction process. Flame effects are stretch goals.
13. each building needs an animated sprite for when it is in use.
14. each lair needs a sprite and an icon.
15. each spell needs an icon and a spell effect sprite. Each projectile needs
a sprite.
16. a stretch goal would be differing sprites for each piece of equipment.
included with this would be engine work to allow for dynamic sprites.
17. each terrain type should have a ground material and sprites for doodads.
18. there needs to be several GUI menus. The precise number depends on
gameplay breakdown.
17. each hero type and henchman needs to have pithy and unique voice lines.
this is a stretch goal.
18. there should be music tracks for each part of the game - beginning,
middle, and end.
19. there should be sounds for each action that takes place in the game
including combat, UI interactions, and spellcasts.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═════════════════════════──────────────────────────────────────────────────┘
--- #14 notes/symbeline-aspects ---
═════════════════════──────────────────────────────────────────────────────────────
7-24-22
There are three aspects to this game. Broadly, they are military, economics,
and diplomacy. More specifically, they are lateral problem solving and lane
management, logistic traffic management, and a worker-placement bluffing game.
These three aspects can be toggled on and off at will, essentially designating
one or more as "AI controlled" and will require no input from the player. They
will time their progression to be about at the same rate as the player, thus
creating a balanced feel to the game. They also provide alerts and
notifications to the player, for example if military is AI controlled and it
needs a certain type of hero to progress, it'll ask for it specifically.
Each aspect will develop and progress at it's own rate, and the difficulty
increases as each milestone is achieved. This is to allow the player to create
their own difficulty curve, mediated primarily by their drive to proceed.
An analogy would be in Factorio, the game doesn't increase in difficulty unless
the player builds pollution spawning factories - in the same way, in Symbeline
the difficulty doesn't increase unless the player solves lane challenges in the
military aspect, develops new trade routes / traffic paths in the economic
aspect, or creates new treaties in the diplomatic aspect.
In order to properly explain each aspect, a brief overview will be necessary.
In Symbeline, the game plays as a factory might operate. The economic aspect
produces heroes, items, and other deliverables that are consumed by the
military and diplomatic aspects. There are various problems that need to be
solved far from the capital, such as a particular type of monster that is weak
or immune to various damage types which necessitates particular heroes or
items in order to progress on the military aspect. All of the resources in the
game operate on an "income based" system, where output is not measured in total
amounts but rather in terms of how much is produced versus consumed. If the
input cannot meet the demand, the output is slowed. If input exceeds demand it
can be converted into gold which can be used to hire guards and heroes.
Resources can be produced inside and outside of the city, depending on their
type. But they need to be moved around to various shops for various processing
and productive purposes, so pathways must be constructed to deliver those
goods. In addition, each building must be supported by several houses for the
workers to live in, and the closer they are to the building the better. The
denizens of the kingdom don't mind being shuffled about, so they'll organize
themselves according to what's most efficient. However they will not organize
the paths they take to get places, which is the primary gameplay for the
player - designing routes for each building and ensuring they don't overlap or
cross too many times, causing traffic and disruptions to your income.
Each choice the player makes is immediately reflected in the income
calculation, thus allowing for the visual aspect of the game to be wholely
separate from the economic side - in fact this is a common thread throughout
all three aspects. Computation power is the ultimate enemy of scale, and this
game flourishes with a massive scale.
The gameplay for the military aspect consists of manipulating "lanes" that
designate where each hero will adventure. These lanes are scalable to the
player / AI's whims, with a careful balance required - too thin, and the heroes
might not encounter enough monsters to level up. Too thick, and they may find
themselves patrolling a vast wilderness full of dark and evil monsters. At the
end of every lane is a "frontline", where progress has essentially been halted.
These frontlines can develop as a result of meeting a foreign kingdoms front
or finding a monster type or puzzle that is particularily difficult for your
heroes to overcome. The lane / frontline can be scaled not just laterally, but
linearly as well such that heroes will be a certain level when they reach the
end - think scrolling on a mousewheel translating into deepening level zones.
In addition, each monster zone can be set to a certain "security level" meaning
how many monsters are there for your heroes to defeat. It's important that they
have ample targets for training, however it's always more effective to train on
monsters near their level so you have to be careful not to wipe out the native
skeleton / goblin / troll population.
Each monster zone can have a relationship with the kingdom, on a 2x2 matrix -
cultivating / desecrating the land, and fostering / exterminating the monsters.
The land produces monsters and treasures, while the monsters provide experience
and danger to the heroes and kingdom denizens who live there. However by
desecrating the land, farms may be built and by exterminating the monsters,
those farms may be safe and require fewer guards. As ruler, you must balance
the development of unique magical and alchemical productions with the need for
food and other mundane requirements.
Diplomacy is a careful balance of internal and external matters, played out
through feasts, tournaments, and faires. Each of these events will require
input from the economic side and military side, and will involve "courting"
other nobles from neighboring kingdoms to sway them to supporting your edicts.
When hosting an event, you may pick a particular topic of conversation for your
nobles to discuss with their guests. You may also assign your nobles to
attempt to engage with a particular foreign noble. Each member of your court
has a differing personality (including you, the Majesty) and depending on how
you assign them you may experience better or worse results - such as assigning
someone who's kind to talk with someone who's cruel would impart a malus to
their conversation. Unless the kind person has the trusting trait, in which
case they'd succeed in this encounter but fall sway to them in future
conversations... Complex interactions that all boil down to a single pair of
d12 dice - one for your noble, one for the enemy. This represents the charisma
of the two conversants on that particular day, and whoever wins the roll sways
the other to supporting their edict. Speaking of edicts, they may include trade
agreements, non-aggression pacts (lasting for a short time), and other
regulations - perhaps your greatest rival utilizes necromancy, so it would
behoove you to attempt to regulate the practice and limit it's effect. By
swaying the nobles of their kingdom, you may be able to enact a mutual
agreement to limit the usage of dark magics, essentially hamstringing their
progress. But in order to learn of their necromantic usage, you'll need
espionage... Which brings us to spies.
Spies are similar to nobles in that they can be assigned to various roles,
however they take a more passive role, acting in the background. The
information they gather is compiled into a report that is presented at
pertinent parts of the game, such as when preparing for a feast or inspecting
an enemy frontline. These reports are considered the diplomatic deliverables,
giving information and mechanical bonuses to many different parts of the game.
They may be given three possible roles - information, defence, or offense.
Offense involves placing cursed artifacts (creating through economy) in enemy
lands, which debuff their heroes when used and bind themselves to them
preventing their removal except through extraordinary means. Defence is
essentially countering that in your own kingdom, and uncovering disloyalty in
your nobles.
These three aspects fit together like interlocking puzzle pieces, but each is
able to be utilized or ignored depending on the preferences of the player.
It is important that the game doesn't progress unless input is received. The
simulation plays in the background, but each stage of development must be
considered "stable" such that nothing changes. There are three different
exceptions to this rule, one for each aspect:
The military side encounters raids from enemy kingdoms and the dark lord.
The economic side encounters raids from ratmen and moss trolls and bandits.
The diplomatic side has a rolling schedule of events that must be attended.
These three "exceptions" are recurrent events that require attention, but they
don't *increase* in difficulty unless the player takes an action that causes
it. Meaning, if the player overcomes the rock golems, then they are displaced
from their home and join the dark lord in his conquests. If a new district is
built new sewer connections must be built as well, creating a larger attack
surface for ratmen to exploit. As time goes by, various foreign events must be
attended, as absence causes your future events to attract fewer foreign nobles.
By addressing these threats, your kingdom may grow and eventually overcome the
dark lord at the center of the island.
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧══════════════─────────────────────────────────────────────────────────────┘
--- #15 fediverse_boost/5981 ---
◀─╔═══════════════════════════════[BOOST]════════════════════════════════────────╗
║ ┌────────────────────────────────────────────────────────────────────────────┐ ║
║ │ Some programming languages I’ve tried and liked and would recommend to others:C (especially C89/C90/“ANSI C” and C99)posix shell, bourne shell, and similar shells (bash, ksh93, mksh)PHPScheme (depending on the vibes I’m getting from someone I might recommend)Common Lisp (Same caveat as Scheme)Emacs Lisp (Same caveat as Scheme and Common Lisp)Motorola 68000 assembly │ ║
║ │ │ ║
║ │ Some languages I’ve tried and liked but would not recommend to others:Hewlett-Packard RPL (Actually I might recommend it to someone but it has to be a very specific kind of person)FORTH (same as RPL)Commodore BASIC (Microsoft BASIC) for the VIC-206502 assembly (so bad it’s good)Z80 assembly │ ║
║ │ │ ║
║ │ Some languages I’ve tried, did not like, and would not recommend to others:COBOL (maybe I could get used to it? I can at least read it. Just it’s so painfully like writing SQL statements without being as generally useful as SQL database queries)Kotlin (Like that feeling when you read words that alone you understand, but together in a sentence they make zero sense)JavaClojure (a.k.a. “Let’s make Common Lisp but make it worse”)Rust (stands for “Ridiculous Use of System Time” or something as far as I am concerned, heavy on memory and storage and super slow to compile and reads like Kotlin)TI BASIC (TI-82/83/84 style; TI-89 is a little bit better but still not good)C++ (unless you’re just writing almost completely C and building it with a C++ compiler)x86 assembly (I kind of like it but mostly don’t, there are better and more coherent CISC processor ISA’s if you’re into that) │ ║
║ │ │ ║
║ │ I should put Javascript somewhere, so I’ll say that it’s possible to write javascript code that I like and can read. Just no one chooses to do it anymore. There was a window between the time JQuery started to fade and all these stupid fucking “web frameworks” took off that it was somewhat tolerable. │ ║
║ └────────────────────────────────────────────────────────────────────────────┘ ║
╠─────────┐ ┌───────────╣
║ similar │ chronological │ different ║
╚═════════╧════════════════════════════════════════════════════════════┴───────╝─▶
--- #16 fediverse/5212 ---
════════════════════════════════════════════════════════════════════───────────────
the reason you start with a game engine is because then you'll have tools to
make however-many games you want. Tools that you know intimately enough that
you can debug and improve them without breaking your creative flow by learning
something new halfway through a project
the whole point of individualized projects instead of viewing each computer as
a complete and total whole (why do we need servers again?) is that you can
paint a picture of where the design of the program is intended to go, such
that all the considerations are in place and whatever issues or struggles you
might face along the way are adequately addresssed, -- stack overflow --
[because I mistyped addressed] -- -- if you know what "stack overflow" means
you have intimate knowledge of the technology, and can probably guess what it
means in context when I say it. "nuts I lost that train of thoguht" -- stackl
ov
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═════════════════════════════════════════════════════════════──────────────┘
--- #17 fediverse/5903 ---
══════════════════════════════════════════════════════════════════════════─────────
when talking to claude, your filenames should never have extensions and you
should write in english. "picture of a signpost, one reading "function_A()"
and one reading "function_B()" each to take you to a destinonewscenery." or
something like that.
-- stack overflow --
a tub of icecream that has icecream around the side with a pillar / bone of
caramel straight down the middle like looking down a record.
-- stack overflow --
what if every address received a listing and description of each crime or
situation that happened in their city / neighborhood in the past week or
whatever
-- stack overflow --
boar hide helmet except, it's a metal helmet with an intimidating face on top
like shogun horns, or nordic vampires.
or felted wool, so you can see the shape of it but not be hurt when you bounce
off of it
this is my favorite shape: but felted a quarter to half inch thick. could have
metal inside or no.
-- oh boy here I go postin' again --
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═══════════════════════════════════════════════════════════════════────────┘
--- #18 fediverse/5237 ---
╔════════════════════════════════════════════════════════════════════──────────────┐
║ that feeling when you're working on a large piece of software which has the │
║ capability to process in advance which operations will go in what order (a │
║ form of constant re-compilation) and schedules tasks like an operating system, │
║ to be executed on one of many individual threads. │
║ │
║ your filemanager probably has a thread for a moment, then passes it back, │
║ waiting it's turn to be updated while you're messing around on Inkscape or │
║ writing something in Neovim or running neofetch 256 times in order to find the │
║ best background to go along with it or whatever it is people do when using │
║ computers │
║ │
║ the task scheduler meanwhile has the glorious opportunity to work at a higher │
║ level of abstraction, managing each individual process and learning bits and │
║ pieces of what needs to be processed next. It all gets put on a list, and │
║ whenever a new thread comes up to be available it can point it toward one of │
║ those in the list of tasks to be executed by the task executor who works on a │
║ schedule and laughs externally in wintertime~ │
╟─────────┐ ┌───────────┤
║ similar │ chronological │ different │
╚═════════╧═════════════════════════════════════════════════════════───┴──────────┘
--- #19 fediverse/3482 ---
════════════════════════════════════════════════════════───────────────────────────
┌───────────────────────┐
│ CW: cursing-mentioned │
└───────────────────────┘
"Alright I'm not great with syntax so I'm going to write it in pseudocode
first, and then if you'd like I can show you how I work through implementing
the syntax.
But first - do you want a robust solution, a quick solution, or a rapidly
deployed and cheap solution?"
using this trick you can pretend to be competent in any programming language,
except maybe ancient ones like Fortran or strange ones like lisps or Haskell
if they ask you to use a framework or something tho you're kinda boned because
you need to know which functions to call and how to initialize context and
such. When using a framework, the boilerplate is the code, which is why
frameworks suck
"don't call yourself a programmer" fuck off
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═════════════════════════════════════════════════──────────────────────────┘
--- #20 fediverse/2879 ---
══════════════════════════════════════════════════════─────────────────────────────
┌────────────────────────┐
│ CW: re: tech info-dump │
└────────────────────────┘
@user-1370
I love this a lot! I want to put function pointers in a "matrix architecture
array" and make them point to different functions at different points in the
program. I bet you could even point them at each other, so like if M and Y
then point at N, A, Y or something.
this is really cool I like stuff like this tomorrow I'll take pictures of
something similar I'm working on! I abandoned it tho hehe anyway remind me if
I forget!!
┌─────────┐ ┌───────────┐
│ similar │ chronological │ different │
╘═════════╧╧═══════════════════════════════════════════════────────────────────────────┘
|