Wayyy tooo loong since my last entry... A lot has happened but for better or worse it's all good now. First I apologize to everyone (especially me) for my absence. And there's no second.. kek.

     Have you read a horror story lately? Cause you're about to read on now. 

                                                                                                  Chapter 1:
     Once upon a time a wanna be game developer updated his engine and a 95% ready game just got 1% ready.

     Well though the beginning is horrifying the end is happy. So lets clear things out now. I'm at fault here because I didn't have a back up and the problem isn't in updating the engine itself. It has more to do with opening the project with the new version. I have 2-3 version of the same engine, depending on the number of projects and on which version each the project is created. So when I opened the project on a the wrong version it happened. No data was lost. I don't know what happened but on some levels the game didn't work properly, some blueprints were messed up etc. In retrospect it could have been much much worse.. Anyway I started salvaging and patching up the game. After each major fix I made a backup. Now I make backup of everything, sometimes a backup of the backup.. 

     After much salvaging it came to a point where it couldn't be fixed..That was the worst feeling I felt since the start of my journey to become a game developer. There were couple of levels which I couldn't fix, be it because of my of lack skills or knowledge. After some thought I started migrating the working parts to a new project. My plan was to redo the broken beyond repair stuff(levels). An that's what I did! Frankly the redone levels are even better than before(duh!) and at least there's a plus to all this nightmare. So after much copying, constantly going between projects, doing backups, doing backups of the backups, checking if everything works after each 'new' level I was able to do it and it worked!

     I think this experience got me closer to the game developer (and idiot) title overall. It's one of those things in one's career who everyone else has gone through. Till next time when I'll put a name to the game!

It's being tested! Finally I made a so called beta and Kensei and friends are testing it. Well to be honest it was betas, because the first beta didn't work properly. After he gave me some critical feedback I.. well I'll write about it in a second. All in all the game is nearing its development cycle and the closer I get to finishing it the more impatient I become. There were many things that chaged, especially control related.

     One of the the major things that was pretty obvious for the testers and not me was the lack of air control in the ball. Such a simple and small thing made a big difference. As a whole the control of the ball sucked! I was comfortable with it because I developted the thing. There is probably a term for this kind of situation.. Anyway beside lack of air control the ball felt heavy and not flexible enough. If a player didn't knew what was coming next in the level he would surely fail because the steering was slow and flegmatic. Ofcourse it was very hard for me to see this because you know.. I created the levels. After more testing the controls and feel of the ball was near perfection. Now it is easier to control the ball and you feel more flexible and more in control of situation(because it is easier to control the ball..yeah). And I think this is a both mechanical and design topic about game development. Let me explain:

     The difficulty of the game is going to be leaning towards hard. Now you could create a hard game in the context of the controls of the ball. In other words the obstacles are hard mainly due to the controls. Not that obstacles don't pose a challenge by themselves, but the difficulty comes from for example a slow turning rate -> the player needs to start steering as soon as he/she figures out he needs to steer -> if the players is a little bit late -> fail. Lack of air control -> player jumps towards a moving platform -> he/she didn't calculated correctly the speed of the platform -> fail. Now some may say that this is somewhat casualization of the game and I see the point. For instance if the player didn't calculated correctly the jump why shouldn't he/she be punished for that mistake? The answer is that he/she should be punished, but also should have a chance to correct the mistake if it's small enough. That is the main thing that I think and feel is the problem here. Not that players shound't have second chances (except for game which are designed with this particular purpose) but a second chance should be obtainable ONLY if the mistake is small. After seeing the difference when I adjusted the controls I believe that difficulty because of "bad" controls is to be avoided (unless ur like an exa pro and know ur stuff). Just like a self-respecting horror-survival game should not rely only on cheap jumpscares. Every thing has it's place.

     Now after adjusting the controls it was time to adjust every obstacle on every level!  Cause now the difficulty shifted from the controls to the actual obstacles. Everything seemed too easy and easy does not have a place in the game! The end result is that the player feels more free, more in control and is still challenged. The levels got even more polished. It was good that the obstacles were easily scalable. Now that everything is good I await more feedback. I think that there will be only minor adjusments but we'll see.

     Hi! Long time no see. Believe it or not my last post has been the hardest to write so far. Prolly I need more adjusting. This writing "thing" is somwhat new to me. I usually like things to be in my head. The other thing I'll adress is the lack of consistency with the devlog. As these two months were very busy I was unable to find time to write on my progress with the game. I will correct that in the future.

     This time I'll write about the importance of creating guidelines before starting or in the early stages of the development. I as a noob started creating level after level, section after section, obstacle after obstacle. The only thing I tought about was how this current section worked and looked. I didn't think about the height of the floor for instance or the transition between obstacles or the flow of the whole level. I wasn't without a plan thought. Like I said the the beggining I knew what the general feel of the game should be but I stopped there. I should have gone deeper than that. But now after creating 8 levels and going throught each one atleast 3-4 times I have those guidlines I wish I made before starting. They somwhat naturally "came" to me. Like in the beggining the floor height was different. Sometimes it was 1.5 meters, other times 0.75 or some random number like 1.23664785. But after putting block after block I saw that 0.5 looked just right so I then had to go back and make all other blocks that same height. That had some problems, nothing serious though just extra work. In the game I have rails like train rails but here the ball rolls on them. Depending on the space between them the ball rolls smoother or not, or just falls.. So without turning my brain on I just made them different every time. Finally after the 4+ iteration on I don't remember which level I noticed that the ball rolled great and looked when the space was 1.25 meters. The sphere itself has almost the same diameter. There are more examples like this but I won't bore you with them. Suffice to say that although each one doesn't take that much time to fix, when you take them all you lose alot of time. It's subtle so you don't really feel the magnitude of it.  Ohh the lttle things..
    Here is a list of the things I wish I knew before starting:

1. ​Floor height. (yeah thats right)
2. Space between rails.
3. Standart coloring of different shapes. For instance a cylinder is black, a rectangle can be grey, dark blue etc.
4. Level progression - after a hard obstacle there will follow an easy-medium or easy obstacle.(that right here is a time consumer)
5. To make a blueprint of things I suspected I'll be using more than once. 

Thanfully that's all.
     
     After realizing these blasphemous  errors I went back from the first level to the last and enlightened them. I myslef was amazed of the quality jump after these little things were adjusted. There was one level that was made so bad that I just redid it entirely. Now that same level is one of my best works (according to me). Soon the game will be ready and my worst nightmare will come and that's...  naming the damn thing ofcourse!

      I've finished with the levels revolving around a single mechanic. There aren't that many mechanics to begin with so... yeah. Now, after correcting some of my grammar mistakes in my previous posts I'm ready for this one.

     As the title says, the workflow is getting better both in terms of quality and quantity. Well it doesn't exacly say that, but that's what I mean. It becomes easier and faster for me to design and create levels. Blueprints are less messy also! Much win here! I don't know if this is the reason for this but, I think that creating levels which focus only on 1-2 mechanics and sqeezing everything (well not exacly everything) from them pushed me towards this progress. Now creating something fun and challenging is easier (still not easy).
     
      Soon I'll begin the last iteration of the levels and after some testing the game will be ready. I had an idea about how to finish the development of the game but after some talk with my partner we agreed that it wasn't necessary. Maybe I overthink and take things too seriously about this game. It's a game about a rolling ball after all. Nowdays people make these kind of games for their homework assignment (or so I hear). Or maybe that's the way people think just before they release a bad game. I don't know. For some time now I think it's best to balance things out. Currently it's hard for me to pinpoint which aspects game are in need of a hard and "deep" thought and which aren't. For this game I really thought about the way the game looks and feels, the vision more than anything else. And I don't mean only the colors. More like the shapes and the level design. The shapes are the most simple and yet have big an impact. For instance in Unreal 4 there are two types of cube assets. One is a standart and the other is rounded along the edges. Choosing which type of cube to use can have a big impact on the atmosphere of the game. Ever played a game that feels great and is just awesome? But when asked you can't tell what exacly makes the game so good. Well I think it's a combination of a good design and subtle little descisions like that (obviously plus excellent programming, audio and etc). So small things matter, yeah yes we all have heard it before.

     Does knowing this help? Well yes! Buuuuut this was an example which is easy to implement. Usually small things which show how much you care are quite tedious and time-consuming. So you as developers need to know which things are worth it. Your time is precious. Note that I say 'you' because I don't consider myself a game developer until I release minimum 3 games. And I mean finished quality games from start to end.

     This time I will write about mechanics and somethng like a checklist. Remember when I wrote that the game was 3/4 ready? Well now it's 2/4 ready so that's that. Funny thing how the more work you do, the more work you need to do (or realize you need to do). Prolly some of them traps we rookies get caught in.     

     Apart from not being named yet, my game is evolving pretty good if I may say myself. In the beggining apart from the design document I wrote (and didn't use) I just had vague toughts what the game was supposed to be. I just imagined it in my head and kinda 'feeled' what I wanted players to feel when they play it. So I worked towards that. Currently the games revolves around the following mechanics:

1. Simple jumping.
2. Slippery surfaces.
3. Falling objects.
4. Floating objects.
5. Rotating objects.
6. Objects changing size.

All of these came one after another during development. Because the way I  work currenltly is like that: I start from somewhere, like putting a starting platform for the player and the just work onward, doing things from there after, building the level while keeping some rules. After every section of  the harder obstacles there aways follows something easy, something no-brainer which relaxes and lets the player regain his/her focus. And 2-3 times in each level I create larger platforms, where the player can move more freely. This leave space for things with purely aesthetic purpose and lets me do even harder obstacles because the way I put them in a spiral like way ensures that should the player fail, he/she will fall on the ground. And in the time of the writing the last sentence I realized that this is kinda bad design lol. If the player knows that failing will not kill him then these harder obsticles are more like a chore than a challenge. I think this takes away the fear of failling from the player. So like that this rule will not be in the game, and from text which was going to aim at mechanics I had ended up writing about design.
​
     I have decided that I won't add more mechanics no matter how good or interesting they are. If i keep up like this I won't finish the game anytime soon. So even if the mechanics are simple they need to be fine tuned so it doesn't feel weird. Even a simple jump can be made wrong. Currently I'm trying to get the most of each mechanic by building levels which revolve around only one or two. Well the jumping is the core so it will be everywhere ofcourse.

      So in this devlog I will write about the games I'm developing, what I encounter, what I struggle with and my toughts about it. I'm doing this for mylself as much as for you readers (if any right now). It's one thing to think about stuff but when you start writing them, then you really see where are the problems, so in a way this is also part of the development. Note that for now this devlog doesn't have any structure. I will write whatever I feel like be it just toughts, a checklist of things I need to deliver or just a particular mechanic that's given me headache trying to implement. There may be restructuring in the future.

     So even thogh i have made 3/4 of my game I still can't name the thing. But first lets go back to the beggining. This whole game started as a way for me to get comfortable with UE4, so I needed something simple. My first, unpublished yet, game was made with Unity. I got really hooked with it (both the game and Unity) and got really comfortable with it. But then UE4 happend and we moved to it. Good  descision, but it slowed our progress. It is better in the long run though.

     So about this unnamed game of my. Well, the game is about a rolling ball. You play as the ball and go throught an abstract minimalistic world. You need to react fast because this world around you is dynamic and changes constantly.  When you roll yourself throught each level you can't  predict how things will change. Sometimes what looks like a straightforward and easy path turns out to be an deadly trap.

     That last paragraph is everything I want this game to be. I don't know if this sounds simple or not but before I started with the game I wrote a "design document" 2-3 papers long. There I had a checklist of all enemies, powerups and neutral stuff. The ball could be destroyed or turned into a cube and there were 4-5 kinds of balls - glass, rock, rubber etctetra. Looks alot more ambitious than what I am going for now doesn't it. Almost everything from that didn't go into my game. Now people who are in the business know what I'm facing. Scope management. Although I am a newcomer to game development, I read alot of articles about game development, game design, everything game related and expected something like this to happen. 'Hey I may be a rookie but I won't fall for any of these traps, other rookies fall for' I said to myself. And to be honest I didn't fall for most of these traps. But the ambition to create some grand and complex game with 53645 hours of playtime without dragging it got me. No matter the type of the game, the premise, the genre, I want the game I make to be 'grand and complex with 56675..' you get the idea. But before that I first need to make small, simple games with less content and more quality put into them (not that I will put less quality into games with more content), and that's what this unnamed game is here for. The third paragraph about the game is what I want and I plan to deliver.