first timer to a 48hr compo, post-mortem of COMPLICATED VIEW
That was fun. And stressing.
I didn’t get my entry finished to the state I had hoped but submitted it anyway within the final minutes, since I think the visual puzzle aspect is interesting enough to play with.
click to view: http://www.ludumdare.com/compo/ludum-dare-19/?action=rate&uid=3278
Right away I seriously underestimated the time constraints, I started working on my entry Saturday afternoon (about 18 hours in?). I had a rough idea of what I wanted to create but I hadn’t done any work identifying individual systems I’d have to script or how it would all work together.
the bare minimum brainstorm
I basically jumped right in and started sorting out how I was going to create the visual effect that I was after, sort of a reverse camera-mapping effect but with geometry instead of texture mapping. I needed to take a plane which had been cut into fragments of various sizes and translate the fragments outward towards the camera at random lengths, but while scaling the fragments in size so that when the viewer looks from the camera’s position they see the plane as if it were solid. I had made failed attempts at this effect in the past so I had some existing knowledge about what was involved, but the difficulty in this was making it work for a specific viewpoint. A few hours were spent of trial-and-error, all sorts of debugging lines being drawn between points in space so that I could compare results and figure out what I needed. It turned out to be simpler than what I thought when approaching it, but it still was straining on my poor and forgotten math knowledge. There very well could be an even easier elegant way out there involving matrix transformations and stuff.
finding a key view position
I soon noticed that using a “raw” X Y mouselook for the player camera was too harsh, it seemed to reduce the impact and readability of the visual effect, so I began looking into lerping the camera. It helps a lot, and as a bonus makes input with a laptop track pad work great.
Soon after getting that working I descended blindly into an unexpected Quaternion hell where I also attempted to blend the player camera towards the “key” camera rotation when the Player was very near the correct position and rotation, as a way to assist in snapping to the perspective that solves a wall. I spent too much time on it and didn’t get it working right in the end, all I know is Quaternions have 4 dimensions and are inside The Matrix, instead I just opted to count a wall as solved when within X amount of the key position and rotation. This leads to some problems where the Player never sees the wall fragments fully give the illusion of forming the wall, instead there are small gaps. Thinking about it now however, I could probably just take control of the Player’s camera during the solved method and blend it to the correct view, creating a transition that feels smooth and provides feedback that the Player has just solved a puzzle, rather than immediately popping in the new room (as it does currently) which is jarring.
The next problem to tackle was creating a system to handle randomly placing the “key viewpoint” for each of the 4 walls, and handling the creation and removal of rooms. By this point I had started working again Sunday morning and since I’d not planned out any order, my scripting began turning into spaghetti-mess with all sorts of back and forth checks, I was basically improvising everything as I went along. There are some issues with the random placement at times, sometimes the fragments “spill over” behind the key viewpoint which means they won’t be in view for the player, so the player will see missing fragments (holes) in the wall when solving.
Next was the addition of enemies, the intent was to have enemies gradually spawning in from beyond the current room, slowly encroaching on the Player’s position in a way which would cause the Player’s tension to rise as they searched for a key to the next room. Finding a key viewpoint would cause all enemies inside the current room to be destroyed, and the idea is that the speed and number of enemies would slowly increase the further along the Player progressed. Destroyed enemies would build up some sort of panic device which when activated, destroys all enemies in a radius around the Player, but potentially has some negative effects (maybe a temporary boost to the number of enemies spawning and a re-shuffle of the current wall solutions).
I didn’t get to that point, as the enemies were being added with about 2 or 3 hours remaining, and I spent the last moments generating some materials and colors to help give the entry a weird and potentially unique look.
Some of my disappointments with this entry are not putting in a placeholder title screen/state right from the start, along with a game over state, all future experiments will have that framework in place, as easy it may be to do, when you’re under pressure of a deadline it is very easy to disregard simple things that could assist in making your entry appear a bit more coherent. I also really wanted to get audio in, as it would have added a lot to the experience, looking back, I probably should have set aside the enemy stuff in favor of adding audio as the enemies are not very incorporated into the entry.
well, that’s about it, if you’re reading this I hope you found my entry somewhat interesting, I look forward to playing through the other entries and the future Ludum Dare compos to come! I think I’ve learned a lot from doing this 