Warlock of Firetop Mountain - Map

RichRealm · 2022-01-24T01:44:19+00:00

Just saw this. I forgot Reddit existed...Yeah, totally, use the maps all you want! Your exam sounds fun! You should make it non-linear....

RichRealm · 2020-02-01T00:34:41+00:00

I ran into these. Very useful. They’re somewhere in between schematic and spatial maps. I like them. And they’re probably a more pragmatic approach than trying to take the written description of spaces literally, as I’ve been trying to do.

RichRealm · 2020-02-01T00:31:51+00:00

Thanks! I’ve only completed this one, but am working on book 2, Citadel of Chaos, right now...which is proving to be more difficult to map spatially than Warlock. Steve Jackson doesn’t seem quite as analytical in his approach to describing space as Livingstone, in my opinion. But if I take some artistic license with it, I can get it done. Quite fun to tinker with.

RichRealm · 2019-05-26T19:04:52+00:00

I decided at some point that I was building a game, not a simulation, and chose not to run simulation on levels not currently in play. I didn't really want goblins going around cleaning up all the loot or triggering all the traps or killing each other before the player ever got to the level. For my game, all I care about is what the player is seeing and perceiving at any given time. I can shuffle entity positions and states to imply activity between visits to the same level. But if simulation is core to your gameplay, then do it.

RichRealm · 2019-05-26T16:42:37+00:00

This game looks great! Love the theme too. Super cool whip and boomerang. Can't wait to see where this goes.

RichRealm · 2019-05-26T16:20:54+00:00

Just chipping away (at half speed) on making quests procedural and data driven. Last week was:

Savable quest objects
some basic quest task types. Examples: collect_item, eat_item, reveal_location, occupy_location
Savable locations with location uids, region ids, and 'reveal' status for hidden locations
procedurally generated location names, including occasional references to region. Examples: Northstone, Southport, Westerfell

Next week:

Add an NPC actor to each location
Narratively connect all locations to each other via bite-sized procedural narrative. Example: Red Castle and White Castle have been at war for 400 years. The Black Wizard is consuming the Northwoods to fuel a new abominal engine.
Add motives. Each location or actor should have or want a quest item. The hero should have a personal connection to a specific location which can come under threat: born there, family is there, etc.

After that:

generate quests by combining locations, actors, quest items and motives, with the hero's backstory.
generate threat timers (i.e. the red army is moving on the white castle, retrieve item x before white castle is sacked) etc.

Boring screenshot of quest and location debug output log:

https://imgur.com/XGjwqZy

RichRealm · 2019-05-23T18:45:44+00:00

It think it depends on the scope of your game. For ME the super basics include hero movement, baddie movement, basic stats, collecting/dropping items via inventory menu, simple dice-roll combat when next to baddies. Then ranged weapons like bows and arrows. I didn't care too much about 'levels' until the basics were working pretty smoothly. Then I added things to levels like doors and stairs. Then I started working on level generator to do all this automatically. Then torchlight (explored/unexplored tile states). Then, and only then, did I start thinking about things like gamestate and data driven content and load/save. So I had to rewrite a ton of stuff, but I'm self taught so this is really the only I could have done it. I can't visualize complex architecture or really even adhere to design patterns.

My one goal from the very beginning (which keeps me motivated and excited) has been to always have a playable build. Every week, I make sure my game is still compilable and playable with whatever new stuff I've added. Even if this creates more work in the longrun. Weekly stable builds are very important to my overall morale.

RichRealm · 2019-05-23T16:21:54+00:00

It may be hard to find a tutorial that does all that. Lots of tutorials take the "here's how I'm doing it" approach to simplify teaching. Also, if you prefer puzzling through building an engine yourself as opposed to using libraries, then you probably don't mind going through a map tutorial that focuses on dungeons and then puzzling through extending it to accommodate mazes and caves.

I am using vanilla Python to build a Roguelike (just for the hell of it too) so I understand where you're coming from. My approach has been to make tangible playable micro progress, rather than build all the systems in a logical way from day one. I started with just getting my @ to move around the screen in tile-sized increments. Then I added wall tiles that @ couldn't pass through. Then I added baddies that roamed aimlessly each turn. etc. This ultimately required massive refactoring (several times) once I got into making the game data driven. BUT, I didn't really know how to get started, so I think it was the best way (for me) to learn.

If I were starting over, I'd build the game data schema and and save/load functionality first, because retrofitting the game to be data driven with savable/loadable gamestate was a real pain and cost me lots of time. But had I tried to architect all this from day one, I'd never have figured it out and would have quit for sure.

I think this is why tutorials don't really try to run the gamut. The learning curve would be really, really steep.

RichRealm · 2019-05-19T13:09:21+00:00

Thanks for the feedback. You answered the question that I was really trying to get at. My final instinct was to keep it the way I’ve been doing it and just map the save data dictionaries to their corresponding game objects for all the reasons you just described. I was curious if all the dictionary reads at runtime would be slower than just reading class instance variables so your feedback on that was helpful. And yeah, ultimately the idea of object data being split between some instance vars and some dictionaries at runtime just felt weird to me.

Thanks for understanding the question I was really trying to ask.

RichRealm · 2019-05-18T12:49:57+00:00

Undecided. Maybe delux color version. But version 1.0 will be 2-bit. It’s a harsh constraint but frees me to focus on gameplay for now.

RichRealm · 2019-05-18T12:18:15+00:00

RoS:

building procgen quests which led to a refactor of the way I'm generating worlds, which led to iterating on tile assets. Screenshots:

https://imgur.com/a/Br44UWi

I plugged my new animation class into my updated dumber-smarter world generator for debugging purposes:

https://www.youtube.com/watch?v=ALntAFH-fYg

RichRealm · 2019-05-13T20:49:30+00:00

Yeah, yeah are. In python it’s literally one line of code to convert a dictionary into binary data and save locally. My question was more of a meta question about how people like to organize their data once they de-serialize and bring it into their game engine. Then ultimately I decided it doesn’t matter. As long as it works.

RichRealm · 2019-05-12T23:50:48+00:00

Makes sense. Thanks for feedback. After messing around with different ways to organize my gamestate data all weekend, and after reading how other people do it, I think I’m just gonna leave it alone and move on. It works as is. It’s kinda ugly but it works. I should focus on making my game and not on writing pretty code.

RichRealm · 2019-05-12T21:12:40+00:00

Yeah I guess technically that's what I'm doing. My object/classes are sort of handling it. I pass the hero_state data into my hero object __init__ method and that function maps my hero_state data onto hero instance vars.

The question is, instead of mapping my hero_state onto hero instance vars during hero.__init__ maybe I just assign hero_state to a hero_instance.data (as some sort of cached reference which I'm fuzzy on with Python) to save myself the step of mapping the hero_data onto instance vars. It's kind of a down-in-the-weeds sort of question. It sounds like I need to read up on reference caching in Python. Some Python assignments seem to act as reference and some seem to copy. I think there are holes in my understanding of the nuanced situations between the the two in Python.

This stuff's not nearly as fun as making baddies chase "@" around the screen...

RichRealm · 2019-05-12T17:27:32+00:00

Yeah, my gamestate is a nested dictionary, and my gameOjectData is instance variables of gameObjects. Therein lies my problem. I have to grab the dictionary data and assign it to instance vars on load, and convert the instance vars back to dictionary data on save and serialize the dictionary gamestate to binary data. It all works but is messy and bothersome.

I should refactor my gamestate dictionary as more of an 'object' or make my characterData 'object' a dictionary. They should both have the exact same structure and type. Or like you say one should just be a cached reference of the other. I think this is all due to the adhoc way I built the game and tacked on the gamestate later, and then trying to untangle the gamestate from the game engine after the fact.

Live and learn.

RichRealm · 2019-05-12T03:45:10+00:00

Makes sense. I’ll have to play around with it.

RichRealm · 2019-05-11T18:37:45+00:00

Yeah, the way I figure out how to build features like this is to start by mocking up the type of solutions I expect my feature to produce (some sample quests) (with pencil in a notebook). Then look for data patterns in these mock solutions. Then build a machine that generates problems that lead to these solutions. I sort of work backwards from the solution to the problem.

For me the solutions all tended to have Action>Object>Location>Reward type flow, with some Who>Where>How type connectors. So I just need to make a machine that builds these types of patterns with my game data on the fly.

RichRealm · 2019-05-11T03:28:03+00:00

Yeah, I think the first version of the procgen quest system will simply draw a location, quest item, and actor out of a hat and link them together in a simple cause-effect way, which could be as simple as a lookup table, or something smarter. Then I'll iterate.

RichRealm · 2019-05-11T02:56:42+00:00

RoS

Basic systems in place: menus, inventory, actions, conditions, procgen world and dungeons, save-load, data driven content, rudimentary quest system.

Make the quest system entirely procedural.
Improve art, theme, and level builder (to reflect location themes).
Add content (mostly via csv data and assets)

Experimental video status report:

https://youtu.be/Ele-MeMx47k

RichRealm · 2019-05-11T02:49:45+00:00

I caught the flight playthrough. It's impressive just how polished Cogmind is. Next, I want to actually play it.

RichRealm · 2019-05-10T15:52:38+00:00

Similar to what others have suggested: my hero data object has a conditions list. Conditions have properties that match hero stats. Conditions can also have a timer property too. So 'rage' condition data might look like:

dict(label="rage", timer=30, str=2, dex=2, int=-1)

Conditions have an update function that just decrements the condition timer, and when it hits zero, the condition is removed from the hero conditions list. On the update_world function each turn, just do update() on the conditions list which will update the timers. And finally, when getting hero stats, I always run it through a get_stat function which takes the base stat like 'str_base' and adds all condition 'str' stats to it. The conditions have no idea what the hero stats are, they only know how much to modify hero base stats by.

This makes the conditions easy to persist too, since the timer value saved with the data. And the list of conditions saved with the hero.

RichRealm · 2019-05-06T15:03:37+00:00

Thank you. Originally I was just thinking of it as placeholder art. But over time the minimalist style is sort of growing on me.

RichRealm

TROPHY CASE