=== ANCHOR POEM === ╔══════════════════════════════════════════════════════════────────────────────────┐ ║ ┌────────────────────────┐ │ ║ │ CW: opinionated-design │ │ ║ └────────────────────────┘ │ ║ │ ║ │ ║ Steps to make a game waterfall style: │ ║ │ ║ Lay out all the data structures and arrange them in containers like arrays or │ ║ hashmaps │ ║ │ ║ Build methods which manipulate those structures (think getters and setters) │ ║ │ ║ Then build machinery which operates upon those structures using those methods, │ ║ like game loops, cooldown timers, status effects, and thread pools. │ ║ │ ║ Then develop a way to present it to the player using UIs, visuals and │ ║ graphics, narratives, sound, etc. This will probably involve implementing your │ ║ game in an engine like Godot, Raylib, or Bevy. │ ║ │ ║ By developing your game in this order, you will DESIGN the systems first, and │ ║ IMPLEMENT them second. Systems are agnostic - implementation is tied to a │ ║ specific engine. You will learn more about programming by doing it this way, │ ║ instead of losing your motivation by learning new tools like game engines or │ ║ 3D modeling systems, which aren't useful unless you already have a game. │ ║ │ ║ I'd recommend starting with pencil and paper until you're ready to implement. │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧═══════════════════════════════════════════════─────────────┴──────────┘ === SIMILARITY RANKED === --- #1 messages/574 --- ═══════════════════════════════════════════════════════════──────────────────────── Steps to make a game waterfall style: Lay out all the data structures Build methods which manipulate those structures (think getters and setters) Then build machinery which operates upon those structures using those methods, like game loops, cooldown timers, and status effects Then develop a way to present it to the player using UIs, visuals and graphics, narratives, sound, all that junk that's probably someone else's job anyway ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧════════════════════════════════════════════════════───────────────────────┘ --- #2 fediverse/3037 --- ═══════════════════════════════════════════════════════──────────────────────────── @user-570 have you ever wanted to design your own MMO? If you think you can make a client, there's a server already set up which interfaces with World of Warcraft. So... the hardest part is done, and suddenly the rest is about as hard as making any other game. The reason I ask is because there's no open-source client for the WoW engine server software Azerothcore, but if written then there could be a whole new field of indie design as solo developers would be able to build their own multiplayer games with ease. well, as easy as making a game in Godot at least. That's the dream. I don't think I could build such an engine, but I spend an awful lot of time thinking about how engines are built. There's a lot of freedom in the design space, for example this mod server I made which emulates Risk of Rain: https://www.youtube.com/watch?v=6HsW4g2ZIgk It has randomized enemies, treasure chests, wandering vendors, and deployable hearthstones. If you've played WoW that stuff might ring a bell, otherwise it's probably just random features ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧════════════════════════════════════════════════───────────────────────────┘ --- #3 fediverse/3034 --- ═══════════════════════════════════════════════════════──────────────────────────── @user-570 I've messed around with Bevy and the library most similar in C is Raylib. in Lua it'd be Love2D I think. I love the idea of those systems. I haven't built a full game using them but I can conceptualize operations within them easier using a framework like that versus a game engine like Godot. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧════════════════════════════════════════════════───────────────────────────┘ --- #4 fediverse/4877 --- ════════════════════════════════════════════════════════════════─────────────────── you can make a functional prototype for almost any game in Warcraft 3's map editor that's why no real-time strategy game ever made an editor as good again FPS editors peaked at Unreal Tournament 2004 imho RPGmaker eliminated a whole class of game design jobs platformers you can make in godot menu based games too, though Twine also works well for that etc etc until you have a prdouct that you can justify sinking money into an engine for (the engine isn't THAT expensive geez and it's the most fun part to write) yeah I think you got this backwards, we should pay for the CONTENT not the structure it lives in. Why not just use godot? why not use a Warcraft 3 map? there are some things you can't do in Warcraft 3. You couldn't make Supreme Commander, probably, at least it wouldn't be as good. etc etc that's how it goes... game design, amiright? I miss thinking about that. Anyway gtg gotta log off for a bit [101 characters remaining] ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═════════════════════════════════════════════════════════──────────────────┘ --- #5 notes/how-to-ai --- ═════════════════════════────────────────────────────────────────────────────────── first you gotta build an entire simulation of the game mechanics. Essentially, building the game from scratch without any of the graphics. Sorta like those aimbot games for Overwatch, or KSU or w/e the aim training game was. Then, map the relationship between various objects in the game to a table situated a level above them. So, like, a barrel can be climbed on or walls can be used as cover or w/e the game you're playing is. Have a table one level above that relationship (an abstraction, if you will) and record the conclusion. Then take one more step back, then another, and another, all the way to the present. Essentially, processing backward. Eventually you'll get to the present moment, and ideally you'd do it in one step - this is why it's important to map things on two dimensional planes, so that you can aim. Anyway here's the steps: 1. recognize the environment, 2. Take one step backward from each object in the environment (predicting it's motion, you might say) and on and on gathering ideas about how git'll move next. Draw a 2d line (on a map, as the crow flies) then another about halfway to the target and it'll be +/- a certain amount. So you'll add another dot on the graphed line at x=(1/2 of the distance) - x being of course the distance and y being concieved of as the distance from the shortest possible route. sorta like throwing a ball at a wall and making ripples. the projected cone is a field of perception - the interpretation of what's at stake. Life, and existence, is little more than a perspective applied on (or by ) a biological machine. What separates the man from the animal? Nothing but time, as all evolution teaches us. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧══════════════════─────────────────────────────────────────────────────────┘ --- #6 fediverse/1602 --- ╔═══════════════════════════════════════════════════───────────────────────────────┐ ║ @user-1037 │ ║ │ ║ those all seem really cool though! They all kinda have the same basic UI tho, │ ║ kinda feel like there's opportunities for different kinds of expression. Like, │ ║ in game design there's a lot of different genres, and yeah sidescrollers │ ║ include mario and sonic but they're both very different experiences. So too │ ║ perhaps could we interact with our computers by programming them in more │ ║ engaging ways. │ ║ │ ║ they say some people are visual learners, others need to be taught, some │ ║ people need to watch someone else doing it, and a few might just learn by │ ║ plugging their brains into a computer and downloading a black belt in kung fu. │ ║ │ ║ Maybe typing long paragraphs of logic makes sense for some people, I know for │ ║ most it doesn't come naturally. Maybe some people are more used to like, │ ║ looking at maps that you can examine at different levels of abstraction. Like │ ║ players who play Paradox games zooming from a national perspective to states │ ║ and individuals and all the other things they might want to strategize using. │ ║ Or m │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧════════════════════════════════════════────────────────────┴──────────┘ --- #7 fediverse/281 --- ╔═══════════════════════════════════════════───────────────────────────────────────┐ ║ ┌─────────────────────────────┐ │ ║ │ CW: cursed-game-engine-idea │ │ ║ └─────────────────────────────┘ │ ║ │ ║ │ ║ a game engine which won't let you import custom assets unless you complete a │ ║ few simple tasks using the interface - "build a green capsule collider" "make │ ║ this soldier unit shoot three bullets per shot" or "enable the automatic linux │ ║ support" - using the interface, writing some code, and changing configurations. │ ║ │ ║ why would anyone do this? well it could be useful to increase the difficulty │ ║ of importing external resources. plus it helps the user learn a bit over time, │ ║ and it slows the pace of output such that the user's skills are encouraged as │ ║ the output of the programming and not the program itself. │ ║ │ ║ an inverse curse (an evil one) would be where the requirements to complete │ ║ basic tasks are hidden behind unapplicable skills. like, do you know exactly │ ║ which buttons to press? engage with the skinner box, please. yes yes this is │ ║ what we need - unintuitive software that completely disarms the populace from │ ║ using them! suddenly they're worthless, and can't do anything on any surface. │ ║ it sucks │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧════════════════════════════════────────────────────────────┴──────────┘ --- #8 notes/joust-gdd-with-extras --- ════════════════════════════─────────────────────────────────────────────────────── imagine a game where you can have conversations with an AI that's playing the role of a character in a video game. Picture this: You're a traveller visiting the tournament that's in town. There's jousting, melee duels, archery contests, all kinds of things that are just fun to play around doing. The earliest sports, if you will. Anyway the whole game is about talking to the other people there - basically the games are "playing in the background", and while you can compete in them it's not the bulk of the game. Most of it is just having a conversation with an AI and acting it out *like a roleplaying game*. O M G teach people to roleplay the way you play games! You're always going on about how "different" your way of gaming is than other people. So *show us* how you do it, how do you play? Like what are the fundamental, actual, steps that you take? You can show us by programming a game that inspires that playstyle. That's what game design is all about, finding creative ways to think. Well, think and act. But still. anyway, so you know what you're about? Good. Let's go. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═════════════════════──────────────────────────────────────────────────────┘ --- #9 notes/joust --- ════════════════════════════─────────────────────────────────────────────────────── imagine a game where you can have conversations with an AI that's playing the role of a character in a video game. Picture this: You're a traveller visiting the tournament that's in town. There's jousting, melee duels, archery contests, all kinds of things that are just fun to play around doing. The earliest sports, if you will. Anyway the whole game is about talking to the other people there - basically the games are "playing in the background", and while you can compete in them it's not the bulk of the game. Most of it is just having a conversation with an AI and acting it out *like a roleplaying game*. O M G teach people to roleplay the way you play games! You're always going on about how "different" your way of gaming is than other people. So *show us* how you do it, how do you play? Like what are the fundamental, actual, steps that you take? You can show us by programming a game that inspires that playstyle. That's what game design is all about, finding creative ways to think. Well, think and act. But still. anyway, so you know what you're about? Good. Let's go. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═════════════════════──────────────────────────────────────────────────────┘ --- #10 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 │ ╘═════════╧╧═════════════════════════════════════════════════════════════──────────────┘ --- #11 fediverse/240 --- ╔═══════════════════════════════════════════───────────────────────────────────────┐ ║ ┌──────────────────────┐ │ ║ │ CW: game-design │ │ ║ └──────────────────────┘ │ ║ │ ║ │ ║ i like to design games. my darling is a game based on Majesty (2000) the │ ║ Fantasy Kingdom Sim. you can think of it like a management strategy game where │ ║ you control the knobs and levers that a fantasy monarch might have - │ ║ allocating funds, placing quest bounties, hiring heroes, and organizing the │ ║ peasantry. the important part is that your units are not controllable - they │ ║ just do their own thing. │ ║ │ ║ unrelated, but I think we should design games as APIs that a user's preferred │ ║ tool could interface with and render as they will. it'd help a lot with │ ║ cross-platform compatibility and would allow people to customize parts of the │ ║ game to their desires. │ ║ │ ║ unrelated, but I think if you could design an AI that could play games │ ║ (perhaps through an API) that it hadn't been trained on, I think you would │ ║ have a pretty convincing argument for abstract "problem solving" capabilities. │ ║ │ ║ unrelated, but games like the one I described are good for situations where │ ║ people don't have to trust their monarch. to it you are AGI │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧════════════════════════════════────────────────────────────┴──────────┘ --- #12 fediverse/2947 --- ╔══════════════════════════════════════════════════════────────────────────────────┐ ║ the downside of Proton and Lutris is now the ONLY games that work on Steam are │ ║ either continually updated (untenable) or playable on Lutris or Proton. Same │ ║ thing with Wine, though there's always at least one decent substitute. │ ║ │ ║ kinda makes me want to write a manager-style program which runs programs using │ ║ whichever version of their git repository would work best for their system / │ ║ configuration / purposes. Idk how I would start working on that though. │ ║ │ ║ I bet you could make one that acted like a shop, but where you didn't charge │ ║ any dollars. You could like... "swipe" through UI options, and pick whichever │ ║ felt most useful for your setup. Like, how some people use i3 and some use dwm │ ║ │ ║ with maybe inspectors that are modeled off of video-game style "options" GUIs │ ║ that mainly correspond to flags on the command/terminal line or compilation │ ║ flags │ ║ │ ║ I feel like that kind of abstraction would make it a lot easier for users to │ ║ adjust their system. they're noobs, after all. gotta show them all the choices │ ║ in one place... │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧═══════════════════════════════════════════─────────────────┴──────────┘ --- #13 fediverse/5405 --- ══════════════════════════════════════════════════════════════════════───────────── can't stop thinking about a visual programming editor that can be interacted with in the same way that people are used to (think chromebooks dragging and dropping icons in a web UI) but produces a text-file full of code and all the required compilation scripts for any language the user requires... seriously, programming is not THAT different between the different languages. especially the main ones. they're all essentially variables and function calls at the end of the day, so why not abstract away all the extra details and build something that n00bz can actually use to build things. I technically could make this but I don't have the bandwidth and I don't think it's important really? who can say, the tools tend to co-create the solutions in my experience. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═══════════════════════════════════════════════════════════════────────────┘ --- #14 fediverse/4880 --- ════════════════════════════════════════════════════════════════─────────────────── I remember being a game design student before "indie games" were a real thing they were like... flash games, y'know. just like, junk content, like memes or whatever. I had a passion for them, and I bookmarked the most well developed of them all. I probably played hundreds of games, no clue how many. Maybe even thousands, I did it for what felt like years. since like... age 7 until 11 or 12 there's nothing that can compare to it today. maybe itch.io but they're more involved typically. increases the barrier to enter, plus they cost dollars. we used to make this stuff in our spare time. where did all our spare time go? ah, right, that's what happens when you actually invest in computer education. you have kids running linux on their laptops. you get flash game designers. you get soldering junkies and electric engineers and networking and dev-ops security system facilitators and various other computer related things besides. ... what was I saying? oh yes when you invest in education, there's more to se ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═════════════════════════════════════════════════════════──────────────────┘ --- #15 fediverse/6015 --- ══════════════════════════════════════════════════════════════════════════───────── ┌──────────────────────┐ │ CW: AI-mentioned │ └──────────────────────┘ In 2025, if you want to create a piece of software your options are to either: devote your life to it, or use AI to build a semi-working prototype that you can use to pitch your idea to a bunch of people who have devoted their lives to learning how to use your idea as documentation while they build it from scratch, throwing out most of the code but keeping all the checklists and progress-trackers you built along the way, perhaps even utilizing some of your tooling that you used while constructing the scaffolding of this monstrous application that you won't be using most of the source-code for. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═══════════════════════════════════════════════════════════════════────────┘ --- #16 fediverse/940 --- ═══════════════════════════════════════════════──────────────────────────────────── @user-652 just made a game for GGJ in Godot and I have to agree. Godot is so frustrating, but one thing I have to concede is that once you get your head around it the GUI part is actually incredibly powerful. My next game I'm going to make in Raylib, and if the UI bit proves too difficult I'll probably end up back at Godot. ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧════════════════════════════════════════───────────────────────────────────┘ --- #17 fediverse/982 --- ═══════════════════════════════════════════════──────────────────────────────────── @user-707 @user-708 using this to control the buttons in VRchat would be like a person with a prosthetic interacting with real life :O minus the physicality of course, but that's next. can't wait to play Warcraft 3 and think "select all healers" so I can point them at a dying unit with my mouse. or world of warcraft where your rotation begins to feel like a song. maybe even a text-based adventure, where you reading the text corresponds to the results of the simulation, https://www.spreeder.com/app.php style. could make it so that if you wanted something else to happen, you had to willfully think it while the words are flashing in front of your eyes - the game would pause if you blinked, perfect for phones btw... could be a locally networked thing, like four to six people hanging out and playing a game like pictionary or charades. except, a story that developed, and whoever wanted could change it while everyone was reading it at once. sorta like a competition to see who can make the best twists and false endings ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧════════════════════════════════════════───────────────────────────────────┘ --- #18 fediverse/6251 --- ╔════════════════════════════════════════════════════════════════════════════──────┐ ║ "Hi computer, all is well. Can you create me a visualization of this │ ║ particular mathematical concept? It should be written in Lua using the Love2D │ ║ engine because that's my favorite. I should be able to step through the │ ║ calculation steps and modify values at each stage, and by the end we should │ ║ have a fully interactable system which works through the general concepts of │ ║ this particular kind of math." │ ║ │ ║ "no no I don't want you to explain it to me, I want a tool - a toy - that I │ ║ can play with to better understand it. Let's build it in Lua using the Love2D │ ║ engine because that's my favorite. When we're done we can start converting it │ ║ to use HTML5 - no javascript! - but for now let's get the system operational. │ ║ It should have a config file that can be adjusted with every value we can │ ║ think of." │ ║ │ ║ "can you go through this fully functional system and extract as many values as │ ║ you can think of into a config file? make sure there's efficient loading of │ ║ those values in the main function (or somewhere similar) as well. ty" │ ╟─────────┐ ┌───────────┤ ║ similar │ chronological │ different │ ╚═════════╧════════════════════════════════════════════════════════════╧════──────┘ --- #19 notes/coh-waves-of-playerbases --- ══════════════════════════════════════════════════════════───────────────────────── imagine if there was a stacking inf bonus to players who played on red / blueside which increased or decreased depending on either A. the number of players online at the time, B. the proportion of players playing on that team versus the other, or C. the time of day. Essentially helping to cure the faction imbalance by offering rewards to one side or the other which would encourage a certain group in the population of the game to change sides or not. perhaps frequent changing could grant a title called "mercenary" or something like "log in for each consecutive day for 10 days straight and each day switch faction alignment at least once" ... anyway you could cure the faction imbalance between redside / blueside by offering an INF reward for playing on each side one by one alternating like an iterator first red then blue or first blue then red either way it doesn't matter because it'll switch after a while and encourage everyone to switch sides. And the way the character responds to that stimulus tells you a bit about their character's personality. also... it should not affect AE or Pocket D farms. Nor missions, TFs, or anything else. they should SOLELY impact open world patrolling / hunting. I believe this would not only incentivize people to spend time in the open world (which is a mostly unused piece of game assets) but it would also increase the visibility of the newly bolstered faction numbers. Think about it - if everyone who switched sides is out in the open world, then they could see each other. They could fight the same mobs, and team up together. In doing so, they could form greater and greater supergroups - if only through their interactions with one another as they level up. If they're lucky, the guild they're recruited into has similar interests in mind like doing raiding or PvP or economics or alts or whatever. And they each have their own different styles of operating, it's soooo cute. Like alt guilds will pop up and then migrate to a new one as people make new alts and grow tired of them at higher levels. It's great. I love MMOs! I wish people put half as much effort into making an open source WoW client that they do programming game engines like Godot or Raylib or Bevy. If such a thing was created, we could have a new rennaisance in indie MMO development. It would become fully non-proprietary, the entire game-platform-stack. Meaning anyone could create their own MMO off of it, because (crucially) the serverside soft- -ware has already been reverse engineered. And open sourced. Seriously. You wanna make as much bank as Steam? Make an open source client that lets you design while in it. Then you could charge people for all the games that they played that were designed and hosted by you the content designing software maker. ... okay it's probably not that simple I'm going to go play Unreal Tournament2k4 ` ┌─────────┐ ┌───────────┐ │ similar │ chronological │ different │ ╘═════════╧╧═══════════════════════════════════════════════════────────────────────────┘ --- #20 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 │ ╘═════════╧╧═════════──────────────────────────────────────────────────────────────────┘ |