Technology Choices and Comparative Study

Document Version: 1.0.1 Date: December 9, 2025 Team: J.A.M.E.S. (Jocelyn, Arthuryan, Matthieu, Enoal, Samuel)

---

Table of Contents

1. Introduction
2. Graphics Library: SFML
3. Networking Library: Boost.Asio
4. Dependency Manager: vcpkg
5. Conclusion
6. References

---

Introduction

This document justifies the key technology choices for the R-Type project. Each selection is evaluated based on:

• Project Requirements: Binary UDP protocol, multithreaded server, cross-platform (Linux/Windows)
• Performance: Real-time 60 FPS rendering and low-latency networking
• Team Expertise: Leveraging existing knowledge to maximize productivity
• Integration: Seamless compatibility with our toolchain (CMake, C++20)

---

Graphics Library: SFML

Quick Comparison

Library	Pros	Cons
SFML ✅	• Native C++ (RAII, OOP) • All 5 team members already proficient • Integrated (graphics + audio + input) • Excellent 2D API • vcpkg support	• Less control than raw OpenGL • Larger binary than minimal libs
SDL2	• Industry standard • Large ecosystem • Better gamepad support	• C API (verbose in C++) • Requires SDL_mixer for audio • 3-5 days learning curve
Raylib	• Very simple API • Good for prototyping	• Less mature • Limited for complex games • 2-3 days learning curve
GLFW + OpenGL	• Maximum performance • Full GPU control	• Requires shader programming • No 2D helpers • 2 weeks learning curve

Decision: SFML 2.6+

Critical Factor: All 5 team members have SFML experience from previous school projects.

Impact:

• 0 days onboarding vs 2-5 days for alternatives
• Can focus on networking and ECS architecture immediately
• Familiar debugging and development workflow

Why It Fits:

• ✅ Cross-platform (Linux/Windows requirement)
• ✅ 60 FPS 2D rendering capability
• ✅ Modern C++20 compatible
• ✅ vcpkg integration

---

Networking Library: Boost.Asio

Quick Comparison

Library	Pros	Cons
Boost.Asio ✅	• Async I/O (non-blocking) • Cross-platform (Linux/Windows) • Very mature/battle-tested • Modern C++ (lambdas, RAII) • Perfect for UDP binary protocol • Part of Boost ecosystem • Excellent documentation	• Requires Boost (~100MB+) • Slower compilation • Template-heavy
Asio (standalone)	• Same API as Boost.Asio • Header-only option • Smaller dependency	• Less mature than Boost version • Moderate learning curve
Raw Sockets	• Maximum control • No dependencies	• Platform-specific (#ifdef hell) • Manual async I/O (epoll/IOCP) • Complex cross-platform code
SFML Network	• Simple API • Integrated with SFML	• Blocking I/O only • Requires thread-per-client • Poor for multithreaded server
ZeroMQ	• High-level patterns • Message queuing	• Higher latency • Overkill for direct client-server • Not designed for real-time games

Decision: Boost.Asio

Why Async I/O Matters:

// SFML (blocking): Thread waits idle for data
socket.receive(packet);  // BLOCKS ❌

// Boost.Asio (async): Thread handles other clients while waiting
socket.async_receive_from(buffer, endpoint,
    [](asio::error_code ec, size_t bytes) {
        // Called when data arrives ✅
    });

Project Requirements:

• ✅ Multithreaded server → Boost.Asio's io_context handles multiple clients per thread
• ✅ UDP networking → Native async UDP support
• ✅ Cross-platform → No #ifdef needed (abstracts epoll/IOCP/kqueue)
• ✅ Custom binary protocol → Low-level socket control

Performance:

• 1 thread handles 100+ clients (vs thread-per-client with blocking I/O)
• Non-blocking operations prevent slow clients from affecting others

---

Dependency Manager: vcpkg

Quick Comparison

Tool	Pros	Cons
vcpkg ✅	• One-line CMake integration • Cross-platform (MSVC/GCC) • Auto dependency resolution • Binary caching • Microsoft backing	• Slower first build • Requires installation
Conan	• Mature versioning • Pre-built binaries	• Additional setup step • Python dependency • Team unfamiliar
FetchContent	• Built into CMake • No external tools	• Rebuilds on clean • Manual transitive deps • No caching • Clutters CMakeLists.txt
Git Submodules	• Complete control • Works offline	• Manual config per lib • Large repo size • Violates project spec*

*Project spec: "Copying full dependencies source code into your repository is NOT proper dependency management"

Decision: vcpkg (manifest mode)

Manifest Example:

{
  "dependencies": ["sfml", "boost-asio"]
}

CMake Integration:

cmake -DCMAKE_TOOLCHAIN_FILE=vcpkg/scripts/buildsystems/vcpkg.cmake
# That's it! No boilerplate in CMakeLists.txt

Key Benefits:

• ✅ Auto-resolves transitive deps (SFML → freetype → zlib → ...)
• ✅ Cross-platform builds (Windows MSVC + Linux GCC)
• ✅ Binary caching (CI/CD: 1 min vs 20 min)
• ✅ All needed packages available (SFML, Boost.Asio, GoogleTest)

---

Conclusion

Technology Stack Summary

Layer	Technology	Key Reason
Graphics	SFML 2.6+	All 5 members proficient → 0 days learning
Networking	Boost.Asio	Async I/O for multithreaded server
Dependencies	vcpkg	One-line CMake integration

Project Requirements Compliance

• ✅ Binary UDP Protocol → Boost.Asio provides low-level socket control
• ✅ Multithreaded Server → Boost.Asio io_context thread pool (non-blocking)
• ✅ Cross-Platform (Linux/Windows) → All technologies support both platforms seamlessly
• ✅ Package Manager → vcpkg with CMake integration
• ✅ 60 FPS Rendering → SFML handles real-time 2D graphics

Strategic Decisions

Decision	Rationale	Impact
SFML over alternatives	Team already expert	Saves 3-14 days onboarding
Boost.Asio over raw sockets	Cross-platform async I/O	Eliminates platform-specific code
vcpkg over Conan/FetchContent	Simplest CMake integration	One-line configuration

---

References

Official Documentation

Technology Choices and Comparative Study

Document Version: 1.0.1 Date: December 9, 2025 Team: J.A.M.E.S. (Jocelyn, Arthuryan, Matthieu, Enoal, Samuel)

---

Table of Contents

1. Introduction
2. Graphics Library: SFML
3. Networking Library: Boost.Asio
4. Dependency Manager: vcpkg
5. Conclusion
6. References

---

Introduction

This document justifies the key technology choices for the R-Type project. Each selection is evaluated based on:

• Project Requirements: Binary UDP protocol, multithreaded server, cross-platform (Linux/Windows)
• Performance: Real-time 60 FPS rendering and low-latency networking
• Team Expertise: Leveraging existing knowledge to maximize productivity
• Integration: Seamless compatibility with our toolchain (CMake, C++20)

---

Graphics Library: SFML

Quick Comparison

Library	Pros	Cons
SFML ✅	• Native C++ (RAII, OOP) • All 5 team members already proficient • Integrated (graphics + audio + input) • Excellent 2D API • vcpkg support	• Less control than raw OpenGL • Larger binary than minimal libs
SDL2	• Industry standard • Large ecosystem • Better gamepad support	• C API (verbose in C++) • Requires SDL_mixer for audio • 3-5 days learning curve
Raylib	• Very simple API • Good for prototyping	• Less mature • Limited for complex games • 2-3 days learning curve
GLFW + OpenGL	• Maximum performance • Full GPU control	• Requires shader programming • No 2D helpers • 2 weeks learning curve

Decision: SFML 2.6+

Critical Factor: All 5 team members have SFML experience from previous school projects.

Impact:

• 0 days onboarding vs 2-5 days for alternatives
• Can focus on networking and ECS architecture immediately
• Familiar debugging and development workflow

Why It Fits:

• ✅ Cross-platform (Linux/Windows requirement)
• ✅ 60 FPS 2D rendering capability
• ✅ Modern C++20 compatible
• ✅ vcpkg integration

---

Networking Library: Boost.Asio

Quick Comparison

Library	Pros	Cons
Boost.Asio ✅	• Async I/O (non-blocking) • Cross-platform (Linux/Windows) • Very mature/battle-tested • Modern C++ (lambdas, RAII) • Perfect for UDP binary protocol • Part of Boost ecosystem • Excellent documentation	• Requires Boost (~100MB+) • Slower compilation • Template-heavy
Asio (standalone)	• Same API as Boost.Asio • Header-only option • Smaller dependency	• Less mature than Boost version • Moderate learning curve
Raw Sockets	• Maximum control • No dependencies	• Platform-specific (#ifdef hell) • Manual async I/O (epoll/IOCP) • Complex cross-platform code
SFML Network	• Simple API • Integrated with SFML	• Blocking I/O only • Requires thread-per-client • Poor for multithreaded server
ZeroMQ	• High-level patterns • Message queuing	• Higher latency • Overkill for direct client-server • Not designed for real-time games

Decision: Boost.Asio

Why Async I/O Matters:

Async I/O enables low-latency, non-blocking networking suitable for real-time games and server scalability.

Dependency Management

Tool	Pros	Cons
vcpkg ✅	• One-line CMake integration • Cross-platform (MSVC/GCC) • Auto dependency resolution • Binary caching • Microsoft backing	• Slower first build • Requires installation
Conan	• Mature versioning • Pre-built binaries	• Additional setup step • Python dependency • Team unfamiliar
FetchContent	• Built into CMake • No external tools	• Rebuilds on clean • Manual transitive deps • No caching • Clutters CMakeLists.txt
Git Submodules	• Complete control • Works offline	• Manual config per lib • Large repo size • Violates project spec*

*Project spec: "Copying full dependencies source code into your repository is NOT proper dependency management"

Decision: vcpkg (manifest mode)

Manifest Example:

{
  "dependencies": ["sfml", "boost-asio"]
}

CMake Integration:

cmake -DCMAKE_TOOLCHAIN_FILE=vcpkg/scripts/buildsystems/vcpkg.cmake
# That's it! No boilerplate in CMakeLists.txt

Key Benefits:

• ✅ Auto-resolves transitive deps (SFML → freetype → zlib → ...)
• ✅ Cross-platform builds (Windows MSVC + Linux GCC)
• ✅ Binary caching (CI/CD: 1 min vs 20 min)
• ✅ All needed packages available (SFML, Boost.Asio, GoogleTest)

---

Conclusion

Technology Stack Summary

Layer	Technology	Key Reason
Graphics	SFML 2.6+	All 5 members proficient → 0 days learning
Networking	Boost.Asio	Async I/O for multithreaded server
Dependencies	vcpkg	One-line CMake integration

Project Requirements Compliance

• ✅ Binary UDP Protocol → Boost.Asio provides low-level socket control
• ✅ Multithreaded Server → Boost.Asio io_context thread pool (non-blocking)
• ✅ Cross-Platform (Linux/Windows) → All technologies support both platforms seamlessly
• ✅ Package Manager → vcpkg with CMake integration
• ✅ 60 FPS Rendering → SFML handles real-time 2D graphics

Strategic Decisions

Decision	Rationale	Impact
SFML over alternatives	Team already expert	Saves 3-14 days onboarding
Boost.Asio over raw sockets	Cross-platform async I/O	Eliminates platform-specific code
vcpkg over Conan/FetchContent	Simplest CMake integration	One-line configuration

---

References

Official Documentation

• SFML Documentation
• SFML Tutorials
• Boost.Asio Documentation
• vcpkg Documentation
• CMake Documentation

Comparative Studies

• Game Networking Architectures
• ECS vs OOP in Game Development
• Binary vs Text Protocols
• UDP vs TCP for Games

R-Type Project Documentation

• RFC-0001: Engine Architecture
• README.md
• CONTRIBUTING.md

---

Official Documentation

• SFML Documentation
• SFML Tutorials
• Boost.Asio Documentation
• vcpkg Documentation
• CMake Documentation

Comparative Studies

• Game Networking Architectures
• ECS vs OOP in Game Development
• Binary vs Text Protocols
• UDP vs TCP for Games

R-Type Project Documentation

• README.md
• CONTRIBUTING.md

---

This document will be updated as technologies evolve and new requirements emerge in Part 2 of the project.