This topic contains 5 replies, has 1 voice, and was last updated by 
josh November 7, 2020 at 10:38 pm.
-
Posts
-
joshAn idea for a starting research step: TuxRacer is/was an open source OpenGL Linux game. I believe it was generated from 3D models. If so, 3D graphics in the code is ez to localize. But for research, one could pretend that you only get examples of 2D sequences & have to put together a 3D model from the examples prior to modifying it. In this case, it should be ez to plug the modified model into a working version of the code to evaluate the progress of various algorithmic steps.
-
joshThe kluge like limitations of TuxRacer at the edge of its model is an example of a real-world game approximation to taper off the limits of its representation. In practice, there will be a catalog of such things found in non-VR games. Degree of automation in creating Stage 2 will depend on the ability to handle those with some kind of substitution [category: edge of map kluge; spec example: sticky snow bank]
-
joshA key point about having access to original source code is that many, many runs of gameplay can be generated algorithmically. An AI’s version of constraining game play in the new model & relaxing that where it is seen as unnecessary & undesirable doesn’t need to look anything like the original implementation of the kluge.
-
-
joshI thought of Pacman as a good negative example -there are no 3D clues, but even if some pretty 3D thing was derived, it’s hard to see how the original game extends beyond 2D. The gameplay itself is premised on a 2D view.
-
joshI can a different game with 3D mazes that can be shown in translucent views with game “cheats” that describe the shape of paths to goals & the paths of approaching enemies. But imagining gameplay, it seems that the more 3D it becomes, the less it has to do with the 2D maze “inspiration” – it’s just a completely different runner game.
-
-
You must be logged in to reply to this topic.