AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
Back to Blog
Tinykeep walkthrough1/6/2024 ![]() The thing that caused me the most trouble yesterday was coming up with a scheduler for entity actions/updates. UI is nonexistent and input handling is simplistic for now. It's working for now and I've got characters moving again, but I'll call it placeholder. I also started putting together the entity-component system, but since I have no idea what it really ought to look like, I don't know whether I've created some kind of abomination. I improved the way terrain variation was implemented, and based it on a hash function as mentioned before. It can run several iterations on the current map size in tens of milliseconds, much better than the couple of seconds it took before. I've reworked map handling to use numpy, which substantially increased the speed of the dungeon generation algorithm. Maybe once I'm done with my ideas for the roguelike. After hearing about Clojure's advantages here, I'm more motivated to finally look into it now. I can reload changed modules, but it won't update existing objects. Unfortunately Python doesn't have enough support for full live-coding. I've managed to put together a couple of nice debug mechanisms and visualization functions, which should help with future complications. Being able to inspect and modify the game's map structure and other data makes it much easier to follow what the map generation process is doing. Did a little research, and found out how to spawn an IPython console in a separate thread, with access to the game's internal state. In the last day and a half, I've been able to unravel the nest of patchwork hackery I'd put together and get the program looking sensible again.Īfter initially cleaning up the game loop, I started thinking about the possibility of live-coding. I think it helped that, after cutting out each piece, being able to focus on returning the program to a working state kept me on track. ![]() Once I got into it, it became surprisingly easy to progress. I began rewriting the game in-place, tearing open the code and extracting it into neater compartments. That's somewhat easier to make visible progress on with theĬurrent state of the game. Maybe wilderness or town maps as I mentionedīefore. I may also look at increasing terrain complexity, creating more To rewrite some of the drawing and update routines. Making the maps larger is very costly and I'll have I haven't actually set up an event system, so inter-object communication Interesting I'd have to implement it to understand what it actually There are also field-of-view and line-of-sight algorithms. What I've got right now is an infinite world, I just found thisĪpproach to roguelike game structure. Get started on, and they don't need particularly intelligent behavior. I wanted to prototypeĬommunication/interaction systems, but combat systems will be easier to Useful behavior for NPCs requires giving meaning to spaces in the world,Īnd that might take a while to figure out. I could try spawning creaturesĪnd giving them basic behaviors. I've been struggling with designingĪ world model for the game, to abstract away the individual maps andĪs for what I might work on next. I'm intending to redesign it for smooth scrolling,īut that's been more of a challenge. Viewport concept, rendering a map per screen and switching maps when you ![]() Smoothing phase of the generation algorithm. It looks really good to me, and theĮrrors are likely just because I cut a couple of corners in the It took about 16 hours, but I managed to stitch multiple maps together On whether I'd be able to find the right abstraction to limit that. In the end, scrolling might be something that's better off dropped,īecause it substantially complicates many parts of the game. I likely won't be able to manage that before Same time I should think about reducing the amount of unnecessary workĭone on each frame. There are a lot ofĭesign issues to work out before that can happen properly, and at the ![]() Too much of it is based onĪssumptions about the screen being a single map. I'll need to do another rewrite soon, because the code is not at allĭesigned to handle a scrolling viewport. Performance consequences of something like this, and performance is Game's components and systems with each other. For events, I was thinking of using publish/subscribe to connect the
0 Comments
Read More
Leave a Reply. |