A 42 School project that started delving into graphic and game development
- game.h - Header file defining game structures, enums, and function prototypes.
- main.c - Main entry point of the program.
- init.c - Initialization functions for game entities (player, rooms, puzzles, etc.).
- render.c - Functions for rendering game elements.
- input.c - Handling user input.
- update.c - Updating game state based on user input and time.
- boss.c - Logic and behavior for the boss enemy, including Dead Man's Volley.
- puzzle.c - Logic and behavior for puzzles and interactive elements.
- rooms.c - Initialization and handling of different types of rooms.
- player.c - Player-specific functionality (movement, actions, inventory, etc.), including hotkey healing.
- spawn.c - Handling spawning of items or enemies.
- maps.c - Loading and managing game maps or levels.
- ui.c - Implementation of user interface elements (health bars, dialog boxes, etc.).
- camera.c - Managing camera movement and viewports.
Here's a simplified example of how you might structure your project with header files for each .c
file:
-
game.h: Main header file defining game-wide structures (
Game
,Room
,Player
, etc.) and core function prototypes (init_game
,update_game
,render_game
, etc.). -
player.h: Header file defining player-related structures (
Player
,Inventory
, etc.) and function prototypes (init_player
,update_player
,handle_player_input
, etc.). -
boss.h: Header file defining boss-related structures (
Boss
,BossAttack
, etc.) and function prototypes (init_boss
,update_boss
,handle_boss_room
, etc.). -
puzzle.h: Header file defining puzzle-related structures (
Puzzle
,Button
, etc.) and function prototypes (init_puzzle
,handle_puzzle_room
, etc.). -
room.h: Header file defining room-related structures (
Room
,Door
, etc.) and function prototypes (init_room
,handle_room_events
, etc.). -
render.h: Header file defining rendering-related function prototypes (
render_game
,render_player
,render_boss
,render_ui
, etc.). -
input.h: Header file defining input-related function prototypes (
handle_input
,handle_player_input
,handle_puzzle_input
, etc.). -
spawn.h: Header file defining spawning-related function prototypes (
spawn_key
,spawn_enemy
, etc.). -
maps.h: Header file defining map-related function prototypes (
load_map
,generate_map
, etc.). -
ui.h: Header file defining UI-related structures (
UIElement
,DialogBox
,HealthBar
, etc.) and function prototypes (render_dialog
,render_health_bar
, etc.). -
camera.h: Header file defining camera-related structures (
Camera
,Viewport
, etc.) and function prototypes (update_camera
,set_camera_position
, etc.).
-
Game Initialization and Structures:
- Define structures like
Player
,Boss
,Puzzle
,Room
, etc., ingame.h
. - Implement initialization functions (
init_game
,init_player
,init_boss
, etc.) ininit.c
.
- Define structures like
-
Rendering:
- Implement rendering functions (
render_game
,render_player
,render_boss
, etc.) inrender.c
. - Utilize graphics libraries like
mlx
for rendering if using C graphics.
- Implement rendering functions (
-
User Input Handling:
- Implement functions (
handle_input
,handle_player_input
, etc.) ininput.c
.
- Implement functions (
-
Game State Updates:
- Implement update functions (
update_game
,update_player
,update_boss
, etc.) inupdate.c
.
- Implement update functions (
-
Boss and Puzzle Mechanics:
- Implement boss behavior, attacks, and Dead Man's Volley mechanics in
boss.c
. - Implement puzzle solving mechanics in
puzzle.c
.
- Implement boss behavior, attacks, and Dead Man's Volley mechanics in
-
Room Management:
- Define different room types (
ROOM_PUZZLE
,ROOM_BOSS
, etc.) and their initialization inrooms.c
. - Handle room transitions and interactions.
- Define different room types (
-
Player Actions:
- Define player movement, actions (attacking, interacting), inventory handling, and hotkey healing in
player.c
.
- Define player movement, actions (attacking, interacting), inventory handling, and hotkey healing in
-
Item Spawning:
- Implement functions for spawning items or enemies in
spawn.c
.
- Implement functions for spawning items or enemies in
-
Map Management:
- Load and manage game maps or levels using
maps.c
.
- Load and manage game maps or levels using
-
User Interface:
- Implement UI elements such as health bars, dialog boxes, and inventory displays in
ui.c
.
- Implement UI elements such as health bars, dialog boxes, and inventory displays in
-
Camera and Viewport Management:
- Implement camera movement and viewport management functions in
camera.c
for scrolling and maintaining focus.
- Implement camera movement and viewport management functions in
Create a new project directory and create the necessary subdirectories for each component (e.g., src, include, assets, etc.). Create the necessary header files (.h) and source files (.c) according to your provided structure.
In game.h, define the game-wide structures (e.g., Game, Room, Player, etc.) and core function prototypes (e.g., init_game, update_game, render_game, etc.). In each respective header file (e.g., player.h, boss.h, puzzle.h, etc.), define the corresponding structures and function prototypes.
In init.c, implement the initialization functions for game entities (e.g., init_game, init_player, init_boss, etc.).
In render.c, implement the rendering functions (e.g., render_game, render_player, render_boss, etc.) using MiniLibX.
In input.c, implement functions for handling user input (e.g., handle_input, handle_player_input, etc.).
In update.c, implement update functions (e.g., update_game, update_player, update_boss, etc.) based on user input and time.
In boss.c, implement boss behavior, attacks, and Dead Man's Volley mechanics. In puzzle.c, implement puzzle solving mechanics.
In rooms.c, define different room types (e.g., ROOM_PUZZLE, ROOM_BOSS, etc.) and their initialization. Handle room transitions and interactions.
In player.c, implement player movement, actions (attacking, interacting), inventory handling, and hotkey healing.
In spawn.c, implement functions for spawning items or enemies.
In maps.c, load and manage game maps or levels.
In ui.c, implement UI elements such as health bars, dialog boxes, and inventory displays.
In camera.c, implement camera movement and viewport management functions for scrolling and maintaining focus.
- Dialog System: Implement dialog boxes or text displays within
ui.c
or a dedicated file for managing dialogs. - Inventory System: Simplify as a hotkey healing feature in
player.c
, eliminating the need for a separate inventory system.
Check that the project compiles well (without re-link) when you execute
the make
command and that the executable name is so_long
.
If not use the invalid compilation flag at the end of the scale.
- use different maps.
- test with different sizes.
- test with different line sizes.
Also, check that the program returns an error and exits properly when the configuration file is misconfigured (for example an unknown key, double keys, an invalid path..).
If not, the defense is over and use the appropriate flag incomplete work, crash...
We're going to evaluate the technical elements of the display. Check that the level is a valid representation of the map used as parameter.
-
A window must open at the launch of the program. It must stay open during the whole execution.
-
Hide all or part of the window either by using another window or by using the screen's borders, then minimize the windows and maximize it back. In all cases, the content of the window must remain consistent.
In this section, we're going to evaluate the program's user generated events. Execute the 3 following tests. If at least one fails, this means that no points will be awarded for this section.
-
Click the red cross at the top left of the window. The window must close and the program must exit cleanly.
-
Press the ESC key. The window must close and the program must exit cleanly. In the case of this test, we will accept that another key exits the program, for example, Q.
-
Press the four arrow keys (we'll accept WASD or ZQSD keys) in the order of your liking. Each key press must render a visible result on the window(player's movement).
In this section, we'll evaluate the implementation of the player's movement. Execute the 5 following tests. If at least one fails, this means that no points will be awarded for this section.
-
The player's spawning position must be in accordance with the map file.
-
Press the arrows keys to move in every direction on the map.
-
is the game "playable"?
In this section, we'll evaluate the map representation. Execute the following tests. If at least one fails, this means that no points will be awarded for this section.
-
The wall's texture is well placed and the player cannot go through it.
-
The collectible's texture is well placed and the player can pick it by walking on it.
-
The Exit texture is well placed and the player can finish the game by walking on it but only after picking every collectible.
-
The player texture is well placed and can move in every direction except into the walls.
In this section, we'll evaluate the gameplay elements. Execute the following tests. If at least one fails, this means that no points will be awarded for this section. Move to the next one.
- There's a small counter displayed on the shell that counts how many movements the player did.
- The counter can be displayed directly on the game screen (see bonus part).
The program use mlx_put_image_to_window and not mlx put pixel!
We will look at your bonuses if and only if your mandatory part is excellent. This means that you must complete the mandatory part, beginning to end, and your error management must be flawless, even in cases of twisted or bad usage. So if the mandatory part didn't score all the points during this defense bonuses will be totally ignored.
enemy patrols that cause the player to lose in case of contact.
There's some sprite animation. You need to explain what it is and how you did it. Rate it from 0 (failed) through 5 (excellent)
The counter of movement is rendered on the screen using texture or mlx_string_put.