Making a game in Visual Studio from 1997

TL;DR: A developer used Visual Studio 6 (released in 1997) on Windows 7 to build a basic framework for a twin-stick shooter from scratch in pure C and OpenGL compatibility mode, including windowing, object management, coordinate system, and fixed time step. ## Development Environment & Motivation The presenter, Sean, uses **Visual Studio 6** (originally released in 1997) running on **Windows 7**. He has stuck with this environment since leaving Looking Glass Studios around 2001–2002. His reason for choosing such an old environment is familiarity and comfort; he doesn't want to migrate. The project goal is to build a simple twin-stick shooter, with WASD movement and mouse shooting. Since the development machine has no gamepad, the mouse substitutes for the right stick. ## Getting Started: Window & Basic Framework Sean first calls his personal platform library `STB` (for handling Windows window creation and OpenGL context), then initializes and creates a window with a gray background. He uses a 4:3 aspect ratio and sets up an orthographic projection matrix, with the coordinate system origin at the bottom-left (0,0), horizontal range -4 to +4, and vertical range -3 to +3 (later changed to -4 to 4 for testing). He uses an older OpenGL compatibility mode, requiring version 3.3. All code is written in a single `.c` file, without splitting into separate files beforehand. He explains: “If I knew I’d be serious about this project, I might split it right away. But for a quick stream, it’s not worth it.” ## Object Management: Static Array & ID Allocator Sean uses a simple static array to store all game objects and implements a basic allocator. Key design choices: - Array size is a power of two (e.g., 64). - **Object ID 0 is reserved as "null"**, similar to a null pointer. Allocation starts at index 1. - The allocator iterates through the array, finds a slot whose type is `none`, and returns its index. - The free function sets the slot to `none`. - The player object is hardcoded to a specific index in the array for more convenient syntax when accessed frequently. Sean explains that for an indie game, using one big array and manually managing slots is sufficient; no complex data structures or dynamic memory allocation are needed. He cites John Blow’s talk: “Just use a big array.” ## Coordinate System & Rendering The projection matrix uses `gluOrtho2D` (actual spelling is `gluOrtho2D`, but due to lack of autocomplete, he tried several times). Sean disables many 3D features (like face culling) and keeps only basic drawing. He uses a pink (magenta) square to test if rendering works. Math is handled with simple 2D vectors (position, velocity) inline in the game loop. ## Input & Movement Input handling uses Win32 API to check keyboard key states (WASD). Sean maps up/down and left/right to two axis variables and handles simultaneous opposite directions (they cancel out, resulting in 0). Movement speed is set to 20 units per second, using simple Euler integration: position += velocity * time step. ## Time Step: Fixed vs Variable Sean explicitly chooses a **fixed time step** (e.g., 60 or 120 FPS step), with multiple iterations per frame if the frame rate is low. His reasoning: - Variable time step leads to inconsistent physics behavior across different frame rates. - Fixed step ensures determinism for logic like collision detection. - For this game (touch and explode), simple fixed step is sufficient. He criticizes variable time step, noting it can cause trouble in projects requiring precise physics. ## Programming Philosophy: Warnings & Abstraction Sean takes a pragmatic approach to compiler warnings. He disables the warning about `double` to `float` conversion (4244) because “I simply don’t care about it.” He explains that during rapid prototyping or procedural generation, such warnings aren’t worth the time to fix. He emphasizes not over-engineering; get things running first. For instance, using static arrays instead of linked lists, and inline code instead of function abstractions. ## Summary The entire demo shows an experienced developer using a toolchain over 20 years old to quickly build the core game loop in a minimal, pragmatic way. While he admits game design is not his strength, his programming skills are sufficient for the project. The environment may be old, but the mindset is clear: focus on a working product, not perfect architecture. **Source:** Making a game in Visual Studio from 1997 - YouTube (https://www.youtube.com/watch?v=nQrzB5P5NPE)