This model is a "thinking" model focused only on "thinking" without generating an answer or solution.
I believe the proprietary models like Gpt-o1 and Gemini 2.0 Flash Thinking actually work in 2 steps: thinking stage and answer generation. So, the thoughts provide extra context for the model.
My argument is that at this point we might have extremely refined open-release models, but they are still bound to user input to generate the next token. Adding some simple, concise and high quality context should improve the output quality. (Too much context could also dilute the attention of smaller models as well)
The aim is to later inject the created thinking process/workflow to a normal model, and steering it like a "thinking" model.
Issues:
It still can generate unintended answers.
Rarely switches to Chinese.
The output can be too long.
The training dataset needs more examples and cleaning.
Use the template as it is with the special tokens and fixed system message on top.
Template:
Think about the user prompt and generate a brief solution workflow for the assistant in first-person narrative. You may break down the prompt for a step-by-step analysis.
### Prompt: {Write worm game.}<|file_sep|>
<|box_start|>### Workflow: {output}<|box_end|><|im_end|>
Okay, I need to create a simple text-based game called "Worm Game." Here's my plan:
Define the game mechanics: The player controls a small worm that moves around on a grid. The goal is to eat food items scattered across the grid while avoiding obstacles and other worms.
Set up the game environment:
Create a 2D grid (e.g., 20x20 cells) as the playing field.
Initialize the worm at one end of the grid, facing right.
Place some food items randomly within the grid boundaries.
Implement movement logic:
Allow the player to control the worm using arrow keys or WASD.
Update the worm’s position based on input from the player.
Handle collision detection:
Check if the worm collides with any walls or itself.
If there's a collision, reset the worm back to its starting point and wait for a short period before allowing it to move again.
Manage food consumption:
When the worm eats a piece of food, increase its size slightly and place another food item somewhere else on the grid.
Keep track of the score by counting how many pieces of food have been eaten.
Add obstacle handling:
Introduce static obstacles like rocks or trees in random locations on the grid.
Ensure these obstacles do not overlap with the food placements.
Win condition:
Define what constitutes winning the game (e.g., reaching a certain level of size after eating enough food).
Lose condition:
Determine when the player loses (e.g., colliding with an obstacle or going off the edge of the screen).
User interface:
Display the current state of the game including the worm, food, obstacles, and score.
Include instructions for playing the game.
Testing and debugging:
Playtest the game thoroughly to find and fix bugs.
Optimize performance if necessary.
Polish:
Add animations or visual effects where appropriate.
Improve sound effects and music to enhance immersion.
By following this structured approach, I should be able to develop a fun and engaging Worm Game.
