Language design: class

With my limited intelligence I had an idea to start designing my own programming language. There are some examples of the syntax in Roguetemple forums 'My language' thread that has had zero interest. I don't know, I'm pretty stoked about programming languages.

When it comes to really important stuff in a language it's how to manage data with functions and/or classes (or something else). My current understanding about class is that it's a nice theoretic idea which most often simply breaks in real life situations. That's why we have those getters and setters and the class can be exposed or it's not going to be neatly modular piece of code. Also in my experience inheritance is way harder than people think at first.

Functional style has different way to handle data which also is highly theoretic when you think about so called pure functions. In reality most functions are what experts call procedures in that they change whatever data is input to them.

My vast experience tells that both classes and functions have their problems and also both work better in different situations. The obvious question when designing a new language of course is there a way to solve those problems in some way? Or do they even need to be fixed, maybe they simply always exist no matter how you try to prevent them. It's like removing pointers from Java, did that actually fix anything important? Sometimes languages try to prevent the dumbness of programmers and they take it maybe a bit too far.

I've thought about one way to relieve data handling with something called resource block which is a collection of data that can be optionally limited to some classes. This data is like static data in C++ that it's initialized when the program is started, but it could be possible to change it. I'm using that kind of data in my C++ projects all the time, but there isn't any kind of built-in way to handle that data in C++, you have to use namespaces to hide it etc. By the way, I don't think I'm going to have namespace in my language, because I think it's fixing a problem that should not be a problem in the first place.

The daily maze news

The maze routine itself works, but it has to match in the rest of level creation. The way I accidentally solved it in the labyrinth level (the only level using maze for now) was make the maze routine "continue" from itself, the tiles it has created in previous "hives". A hive is one instance of maze diggers which are the corridors of the maze left by replicating diggers.

Sometimes it happens that everything runs into a dead end, usually a digger winding on itself. The fix for that is create hives until X number of tiles created. I found out that the number of available wall tiles divided by 3 gives a good result. The reason for that only roughly 50% of maze area is floors, the rest of it is walls. Not a surprise there. But if you divide it only by 2 it seems that the routine can't fulfill the requirement of mazes to create and runs into an endless loop.

There are some questionable things in this method where I'm first creating couple of rooms and then shooting mazes from walls of those rooms. Most important question: are rooms always connected by mazes? For number of test runs it seems to be true, but I have a feeling it could fail in some rare situations. If it happens it's still possible to check each room for connections and create them later with manual style, but I'd rather wish the maze routine work in reliable way.

Yard

The structure generation of Cornucopia is ready, but still needs some tweaks like room types and interior generation. Maybe the smallest room size could be 5x5 rather than 4x4, because smaller rooms tend to squeeze themselves into strings of rooms which don't always look that great.

The green rectangles are yards. It's a feature that can come after a room (as the yard of the room) or as first feature. I think it's a rare, well, feature in roguelikes to have yards in the dungeon.

After those tests I added two different room types randomly to make it more colorful and it does work quite nicely, when you have more room types than just one. At the moment there are only three features: room, yard and corridor, but I think it already looks nice. The interior is more important than the "shape" of the feature anyways.

This routine is probably going to replace 'small room' routine used in various level themes and I like the idea of "layered" generation starting from basic dungeon and then adding stuff like this.

If there is one thing that bugs me it's that backyard in bottom right corner of the screenshot. It doesn't seem to have a door connection which could be some kind of rarely occurring bug. So maybe it would be wise to create important stuff like stairs only to the basic cave area.

Frost

It was somewhat cold this morning (-15C) but also foggy which is quite rare at least in here. It's creating some spectacular looking frost on trees:

As imaged using my potato Fujifilm X10. Frost is like strings of crystallized snow which I guess is formed when that warm foggy air is attached to end of the string in wind. Or maybe I'm just guessing.

About that Cornucopia generator. I've fixed double walls which is generating quite nice looking rooms, since some of them become irregular (not strictly rectangular) and also made the corridor creation. In that I realized you can't create corridors before the next feature is made so corridors need a special routine to allocate their space with Restricted mask type. The only things left are different sizes for each feature type which has complicated the routine somewhat, but in the end it will be useful to have, and then determining which kind of rooms the generator is creating.

Cornucopia

Finally starting to get somewhere with the feature creator which there is a class Cornucopia for it, because my naming skills are perfect. I had problems with reverse connections and the way next feature is adding a connection to previous feature later. I have two examples to show with rooms as features. Later features can be anything, but mostly corridors. The minimum size of rooms are 5x5 tiles, but they could be as small as 3x3 to squeeze them in smaller spaces.

This first example is actually a very rare "failure", because it has five starting points (rooms) as feature parameters, but no clones at all! I was amazed when I saw this, but it's possible that rooms are made in a place where they can't clone, because they can be only made in a solid rock, not on top of the basic dungeon which is a drunken walk generated cave. However, when you increase starting points it's less likely for this to happen.

This second example is more from extreme end where almost all free space is used by clones that all started from five starting points. It's possible to reduce this kind of generation by giving each feature less than 3 exit points to only clone from 1 to 3 directions randomly. Also the percentage value of created floor tiles can be a limit to the amount of features.

Sadly, this routine is far from ready. One problem seen here are double walls between rooms which are the result of features looking for free space without generating over the existing room walls. But it's possible to remove double walls later and expand the space of one of two rooms sharing a wall.

Feature creator

For basic cave level I want to try something new with rooms and corridors. I don't know if this routine has a specific name, but I have seen it before. It's filling the level by searching for next free place for a feature which can be something like room or corridor, or whatever. I guess features can also make branches so in fact this is somewhat like a maze algorithm, just with larger building blocks.

I don't actually need anything new for this algorithm, only the sequence of creation is something that has to be arranged using building bots like the maze routine does.

I think this is going to be the last big algorithm for level themes, then there are some static themes that need some work. Even I have tried to keep things simple it's taking quite a long time to finish 1.3, but I guess this is roguelike development.

Procedures in C++

This is something I must have been mentioned before, but let's recall it. C++ is mainly object-oriented but I've realized that procedures work in situations where objects are not needed. Usually small generic routines and algorithms are good as procedures, because they follow the rule of not changing any dynamic data (objects).

It's ok to create classes for small tasks, but in some cases it becomes a bit clumsy when you need to create instances for extremely small things. Also, procedures tend to relieve the problem in classes when you create repeating code for each class, because inheriting is often not possible to do with any kind of working logic. This inability to use effective inheritance is one of the biggest problems in OOP at least for me. It's not easy to plan good class hierarchies that are safe from difficult changes later.

There is a place and time for procedures, but I think they are extremely bad at handling dynamic data, because then you easily lose ownership mechanism which is one of the strong features of OOP.