This guide outlines recommended practices for developing games with the Retro Game Engine.
your_game/
├── assets/
│ ├── sprites/ # Sprite sheets and animations
│ ├── audio/ # Sound effects and music
│ ├── tilemaps/ # Level data and tilesets
│ └── fonts/ # Bitmap fonts
├── src/
│ ├── components/ # Custom game components
│ ├── scenes/ # Game scenes
│ └── systems/ # Game systems
└── config/ # Game configuration files
- Keep scenes focused and single-purpose
- Use components for reusable functionality
- Implement systems for global game logic
- Separate configuration from code
- Unload unused assets when changing scenes
- Use sprite sheets instead of individual images
- Pool frequently created/destroyed objects
- Clear event listeners and references
- Preload assets during scene initialization
- Use asynchronous loading for large assets
- Implement loading screens for smooth transitions
- Cache frequently used resources
- Batch similar sprites together
- Use appropriate z-indices for layering
- Implement view culling for large levels
- Minimize draw calls and state changes
- Use simple collision shapes when possible
- Implement spatial partitioning for many objects
- Update physics at fixed time steps
- Disable physics for off-screen objects
- Process input once per frame
- Use input buffering for responsive controls
- Implement input mapping for configurability
- Handle multiple input methods consistently
- Maintain consistent pixel scale
- Use limited color palettes
- Design clear visual hierarchies
- Consider readability at all resolutions
- Keep sound effects short and impactful
- Use audio pooling for frequent sounds
- Implement priority system for channels
- Consider music loop points carefully
- Provide clear feedback for actions
- Implement consistent controls
- Use screen transitions for loading
- Save game state frequently
- Test with minimum spec hardware
- Profile CPU and memory usage
- Monitor frame rate consistency
- Test with various input methods
- Test edge cases in gameplay
- Verify save/load functionality
- Check all possible transitions
- Test error handling
- Set appropriate version numbers
- Include all required assets
- Optimize assets for distribution
- Test builds on target platforms
- Include clear installation instructions
- Provide system requirements
- Document known issues
- Include version history
- Not cleaning up event listeners
- Keeping references to destroyed objects
- Not disposing of textures
- Circular references in components
- Too many active physics objects
- Inefficient collision checks
- Unoptimized sprite rendering
- Memory fragmentation
- Inconsistent difficulty curves
- Unresponsive controls
- Unclear objectives
- Poor save point placement