First of all this will be a weird post, but i have something to tell you guys which i have in my mind since a long time.
Since forever i am trying to make games, but for some reason i never finish a single one. Sure i get some raw prototypes done, but then i fully lose all my motivations and never touch it again - which really depresses me a lot.
To give some example, this community have recently started a "Challenges" system, where you can enter some challenge writing some simple games with a fixed set of rules in place - which is very great for learning. So i tried to challenge myself for the october and the november challenge and at the beginning i was very motivated and written a platformer from scratch in no time, but after i got everything working except for enemies i simply lost my motivation again. For the pong challenge its the same deal - i got collisions working and started to put in some CPU movement code and then i lost it again. Why is that? Am i so bad at making games? Why do i lose my motivation all the time, even though i am making steady progress? I dont understand.
The best progress i had so far, was my "Leverman" UE4 project where i finished my first MVP - which was fully playable, but even for this project i have no motivation anymore, because it needs a full remake due to the fact that i made a mistake in the 2D Pixel to UE Units scale and i lost pretty much all the progress i made after my MVP.
On the other side, i am making tools, applications, libraries all over the place and never have this kind of motivation problems there, especially at work where i write desktop and server applications. For example, i have written a media player called Xenorate from 1999 until 2011 and i mostly never had any motivation problems there.
So it seems that normal application development is more suited for me, isnt it?
But really i want to make games, not for making money or getting hired. I just want to proove myself that i can do it or something.
I am making steady progress - but in a very slow pace, not sure if i can keep up with the challenge time frame.
Also i am coding on my crappy notebook (MSI Apache Pro) with the worst keyboard layout ever. No space for a keyboard right now, also i am sick fighting against a cold.
Game pad input is working great, thanks to XInput with integration into FPL ;-)
I can plug in and out any controller and it just works. Also i prepared it for multiplayer, so it will spawn another player when a new controller has been plugged in. When i am in single player mode, every controller can control the single player. So you can move with the keyboard and then of a sudden switch to a gamepad and move with them. Pretty cool if i say that so myself.
Starting to get a basic level editor up and running, with the ability to toggle between editor and game mode.
Also i changed the renderer system a lot.
Struggling a lot, lost a bit of motivation but still made some progress.
Now i am rendering sprites for the level instead of rectangles, yay! Also i integrated ImGui now and made the editor entirely with the ImGui API.
Worked beutifully after i nailed down some simple dimensional math... which took me forever, because i suck at math most of the times because i am not using it regularly.
Game is still the same though... simple stable platformer, but no enemies, no collectibles, no goal...
- I need to make a player sprite, a rectangle looks ugly
- Time to make my first enemy for the very first time, i never made any AI code at all
- Player should fire something to freeze the enemies, but with a cooldown
- After sprites are done, make animations and integrate it into the game.
- More levels
I started participating in the game dev community challenge for oct. 2017 !
Here are the progress after the first evenings:
I decided to make a bubble bobble game in C++ from scratch without using any external libraries - except for my own platform abstraction library (FPL).
So i started up visual studio 2017 communiy edition and made all the groundwork nessecary to power a game, like base rendering, robust input handling, stable game loop, etc.
I am closer to a game now, i have a player (rectangle) jumping around on the screen with rock-solid vector based collisions in a fixed level.
Movements seems to be okay for now and are pretty solid. I am happy, made good progress so far.
Starting to add a ton of math vector/matrix stuff, so i can migrate to modern opengl pretty soon. Also i can now load and render textures
Second thing i have done is to prepare FPL to handle gamepads using XInput in win32, using the same event system i have right now.
Move the level to a tile based system, so i can render and create it more easiely
Move to a command render system instead of immediate rendering, so i can abstract the rendering entirely.
Compile glew yourself so that you wont get weird linker errors on the prebuild libraries or write your own opengl loader
Draw text like score/level and in-game labels
Copy assets as post-build to the output path instead of setting the work-directory
Cant use SIMD for mat4-mult right now, because __m128 is not recognized at all even though i included all the intrinsics headers -.-
I will stop doing any private game or software development for a while or will drop it entirely - depending on how i feel about it.
Right now i dont feel like doing it and dont see any reason why i should do this anymore. I cant hardly find time and when i have one, it just isn´t fun.
But i may do some trickjump mapping in reflex... when they fixed that broken editor :-(
So bye guys, have a good life.
Well a lot had happened and it seems i have my confidence and motivation back for coding.
So i decided to finish "unfinished" prototypes and games i have created in the past and then going from there.
Right now i am working on a breakout prototype i made in UE4 with random generated maps, nice effects and other stuff.
Looks like a project i may actually finish...
That said i will focus on that for now only and not get distracted by other projects.
It seems since the last months i have a deep motivation problem so i basically get nothing noticable done at all.
I work all day (+40 hours each week) and even when i have spare time - i just fool around doing nothing at all.
But when i have time and start to code i just compile the code a hundred times, and watch the results over and over again.
And then starting to see that my results are shit and i want to start from the very beginning, again and again. Or i get distracted by starting another project...
-> Endless circulation of getting nothing done.
Since years its always the same :-(
Fortunatly at work i dont have this problems, writing code there just works and i mostly dont have to think at all, because its just stupid high level programming - relying on nothing else than 3rd party libraries nor learning or getting challenged at all.
I am frustrated right now...
i was working a bit on the next iteration on my game and finally found a nice graphics style to go for: Real tiles and proper lighting, yay! (See the screenshot attached) Even though i am making some progress, i decided to stop working on the project with unreal engine 4 entirely - for several reasons:
I had a few bad data losses which resulted in losing all of my new tiles and lighting work due to some UE4 git integration awesomeness and my stupidness to trust them. Second i really wanted to do all the programming and make a full game by myself - going through the entire process of making a game with a low level language like C. This is in fact a dream i have since i started playing around with game development in the first place, because i was always depending on others like using third party libraries, asking tons of newbie questions etc.
So i booted up visual studio 2015 community edition, created a plain win32 C project without nothing in it and started to code - with two constraints only (not using any third party libraries at all - including the std library, only use OOP when its really needed).
Now after a few evenings i finally built most of the groundwork in i need in plain C without creating a single class or any type of object oriented code ;-)
This includes the entire platform independent architecture (Game DLL and Win32 executable), stable input handling, all the math i need, a directsound audio and opengl video renderer including proper font rendering, a rigid body physics system, simple memory management and some very basic game code. Everything i need to get me started...
Now the plan is to recreate my original prototype i made and start from there. Of course all the tilesets and sprites i used are not lost, so i definitely will reuse them.
I finished the first mvp (minimum viable product) of leverman with all features i wanted ;-) The first level is fully playable from start to finish and contains the following features:
- Tilemap based - Player based on character controller including double jump support - Simple generic following camera system - Player interaction system (Levers, Elevators, Triggers...) - Up/Down elevator systems which gets requested automatically when player is near a stop trigger (Stops are detected by line traces in the player interaction direction up/down) - Jumppads - Spikes and lava, no enemies at all - Kill and respawn system including checkpoint support - Levers to open doors / sink lava etc. - Moveable platforms with obstacle detection (No timeline or matinee at all) - A very simple main menu
But there are tons of things todo to make it actually be finished:
- What type of character (Human? Animal?, Robot?) - Find and apply a suitable art style for the game (Scifi prefered) - Explain stuff (Indicator when you can interact, Simple tutorial level) - Sounds and music (Sound-generator - but music is a bit harder...) - Save games / Checkpoints - Goodies to collect - Better main menu + Options - Track statistics (Time, Deaths, Counts etc.) - Create more levels (11 levels are already written on paper) - Make it a bit more easier (Seems to be pretty hard...) - Bugfixes or course
Download MVP-1 (x64 windows only): http://root.xenorate.com/final/lman/lman_alpha_mvp1.zip
Attached are some screenshots - including the original paper idea from ~1995.
Move to the left / right:
- Keyboard (A or D) - Keyboard (Left or right arrow) - Gamepad thumb left X-axis
- Keyboard (Space) - Gamepad (X button)
- Keyboard (W or S) - Keyboard (Up or down arrow) - Gamepad thumb left Y-axis (only in digital mode!)
- Keyboard (E) - Gamepad (Y button)
What do you think about this? It it okay for the first mvp? Is it fun to play?
Dont be frustrated when you die a lot, it is not that easy at start.
Due of lack of time i had to stop the video documentation series totally :-( But dont feel down! I started last month working with unreal engine 4 again with very good success ;-) As a matter of fact i made more progress in the last month than in the past 2 years!
With UE4 i can fully focus on gameplay and not on writing engine code at all and this is very nice.
Currently i have a fully working platformer with working levers, doors, fixed and flooding lava, elevators, jumppads, spikes, getting hurt and die... all that good stuff. Elevators are fully dynamic and searches the next stop using line traces. Nothing much to add except moving platforms against checkpoints. Of course all fancy staff is not implemented yet and i plan to replace the crappy art with better ones when the gameplay is fully implemented. Maybe i will upload a video showing off when the gameplay is implemented.
Attached is a small screenshot.
Since last time i have successful continued the "Leverman Devlog" series and uploaded 65 episodes! It goes very well and we make steady progress towards a physics based platformer ;-)
We are at the point where we start creating the actual platformer with an integrated level editor.
What we/i have done so far:
- Rendering pixels directly on a canvas using AWT (Only use Graphics2D once to put a pixel array into a canvas) - Keyboard and mouse handling - Fixed and robust game loop - Numerical integration - Vector maths - 2D Rotation / Transformation - Simple collision and response - Drawing rectangles, circles and lines - 2D custom physics engine with a robust contact generator and 3 contact solvers with support for AABB, line-segments, planes and circles - Drawing visualizations for SAT, contacts and impulses - Contact state detection and cashing - Tons of math - Tons of refactoring
If you are interested:
Latest episode (German audio - but code is in english):
First episode (German audio - but code is in english):
half a year later i am back! The project is still going on, but in a new and much simpler way:
I started completely from scratch, including creating some sort of a design/story document to capture the game idea. Also i am recording every coding session for this project, including some heavy and detailed explanation - like a tutorial of some sort and it really goes very well, i am steadily making some progress ;-)
If someone is interested, you can follow it here - the only requirement are some skills in the german language
But i did finished the fluid dynamics integration in my last prototype i shown, but i dropped the fluids idea completely due to several reasons:
- Its incredible hard to tune the fluid properties to achieve a stable simulation for different kind of fluids - Trying to port the particle simulation to a GPGPU, was not that working very well. - After all, fluids are not a core-mechanic of my game-idea
Even though, you can see the result here (Prototype running with realtime position based fluid simulation and working one-way collisions):
Finally i have implemented edge and chain shape one-way collision support and it works great. Of course the performance was really bad after i used it in my actual game test level which does contains a lot of line segments, but i found a solution for that. I use two additional uniform grids to sort in the fixtures + proxy-index and use the exact same approach i used to detect the particle neighbors efficiently. Even for the first implementation this works pretty well - Simulating 1500 particles with 200 line segments runs at 60 fps without any multithreading at all.
The only thing which bugs me a bit, when i start the game the fps goes down instantly to - Creating particles initially using a active/inactive single buffer is not so good for performance maybe? - Uploading every final particle position to the GPU using FloatBuffer is not good for performance as well (Java is very bad at this) - Even with disabled particle system, the fps starts at But for the moment i am happy and i can focus on the actual game play mechanics.
Fixing performance will come later and also i have plans to maybe move the entire physics (particles and rigidbody) to the GPU entirely to get rid of any CPU>GPU buffer uploads and maybe port the game to c++/11 to have a much better way to handle memory and such.
One thing i will try which may be added in a few minutes (thanks to java) to move the PBF-Solver code into threadpools - so that performance should not be an issue in the meanwhile.
In my last post i have talked about using unreal engine 4 and such. Now after i have played a lot with it, i know for sure - this game can not be made with UE4 based on the gameplay mechanics i have mind and it will take at least a few years before UE4 will support what i need: Realtime fluid simulation based on particles. So i decided to drop that idea about using UE4 and try to make it myself, because there is no physics engine out there which do support a particle-based fluid simulation with mixing liquids including two-way interaction with rigid-bodies.
Of course i tried out "Liquidfun 1.1" and at the first glance it looked amazing, but after i used it seriously i was very dissapointed because it never got usable in any way. Particles just bounces off on every wall, like it was some kind of superball, the fluid was not fluid like at all and creating single particles just wont work - only group of particles which are part of some shapes can be created. I dont know why this had not worked for me, but after i have analyzed it a bit, it looked like liquidfun hates chain-shapes for some unknown reasons and my entire level are based on this chain-shapes, so this may be the reason why it was always unstable. I even tried it with cpp implementation, but this had exactly the same problem.
At that point i really was very depressed for a few weeks and have not worked on the game at all, but then i had a good talk with a very good friend of mine about that game idea. He had a lot of good ideas and so becomed that we decided to make it together. Unfortunatly he does only know programming in theory, but had never do any real programming at all, except for some assembler assessments in his school, but more importantly he had absolutly no clue how games are built - what a programmer must do to create a game, what a game loop is, how input is determined and how graphics are displayed on the screen.
Well that was the point where i decided to start completely from scratch and let him see every aspect of it - with a livestream like-way. Another reason to start it over again was the old engine i created - this was fully based on immediate and old rendering techniques. It worked just fine and after a few session we got the same result like before - a jumping character, a level and some camera which follows along based on OpenGL 3.3. After that we added jumppads, tuned the player movement a bit and we started to see some pictures coming together. You can see the results here:
But as ussual like i had expected this, i got demotivated and stopped working on that project - which was great for my family because i was not sitting in my pc-corner anymore and had more time for them and my friend was learning for his studies and had no time at all too. So the project was freezed for the time being. Until the start of january where i got boored and started to read tons of papers about particle systems, fluid simulations, physics simulations and many other advanced topics. Also my friend got back from his studies and we made more coding-sessions together with pretty good results. So i have implemented a fully working position-based-fluid simulation including one-way collisions!
You can see an early result here:
The best part is, that simulation is already integrated into our game framework and work right a way. Unfortunatly the performance for collision tests are extremly poor right now, because i have not optimized it yet. 2 * 2000 * 400 linesegment tests per frame are just too much. But i have good plans for that, i will sort this line segments into my existing uniform grid which i already use for particle-neighbor determination and use this to test only the line segments which are close to a particle - so i assume this will increase the performance drastically.... i hope.
In the last couple of weeks/months i was evaluating unreal engine 4 and see if it is capaple of handling the scale of this game better and faster than writing everything myself.
I will therefore now write down the evaluation process in some report/day like text form.
Starting from the first day (26. August 2014):
Installing was pretty easy, i have read all the requirements and limitations, created an account on unrealengine.com and activated the subscription. After downloading the engine itself ~ 50 mb, i installed it on my 3 year old alienware notebook on win 7. I started it and downloaded most of the free sample projects. The first project i had tested was the "ContentExamples" project - which i already knew about. Mostly all examples was working fine - in sens of performance, but after i opened the big example projects like "EffectCaves" or the "Realistic Rendering Demo" my System completely brokes down and i had barely 5 fps running in the editor view. It was not possible to select any actor at all - just too much for my system. But the worst was coming after i launched on of this examples in the game window outside the editor (1 fps at max) - while the editor was opened - absolutly unplayable. I knew that my system is crap, but i had not expected this to be this crap. When i really want to do more than just a simple stuff with UE4, i need to get a real system. After i have checked out every sample project, i was just starring at the screen and watching video tutorials for hours. On that time i was just fooling around with UE4, creating and testing stuff from tutorials - nothing special.
30. August 2014:
After a few days break, i got a much better understanding how UE4 works. So i decided to start creating a simple "learning" project - by making a simple breakout like game. Creating visuals for a breakout game, was extremely straightforward, but converting them to static mesh's and blueprints after that was not that clear at first glance and somehow such important informationen was not teached in any tutorials at all. After a few hours i had a working prototype, but with better visuals than gameplay, but it got a moving ball, a player controlled paddle and one brick - yay.
3. September 2014:
I dont know, but using real physics in a breakout game is so much pain - i taked me so many hours to build blueprint and configure a breakout-like gameplay... But i got it, i even added a angle correction when the angle is too square. Also i improved the visuals a lot by creating own textures, bump maps, added lights etc.
10. September 2014:
I finshed the gameplay prototype with generated bricks, fixed bugs and created a video, see:
Of course its not completely finished yet, there is still much todo:
- Creating and using player stats like level, score, lives - HUD for the player stats - Simple game menu with (Start, Options, Exit) or an introduction screen
- Fix: Sometimes the ball decided to not bounce of the paddle, but instead passing it along the side while colliding O_o - Improve the performance a lot, cause rendering a dynamic point light for each brick is not that great of an idea i think
Thats also the next steps i have planned. After i have done this, i will hopefully can create the "Leverman" prototype with UE4.
This will be my development diary for the game leverman i am working on - a attempt to create a game from my childhood dreams.
A bit about myself
I am in the start of my thirty's and do programming since about 20 years. In these past years i have created multimedia applications, tons of websites, ui applications, client/server applications, technology demos and several unfinished game-prototypes. I started with Basic on the C64 continued with QBasic and jumped straight into Delphi - a object oriented programming language based on pascal, which most of my past applications are based on. Of course i have learned other programming/script languages as well, like C/C++, Java, PHP, Python, VB, C#, Lua. Nowadays i code in Java because i use all days at work and like it, because its reliable, fast and are strong to build complex software designs. Sometimes i miss using pointers, memory allocations and all that low-level shit but i can live without it ;-)
In my childhood i have drawn "Games" on paper which was played by me using imaginary and fingers only. At the time i really wanted to bring those ideas to "live" and create games out of it, but i was lacking the skills to do it - i was really young and unexperienced. But a good friend of mine was somehow inspired by me and started to draw this stuff too, i even got him interested in PC, video games etc. But unfortunatly i lost all my drawings from that time and could never recall that ideas again - it was just lost.
Many many years later i visited that friend of mine and we talked about good old times while playing video-games and i found his own drawings accidentaly. I remember saying to him: "You know, one day i will bring this ideas to life". But even at that time, i still was not that skilled in programming to create such games. This was the point where i knewed that i wanted to be a professional programmer and thats what i am today.
Today in june 2014, i am starting to create this game i am talking about right now. Starting by creating a design-document and create my/the thousandth game-engine...
Yeah i know, everyone starts by creating a game engine first and realize later on - its not that easy after all. So experienced ppl just say, "Dont create your own engine, its a waste of time - use unity or whatever". But such comments just bounce off me, because i am a person who want to create everything myself, understand everything what happens in the background and have control of it - except for some low-level stuff like opengl, audio, input etc. I even realized that using a existing physics-engine is better than writing one myself and yes - i have written my own physics engine, so i recognized that!
Why doing a journal here?
Firstly, i think this will boost my motivation to work on this game. Secondly, this may be a good reference for me or others in the future, who like seeing a game from the near start to the end. Third, to get some feedback and may listen to experienced ppl ;-)
About the Game
Damn, that was a really long introduction and i havent written anything about the game itself at all -.-
Okay here we go:
It will be a physics-based platformer which makes heavy use of fluids and gases. There will be no enemies at all, but tons of traps! So fun is sure to follow ;-) The main goal for the player/hero will be to reach the exit for every level. Like most platformer the player can jump, fall and die. He will have live -and health points and also some items to pass unpassable areas in the future. Levers - hence the name "Leverman" will take a major role of this game, because levers will activate and deactivate something.
The game will be written in Java using the LWJGL Library and the JBox2D Physics-Engine only. The engine-architecture will be designed to support Windows, Linux, Mac and Android as well. The time will show how it will become and if the JVM is fast enough to handle that scale of that game, but i think the only bottleneck may be the GPU only. If not i will recreate that engine in C++ or just use Unreal Engine 4!
Lastly i can show you my initial progress of the game and engine with a fully working Entity-Component-System, integrated physics, basic rendering and some jumping rectangle . It taked me about effective two weeks (2,5 months) to create this. Hope you like it.