It's interesting. The algorithm the author is trying is of a kind I have tried and, I believe, a mistake.
If you are building a roguelike, just have a sentinel list of entities. That is, do not try to break the level up into a 2d array of containers. Just have a ring, each entity having coordinates, and iterate through it as you need.
If you want to have an ai occupy multiple spaces, have that. Have an 'avatar' ai object own one-to-many (plotable) entities.
The mighty Jeff Lait gave me this insight in a code review. I believe he added, "premature optimisation is the root of all evil." I.e. be happy to iterate through linked lists until you are sure it is a problem.
Thanks for taking the time to respond to the way it's currently done.
The diagrams can give a slightly wrong impression and it looks like I've communicated the actual behaviour poorly because it works very much like you've described; there are not several objects occupying separate tiles that move in a synchronised way (so the troubles described by zenojevski are not applicable here). The constituents have no self-awareness and store nothing but their own appearance. They come in and out of existence as the object moves and are mere "markers"; they can't be interacted with but instead refer interaction to the object itself.
In that sense, it very much does consist of an 'avatar' ai object with several plotable entities except that the avatar object itself acts as one of the entities while the rest are kinda 'hollow'.
The objects are stored in their locations so this method of spreading them across tiles makes the most sense and you're probably right to be critical of this approach however it reflects reality and part of my objective is to make a program that my friends can contribute to as they learn code themselves and the easiest concepts to grasp are those that reflect reality rather than more abstract ones.
Also it hasn't presented any problems so far so I'd rather work with it than around it.
I hope I've understood and addressed what you're saying. Thanks for checking it out.
First off, I'm aware of HN but I've never browsed or used HN before. This is my first post and I've had a quick look over the guidelines but I apologise in advance if I violate any established decorum.
The blog linked here by a friend of mine is indeed the full extend of Asciilands' current online presence. The game still has a long way to go as you might be able to tell by the fact that I'm blogging about fairly foundation features like the combat system etc. The first post on the blog talks about why I'm making it; basically to give back to the freeware community and to "make the game you want to play but can't because it doesn't exist".
The blog itself is something I do to keep a log of the development for historical interest once its finished and also to build something of a port-folio piece; code samples are great but a dev blog goes so much deeper. I also just enjoy doing it.
The blog, so far, has really only been read by a few of my friends, some people I studied with a few co-workers so I'm glad to see it has some appeal to people outside of those circles.
I'm happy to answer any questions and accept any feedback you might have on the blog or the project.
Thanks for your interest!
That's a very old video of some of the earliest test content in the game but it gives and idea. It was basiclaly made as soon as things started moving. I've got a more recent video on the Asciilands facebook page and hopefully video content will start making its way onto the blog soon.
Glad you like the visuals, the appeal is very esoteric but I'm sure there's enough fans of ascii stuff out there to make it work.
The first two games in the XCOM series, UFO: Enemy unknown and Terror from the deep ([1] and [2], but you can't not know them) use the same kind of layout. Unfortunately this gave rise to a series of issues, largely for the same reason that you wrote about[3]:
> If you mind control them, you'll mind control only one square which will become hostile against other parts of the alien and may even attempt to attack them via reaction fire. Control all four sections, and they'll not try to shoot themselves.
There is more, mainly caused by the "fixes" to other bugs, and frankly on the whole the results are quite hilarious. I guess that you should really really cover every corner for this to work well.
Weird, they color the word asciilands but don't link it anywhere. Couldn't figure out how to actually play. A Google search just gives the blog, which just seems to have dev entries.
This is correct; public release is a long way off and features are blogged about more or less as they are developed so the foundation level of the features described by the blog is indicative of the development progress.
If you are building a roguelike, just have a sentinel list of entities. That is, do not try to break the level up into a 2d array of containers. Just have a ring, each entity having coordinates, and iterate through it as you need.
If you want to have an ai occupy multiple spaces, have that. Have an 'avatar' ai object own one-to-many (plotable) entities.
The mighty Jeff Lait gave me this insight in a code review. I believe he added, "premature optimisation is the root of all evil." I.e. be happy to iterate through linked lists until you are sure it is a problem.
Check out his game Smart Kobald.