CONWAYS GAME OF LIFE HEAT MAP CODE
CONWAYS GAME OF LIFE HEAT MAP SERIES

Rather than develop a Tetris game in Life directly, we slowly ratcheted up the abstraction in a series of steps. The underlying idea of this project is abstraction. Questions can be directed to our development chatroom.

CONWAYS GAME OF LIFE HEAT MAP CODE

Table of ContentsĪlso consider checking out our GitHub organization where we've put all of the code we've written as part of our solution. Please distribute any upvotes or bounties across all members of the team. Each member will write about specific sub-topics, roughly corresponding to the areas of the project in which they were most involved. We would also like to extend our thanks to 7H3_H4CK3R, Conor O'Brien, and the many other users who have put effort into solving this challenge.ĭue to the unprecedented scope of this collaboration, this answer is split in parts across multiple answers written by the members of this team. Although the composition of the team has varied over time, the participants as of writing are the following: This project is the culmination of the efforts of many users over the course of the past 1 & 1/2 years. The pattern file, in all its glory, can be found here, viewable in-browser here. This began as a quest but ended as an odyssey. Initial live cell count - smaller count wins. Smaller changes to input - the fewest cells (for the worst case in your automaton) that need to be manually adjusted for an interrupt wins.įastest execution - the fewest generations to advance one tick in the simulation wins.

Your program will be scored on the following things, in order (with lower criteria acting as tiebreakers for higher criteria):īounding box size - the rectangular box with the smallest area that completely contains the given solution wins. The displayed result must visibly resemble an actual Tetris grid. moving a piece left or right, dropping it, rotating it, or randomly generating a new piece to place onto the grid), counting a specific number of generations as waiting time, and displaying the result somewhere on the automaton. Your program will receive input by manually changing the state of the automaton at a specific generation to represent an interrupt (e.g. Your task is to build a cellular automaton using the rules of Conway's game of life that will allow for the playing of a game of Tetris. In addition, it is known that the Game of Life is Turing-complete. In Conway's Game of Life, there exist constructs such as the metapixel which allow the Game of Life to simulate any other Game-of-Life rule system as well. This is also true of the num_neighbors map.Here is a theoretical question - one that doesn't afford an easy answer in any case, not even the trivial one. It's not particularly, because it requires the creation and destruction of many objects (the std::vector and each of the Cells within it) each time it's called. You're right to question whether the current method is efficient. (int)floor((mouse_pos_y + camera_y) / zoom)) If (frame_count % FRAMES_PER_TICK = 0) Īnd alter the line within get_input_mouse to use it instead of doing yet another Cell creation/destruction cycle: highlighted_tPos((int)floor((mouse_pos_x + camera_x) / zoom), Main.cpp is the main loop for the program including a framerate cap:Ĭonst int FRAMES_PER_TICK = TARGET_FRAMERATE / TARGET_TICKRATE Ĭonst int TARGET_TIMESTEP = 1000 / TARGET_FRAMERATE Is this good practice or is one long function better?īelow is the code in rough order of importance alternatively here is a github link. In InputHandler::get_input I just call three 'subfunctions' which aren't reused anywhere else.In Python I would use yield to avoid this is there anything comparable in C++? In Cell::get_neighbours() it seems a bit inefficient to keep constructing vectors for each cell.Any feedback is welcome, but I have a couple of specific questions: The user can add and remove cells with the mouse and some basic stats are printed to console. This is my attempt at a basic implementation of GOL.

Conways game of life heat map