tag:blogger.com,1999:blog-7141432593100470479.post2674955523119185329..comments2014-02-08T17:04:23.690+00:00Comments on The Oblong: ::tap-tap:: Is this thing still on?Snuthttp://www.blogger.com/profile/06737686885066577411noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-7141432593100470479.post-27980575485393787802010-01-15T14:52:44.273+00:002010-01-15T14:52:44.273+00:00Ah! I see what you mean now, sorry.
I don't t...Ah! I see what you mean now, sorry.<br /><br />I don't think it's necessary, however. For one, I'm only intending there to be a few hundred active entities at most. I'm restricted to small levels at the moment due to the time required to generate the terrain mesh, and I was always intending to use relatively few enemies and try to make small-scale combat more interesting. Traversing the list will be a trivial cost, I suspect any bottleneck in this area of the code will stem from the AI generating actions. I'll optimise that bridge when I profile it, to abuse a phrase.<br /><br />For two, the coarse granularity of the system is a benefit in many ways. In order for the simultaneous movement to actually produce interesting gameplay, it has to occur predictably. I think that the concept of 'slow' entities (intrinsically or as a result of temporary effects) only getting to act every other turn is quite transparent. Maybe certain actions could also cause entities to 'skip their next go' in true boardgame tradition. Fast entities can probably just be allowed more exotic movement actions rather than breaking down the turn system further.<br /><br />Although I'm not certain, I think such a simple setup will be sufficient for adding depth without too much complexity, and shouldn't be hard to signal to the player in a clear way.<br /><br />But if it turns out to be too simple a model of time, or I end up dealing with many thousands of entities, I'll definitely need to revise the approach.Snuthttps://www.blogger.com/profile/06737686885066577411noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-25392931799352767862010-01-15T01:15:44.361+00:002010-01-15T01:15:44.361+00:00Snut, if you scan through all entities and skip so...Snut, if you scan through all entities and skip some of them, your running time will be linear in the number of entities, which means that you'll want to either limit the number of entities or the granularity of your time system (which in turn means that everything's going to move at roughly the same speed) lest your system become too slow.<br /><br />I'm suggesting that rather than scan-and-skip, use a "heap queue" or "priority queue" data structure, which will allow you to process only the creatures which actually are scheduled for a turn right now, and totally ignore the others. Not only will you save time by not processing some, but your running time changes from linear to logarithmic, which is a decent savings if you have a lot of entities to process.<br /><br />I don't know what language you're using, so I don't have a suggestion for a library -- but it's a fairly simple data structure.<br /><br />-Wmwtanksleyhttps://www.blogger.com/profile/03283393679440645366noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-1317491427385086812010-01-14T16:17:11.525+00:002010-01-14T16:17:11.525+00:00Hmm, I guess I phrased that badly. Null actions mi...Hmm, I guess I phrased that badly. Null actions might be useful for logging/debugging purposes, but I was thinking of a very simplistic approach - just skipping those entities.<br /><br />entites.filter( e => <br /> currentTurn % e.actionPeriod == 0 )<br /><br />Or something of that ilk. Helpful side-effecting aside, it doesn't really matter if entities emit actions which just behave as the identity, or we skip them entirely.<br /><br />At the moment I don't know how different a 'world state' object will be from a simple interaction graph, but it's an interesting idea. I'm certainly not planning on actually moving anything in the rendered representation until a final valid world state has been decided! That'd be confusing...<br /><br />All that said, I don't have much free time at the moment so the implementation is going slowly. There are probably plenty of things that are going to prove annoying or ugly, and maybe just stating the problem differently will be very helpful.<br /><br />Thanks all!Snuthttps://www.blogger.com/profile/06737686885066577411noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-30933811536683141002010-01-14T06:31:08.955+00:002010-01-14T06:31:08.955+00:00We can allow for slower agents by forcing them to ...<i>We can allow for slower agents by forcing them to take null actions except every N turns.</i><br /><br />Why not slap everything into a priority queue, and then execute the queue up to the first priority change (collecting the resulting interactions into a graph), and then resolving the graph until all conflicts are gone and everything can move?<br /><br />That way nothing actually changes position until all of the conflicts are resolved; and nothing needs to get processed that's not either actively moving OR involved in a conflict with something moving.<br /><br />There's no reason to "execute a null action". Unless that winds up being faster, of course. :-)<br /><br />-Wmwtanksleyhttps://www.blogger.com/profile/03283393679440645366noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-66101568098499067312009-12-29T18:14:58.261+00:002009-12-29T18:14:58.261+00:00I really like this idea! How to represent combat i...I really like this idea! How to represent combat is something I've been struggling with for a while, especially as animation is something I'm really not betting on for first release.<br /><br />This symbolic system sounds far more interesting and easier to 'read' than just sliding some pieces around and doing some damage, and can be elaborated with sound and visual effects easily to make the conflict resolution more interesting if needed.<br /><br />Cheers!Snuthttps://www.blogger.com/profile/06737686885066577411noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-78016938090931138372009-12-28T19:00:48.010+00:002009-12-28T19:00:48.010+00:00Good read! I think you could draw some inspiration...Good read! I think you could draw some inspiration from puzzle games in showing the player the outcome of a turn. RPGs show little floating strings like "*miss*" or "-52" (HP), but in puzzle games there are often symbols such as arrows.<br /><br />For instance, each move could be depicted by an arrow appearing in that direction (or a shield if the actor stands still), and when that results in conflict, the arrow from the losing part will be red and fade away, perhaps even have a cross appear over it. Winning would be green and simple moves could be white or blue. Symbolic depictions like those are IMO much better than the classical message log of RLs, and the floating text/numbers in RPGs!Jotafhttps://www.blogger.com/profile/11804130701206652599noreply@blogger.comtag:blogger.com,1999:blog-7141432593100470479.post-62147537143836937112009-12-22T16:51:55.450+00:002009-12-22T16:51:55.450+00:00good to see youre still making progress. i like re...good to see youre still making progress. i like reading about the technicals behind it, and i hope to see and play a finished product as well someday. looks great!Tim Bolinhttps://www.blogger.com/profile/10287173944450787038noreply@blogger.com