If you solve the performance, you will be very close to a great game.
But you still have to face five other Boss: gameplay, level design, narrative, music and sounds.
And the last Big Boss: marketing.
That is why it is important do not leave this to the end, and already start gathering the army.
The game's narrative is something I have in the back of my mind, but I haven't fleshed out the details yet. In typical MUD fashion, all objects have descriptions, which can be used to help tell the story. I wrote up a few when I was testing the inventory system. Some of the objects are more telling of what has occurred in the temple, before Marika's arrival, than others. A couple of drafts:
There's not much room for text, which is probably a good thing in the long run. I have to think about what is the most important feature of any object and describe that. One thing I haven't settled on yet is what perspective--the player's, or Marika's, the descriptions should be written in. The latter is more interesting to me, since deciding on what things she'll notice is a good opportunity to build up her character. But this approach can also be restrictive. At the moment I have a mix. Inventory cards (like the two above) are not in the perspective of any characters. Marika can talk to the player through the status bar at the bottom of the screen. But I'm leaning toward moving to entirely third person limited.
MUDs and other text-based adventure games often have text descriptions of rooms and NPCs as well. I probably won't go that far. When would the player have a chance to sit down and study an NPC? While Marika may make the occasional comment when walking into a room, rooms are large enough to show important objects graphically.
I'm taking the novelist's approach to level design--getting something down as a rough draft and revise it later. One thing that often plagues new writers is the idea that the first draft has to be written well. Get your ideas down first, then revise. From the programmer's point of view, this means I need to have good tools to build, analyze, and rewrite levels. I haven't finished my toolset yet, but it's coming along. This is where the b2vec issue has slowed me down.
Speaking of which, I worked out a nice solution to the other half of the raycast problem: Bresenham's Line Algorithm (or rather, a variant that ensures all grid points touched by a line are marked).
I never knew the name of this algorithm until now. If you didn't either, you probably will recognize the use--mapping a line to pixels.
But you can use it to implement tile-based raycasting. Check all the tiles along the highlighted line. If any are walls, then the two endpoints cannot see each other. Coupled with the line intersection algorithm, you can also compute the exact point the line strikes a wall at.
Written in a C-like fashion with only data primitives, there should be no b2vec garbage left behind to collect.