So, something interesting happened while I’m looking into the possibility of recreating pacman within our 2LoC Engine. (BTW I almost missed it, but 2LoC apparently means 2 Lines of Code – which is anything but! Nothing can be done within 2 Lines of Code! Just saying.)
I run in some problems that I’ll be listing below:
- Collision Detection, namely the walls.
- It’s clear that in Pac-Man, the main character cannot go over the walls that’s in the way. It is true that when a direction button is pressed, the character can go straight ahead until another button is pressed. However when it hits a wall, the action stops.
- However, the collision of the walls calls for some effective method. I’m thinking of letting the engine read the color of pixels and when the hitbox of the main character actually hit these specific pixels with this certain color it will count as a collision and stops the motion.
- The more traditional way, is to out the wall parts, define them in the engine, telling the program that the main character cannot intersect with that specific area. However, I could foresee that this will take probably more time than the above method.
- The original game features 4 Ghosts as enemies, each has a different AI Set. There’s 1 randomizer, 1 chaser, 1 wanderer and 1 blocker. Which calls for 4 different set of AIs. However in our scenario, we’ll only work starting from 1 set of AI, that’s the chaser.
- The core mechanic for the chaser AI is that the position of the main character is continuously tracked through moving, and the position of the main character is then used by the program to decide where this chaser AI can move. The chaser AI will always move towards the nearest route, which could be easily calculated on paper, but to actually calculate them into the engine would be harder than it looks.
- The easiest AI to make would be the randomizer AI of course.
- There are two bonuses in this game.
- Power Pellet, which changes the AI to some sort of an Anti-Chaser because from then on during a set time the AI will actively avoid the player. Which will be easy to make once the AI is sorted out.
- Cherry, an item that spawns after a set time that simply provide points. Now there’s a problem regarding the tracking of the time. In the original game it seems a cherry spawns once within 2 minutes. However that means the time that the game is played need to be still be tracked. So this is going to be implemented. A faster way to do so is actually to track the number of steps, or more likely distances the main character is traveled and base the spawning of the cherry on that amount. However this is unlike the regular game.
- There are two bonuses in this game.
- Scoring and the actual pellets would be simple enough.
On other projects
Games need cutscenes, and there is a possibly that Maya-built cutscenes could work in our engine. However there’s additional coding to be done.
- Regarding Keyframes:
- It is true that there are at least something in the engine that allows Keyframe-based animation. However, one notable miss in the crack is that the engine somehow lacks an ability to manipulate camera via these Keyframes. Not that they’ll be exported in the OBJ file to begin with. This need to be solved before any additional work could be done – maybe read these camera positions from another file?
- Regarding Morphs
- Morphs, or blend shapes, is necessary for a cutscene to work. The problem is that similar to the above condition, the animation of a morph target cannot be outputted by Maya normally. Maya can output animation to some other formats but it seems the engine initially reads none of them – maybe additional extension of the engine itself is necessary? This is shaping up to like the FMOD situation I mentioned earlier…
Aside from that 2 problems, it’ll be easy to import a cutscene made in Maya into our game.
Yeah, I’m aware that this week’s post is more about questions and questions without any progress, but problem solving is a sort of progress on its own. So I’m back into that. Until next time.