DOT Game - Experiment with custom 2d rendering - Part 1
grand marshal polycounter
I wanted to try out custom 2d rendering for a long time now. I have no problem with Paper 2d in unreal, but if we wan't to be honest, its actually 3d rendered from an orthographic camera. I also like hlsl and blueprint scripting a lot, so I thought it would be a nice challenge for myself to try to mock up a custom 2d renderer, in a basic form for now, and if it works, I can develop it further later.
The idea is the following... Make an empty level, don't add any actors. Create a game mode and a controller blueprint, but don't create a character. The game mode points to the controller which we will use, and the empty level has the game mode assigned to it. For now I do everything inside the controller blueprint, but maybe later in a later experiment, I will move stuff somewhere else. There are 2 materials that I will use to render the game. One to draw stuff into the channels of a render target. This is done in a per object base. And another material to render the game. This another one is a full screen post process shader that is assigned to the camera, so technically we see the game as a post process rendered on top of the black empty level. Actually all of this works very well. In this simple game, I didn't need to have many different objects, so the object list is just a list of coordinates of where to draw things when something changed. The render target is fully redrawn only when I need to remove something. Otherwise I just "alpha test" things on top of it. I could change removel to use a similar method though. The post process material samples the render target, and puts unique things on top, such as things that needs to be updated very often, like the player, or the "ui"...
For now I wanted to have a very simple game, because the main point was to test the rendering method I had in mind. This is what happens in the game, and its rules:
- Player is a white pixel , and can move using the mouse
- Player starts with 5 seconds time and it decreses
- Initially there are 10 green pixels spawned, and they are randomly distributed on the screen. The player needs to collect all of them before his time reaches 0. A new green pixel gets spawned every 2 seconds. Picking up a green pixel increases his time by 1.
- Initially there are 40 red pixels spawned, and they are randomly distributed on the screen. Touching a red pixel decreases player's time by 1 and spawns 2 new red pixels.
Here is a video from it in action:
https://www.youtube.com/watch?v=7F6CPe9M4uo&feature=youtu.be
You can also download the build of the game for free from here:
https://www.dropbox.com/s/jrprmdighd8wkcb/DotGame_Build.zip?dl=0
Overall I call this a success. The whole thing was done in less than one day, and everything worked as I expected and planned. Next time I'll do something more complex, and have sprites instead of simple colored pixels.
The idea is the following... Make an empty level, don't add any actors. Create a game mode and a controller blueprint, but don't create a character. The game mode points to the controller which we will use, and the empty level has the game mode assigned to it. For now I do everything inside the controller blueprint, but maybe later in a later experiment, I will move stuff somewhere else. There are 2 materials that I will use to render the game. One to draw stuff into the channels of a render target. This is done in a per object base. And another material to render the game. This another one is a full screen post process shader that is assigned to the camera, so technically we see the game as a post process rendered on top of the black empty level. Actually all of this works very well. In this simple game, I didn't need to have many different objects, so the object list is just a list of coordinates of where to draw things when something changed. The render target is fully redrawn only when I need to remove something. Otherwise I just "alpha test" things on top of it. I could change removel to use a similar method though. The post process material samples the render target, and puts unique things on top, such as things that needs to be updated very often, like the player, or the "ui"...
For now I wanted to have a very simple game, because the main point was to test the rendering method I had in mind. This is what happens in the game, and its rules:
- Player is a white pixel , and can move using the mouse
- Player starts with 5 seconds time and it decreses
- Initially there are 10 green pixels spawned, and they are randomly distributed on the screen. The player needs to collect all of them before his time reaches 0. A new green pixel gets spawned every 2 seconds. Picking up a green pixel increases his time by 1.
- Initially there are 40 red pixels spawned, and they are randomly distributed on the screen. Touching a red pixel decreases player's time by 1 and spawns 2 new red pixels.
Here is a video from it in action:
https://www.youtube.com/watch?v=7F6CPe9M4uo&feature=youtu.beYou can also download the build of the game for free from here:
https://www.dropbox.com/s/jrprmdighd8wkcb/DotGame_Build.zip?dl=0
Overall I call this a success. The whole thing was done in less than one day, and everything worked as I expected and planned. Next time I'll do something more complex, and have sprites instead of simple colored pixels.