Monday, 25 September 2017

Why this is not the year of Linux

The success of operating system is directly linked to two features or main points. They are "user experience" or how easy the OS is to use and the second feature is development. The rivals of Linux get them mostly right. OSX is (or has been, this seems to be changing recently) easy to use, no one can argue about that. But I think OSX has big problems in development which is focused on Apple's way to do things and make everything else really hard. Windows is the biggest OS, because it has good user experience and also it's very good as a programming platform.

Linux users can argue about those points, but that's all you can do actually. Numbers don't lie. The small amount of "regular" (non-hackers) users are result of GUI versions of Linux that try to implement the user experience part. Casual computer users don't care about compiling stuff from source and updating libraries or whatever. They want to use programs. I've been programming over 25 years and just I want to use programs. I don't want to compile them or figure out what is happening in the OS itself. Another part of the problem is the way open source has failed to give us programs that are on the same level with commercial software, or even better.

Linux programmers seem to live in the same kind of haze than its users. They say how programming is really easy in Linux, but they use technology from 1970's like makefile. Everything changes all the time so you need to compile everything and watch out for library versions, compiler versions etc. Open source itself is an ideology which doesn't work in reality, because most developers want to keep their source code closed and also sell programs which means they need to be compiled into an executable that works in most versions of that OS. The open source ideology is the biggest problem Linux has and it's just as ironic as it sounds.

It's human nature to make everything more complex that it has to be. We can see this in computer technology and in operating systems for sure. They are bigger and spend more resources with every new version, but give us pretty much the same features. Somehow we fail to make things simple from both user experience and development point of view. Maybe we are too smart to create simple things.

Sunday, 24 September 2017

Teemu ARRP Diary 7/3

The null bug was in Get -routine of terrain tile. You would think it's hard to make a mistake in such a small routine, but it is. I was checking the index with 0 when it should have been -1 (out of level). That's why the first (top left) tile was null, but when the debug routine was not using Get_Terrain() it didn't catch it. I tracked it back from look routine which was showing the tile as 'null tile'.

The low level routines work I guess, masks are added to searching (Place class). I'm going through level themes one by one and there are issues with room generation etc. I think there are only two themes that need more work than just simple fixing. I try to keep things simple and work through themes first on terrain level, then second run adding objects and finally creatures.

A kind of "problem" that I run into all the time is that it's "possible" to make things in smarter way, but it just takes way more time than making things work using less sophisticated code. It's important to ask yourself what do you want to achieve in gameplay context and how to do it. If it's really complex stuff then it may be easier to create a complex system for it (in a long run). But if it's not then it's faster and easier to bash some random code and try to keep it bug free at least. Creating a sophisticated engine for anything is incredibly difficult and I think it takes a certain kind of mindset and skills to succeed in creating a coherent game engine that can process everything the game requires.

Thursday, 21 September 2017

Teemu ARRP Diary 6/3

The null tile or object is still a bit of a mystery, because I don't know what it is. Not even with a debug routine I made just to inspect tile's contents. The look routine is actually seeing it as null terrain, but the debug routine shows it's a real terrain tile. So I have to check out how the look routine is determining it's a null terrain.

Doorplace search is not working currently. The reason is that the search routine fails without mask data. To fix that I'm going to rewrite the search with mask tiles. But for that I need room masks that indicate the facing of the room, so each four main directions get a mask type. I've find this useful in Kaduria, because once you have set the direction to a wall it's easy to find it later.

I'm in a process of rewriting the room creation itself, because room has to use a special routine to determine the facing directions while it's creating the room.

Wednesday, 20 September 2017

Teemu ARRP Diary 5/3

Mask routines are now ready, but they aren't possibly yet used. The routine checking for object creation is including a check for mask. Anyway, level creation works the usual way, but there is a strange bug which has to be fixed before doing anything else. It's creating a null tile at the top left corner of every level. To find out more what it is in first place I really need to write a debug routine to show the contents of a tile.

I wrote a new debug routine to collect "togglers" which have value of true or false. The scope of this project is so small, that there are only two togglers at the moment: FOV and mask map tile, which is a routine that shows the mask tile using a color data assigned to it. That way you can make sure the mask map is correctly created.

The null tile bug can be related to place searching. I could make that better to spot by adding a debug id (for example a piece of text) to each call. You can then spot which routine called the search for list of tiles.

Tuesday, 19 September 2017

Teemu ARRP Diary 4/3

The mask data was moved to Terrain_Tile which is a tile of the terrain map in base class of Level hierarchy. It was just much better that way than storing mask data to Display_Map, because it started to get weird with access to Display_Map instance from Level class. Now the data is pretty much where is belongs. It takes more memory, but that's not an issue, because levels spend quite small amount of memory. The data is reset when the save game is loaded, but it's also not a problem, because the mask data is useful only when creating the level.

Today I could try to finish all the routines which actually use mask data. Sometimes using mask is a lot easier than finding out particular terrain tiles, but sometimes you need to find specific type of tiles to create some stuff on them. That's why both systems need to work together. The mask is set using default values for terrain and later when creating rooms etc. it's written over with new values. I find one of the hardest parts of level generation is the way you decide what can be created on a single tile, with often complex rules and special cases.

Sunday, 17 September 2017

Teemu ARRP Diary 3/3

Today I didn't get much done. I noticed that there are some problems with generation routines, because a mask data of tiles don't work. Mask value for tile is useful feature which I'm going to implement for Teemu the same way I have in Kaduria. The mask system has two types of masks, a regular type for terrain tiles and room mask which is a number given to a room or other similar type of area.

It's sometimes useful to assign mask values to tiles that aren't that tile's default type. For example in situation where you want to exclude a part of level from creation. Room masks are also useful, because then you can create stuff in a specific room, and when you have assigned only tiles of that room to a mask id it's easy to find tiles of that room later during the generation process.

I didn't have time to program that feature yet, but I'm planning to put that into Display_Map class which is re-created for each level when you enter it. That way I don't have to store mask values in each level which could be useful in some cases, but I think in this game it would just waste some memory.

Teemu ARRP Diary 2/3

It's already sunday, but I partied so hard that I forgot to report my progress. I confirmed that loading from text data works and it can also remove unwanted spaces etc. The parser is only about 20 lines of C++ code, but it can only get and store pieces of text. However it could be interesting to make it more complex, because I have been thinking about using external data.

Next I wanted to fix re-making of level for testing. The problem was and is that for some reason I have a "static" list for stairs which are copied to each level instance. That's why I can't just delete the level instance and make a new one, which would be the best solution. So I spent some time writing some routines that clear some things from each level class from the hierarchy. It probably works ok, other than the first level size will be always same. This could be changed, but some level themes should keep the size, because there are multiple layers of that same level. The lighthouse for example, it has multiple levels with the same base level stored in World class. There is also a bug related to that, because when you go at the top level it's a copy of the beach. This means you could change something in the beach and it wouldn't show in top level. Copying terrain tiles to top level every time the player enters there could be easy, but game objects are more difficult, because if they are copies it could create some interesting problems. That's why the interaction must be limited when you are on top of the lighthouse.