Letter-Setter. Notes about one game development. P2

[hr][/hr]

Having formed a rough understanding of what the game should look like, I began the prototyping stage. It took me less than a week working on evenings to make the first playable version of the game, and it included the following features:

• field generation. It incorporated Scrabble letter set distribution with its time-proven balance.
  
• tracking the completed words downward in columns and from left to right in rows. Several problems arose immediately:
  
  • firstly, randomly generated field contained finished words, so the game was playing itself without any help from the player;
    
  • secondly, multiple intersecting words could appear (the question was, which word should the game choose and count?).
    
• moving letters across the field. It seemed simple but happened to be challenging as the initially conceived tile-matching mechanics implied swaps of adjacent elements. In our case, it greatly complicated the long words composing process, when someone was trying to do it by moving letters from one edge of the field to another one.
  
• checking the field for the appearance of new words after each move. In addition to the above problems, there was another one: the letters the player preserves for future could be destroyed while several other moves were made.
  
• completed words destruction.
  
• addition of new letters in place of the destroyed ones. And again, we face the problem regarding the game playing itself.
  
• a scoring system for the letters destroyed. Grateful acknowledgements to Scrabble for the scoring system proven over time.
  
• local leaderboards.
  

But despite all problems and flaws in initial design, the prototype was playable and the gaming process could bring some satisfaction. But the problems were real and I had to be solved! Some of them were purely technical and turned into bugs, while others required a bit of work on the design.


At first glance, the problem regarding intersecting words did not seem to be a problem at all: chose the one that brings greater score, and you're good to go. But from a tactical perspective, the player may preserve some letters for the next move by destroying irrelevant ones within less high-scored words. To address this, I have introduced an additional step that allows the player to resolve disputed situations at their discretion, with the ability to disable this step in the settings.

The issue regarding moving letters across the field seemed more serious because the tile-matching mechanics did not work properly in our case! Surely, some kind of time-stop mode prohibiting the game from reading the words until all shifts of the current move are done, could have been introduced. But then it would be easier to abandon the idea of shifts and make new words by clicking the letters across the field.
Apparently, our concept, at the very least, required the ability to drag the letters from one side of the filed to another one. It does not resolve the problem completely, but reduces the number of moves needed to compose a long word.
When implementing the concept, I have tested the waters and came to the conclusion that by dragging letters from one edge of the field to another one, we also move all other letters on the way (they are moved as if we moved them one by one). That is, with the right skill and strategy, we can change the entire field in one move. And this solves our problem completely! Of course, there's much less of tile-matching mechanics left, but a bunch of other, more tactical elements, appear.


But in a word game, the gameplay is only half the battle. The core of the game is words, so we need a dictionary to work with. It was pretty easy to find the database to run some tests. However, it contained a lot of words that do not fit the category of common nouns in their singular nominative case. Additionally, it contained duplicate words and symbols from different languages left after digitization. Perhaps, today one can use ChatGPT to form the dictionary that meets such requirements, but back then, all the questions had to be solved manually.
One of the tasks was to make the game that supports multiple languages, but unfortunately, my knowledge in this area was not extensive. So, at the outset, I needed to add at least two languages: Russian and English, and provide the ability to add new languages in future.
To form a Russian dictionary, I looked towards two dictionaries – The Dahl’s Explanatory Dictionary of the Living Great Russian Language and The Ozhegov's Russian Language Dictionary. But there is almost a hundred years' difference between them, and the Dahl's Dictionary contains too many outdated words. Therefore, I limited myself to the Ozhegov's Dictionary. One more reason to limit myself was the necessity to select words manually, filtering out definitions and etc., and leaving only nouns that meet the requirements. My friends helped me with this work in their spare time. When dealing with one's native language, it's easier to detect common nouns in their singular nominative case. However, the situation with my English dictionary was worse. I have found an English dictionary similar to the Ozhegov's one, with plenty of words and descriptions, but it contained too many unfamiliar words, and it was exhausting to search for their translation in online services.

Time passed, and the work had to be done... The progress was slow and the task began to become tedious. What had to be done? That’s the point – we should let machines work for us! And yet back then ChatGPT was just a prototype, our fairly routine task had a certain sequence, which meant it could be automated!
Dictionary parsing follows a simple cycle:

• take a text line,
• split it into words,
• remove the words that have lready been added to the dictionary,
• remove the words that have already been deemed unsuitable,
• the remaining words are either added to the dictionary or marked as unsuitable,
• take the next text line.

It doesn't seem like something very complicated, but when it comes to analyzing several thousands of words, it appears to be a torment. So, I have written a program that executes this cycle. Therefore, human interaction has been reduced to sorting the words from the screen into two categories - into the dictionary or into the bin.
It seemed to be better and faster, but defining the words’ category was still time-consuming. And this could not have been automated; because the final choice was still up to the human.
To ease the workload even more, I have added hyperlinks to the program, so I could find translations and word meanings in case the word turned out to be unfamiliar. These hyperlinks simply opened the necessary link in a search engine or translator, but there was no need to copy/paste /type the text manually each time I bumped into a new word.
The work moved from a dead center and gained momentum! It was still time consuming, but it didn’t seem so unfeasible anymore - in a couple of weeks (not a big deal, yeah?) a small English dictionary was completed! And not only one, but two of them (I mean Russian and English). But I didn’t feel like incorporating some other languages thus far.

When forming a dictionary, I find this prosses to provide similar experiences to those experienced when playing games, and gained some practical utility as it helped me in learning and understanding the language. And the thought occurred to me: What if I add a small educational element to the game? Players may experience the same desire to find out the meaning or translation of the word they have formed. Since sometimes you remember a word you heard somewhere, but you have never searched for its meaning.
And I want to be clear here: I failed to eliminate automatic destruction of completed words. Unfortunately, people haven't learned to read minds yet, and the field is checked for composed words after each move. I didn't opt to add a full-fledged educational mode allowing to see the translation of a word into a target language and its definition directly in the game, because I am not my worst enemy. But it was easy to incorporate hyperlinks - the mechanism I used in a program forming a dictionary. Apparently, the result couldn't be called a full-fledged educational mode, but it eliminated the need to open the browser and manually type the word. Automation it was! The option to choose the target language and the preferable translator, as well as the search engine, was added to the game settings. And this is how a couple of dozen lines of code have opened the door to the world of educational games.

Then it was time to beef up the project a bit!


Firstly, we need to reward the player. Besides, we have already introduced a scoring system and the leaderboards. A quick brainstorming session resulted in a simple list of bonuses: for composing long words, for the number of words destroyed per turn, for the whole row or the whole column destruction, for destroying some part of the field (20%, 40%, ect.), for the whole field destruction. Ultimately, all of them were introduced into the game, because the more, the merrier: the player should be appreciated, inspired and praised.

Secondly, we should provide the player an opportunity to suffer. We have already incorporated a basic mechanics that worked well, and so it was time to add some modifiers that would make the gameplay harder. So, in addition to the existing "meditative" mode, where nothing restricts or spurs the player, we have added two other modes: step-by-step mode and limited time mode. The names of the modes are self-explanatory: they harness simple mechanics of limitations to enhance the gameplay variety. But this variety appeared to be unclaimed within the players, because they didn’t want to be additionally stressed in a game that by default demands from them to search for the words in a pile of letters and move the latter across the entire field, considering the best trajectory! Limited time mode designed to fuel tension didn't work it well either. So, unfortunately, both additional modes have not gained much popularity within the players. But if the player wanted to suffer, the game would provide this opportunity to him!

Thirdly, the player needs a set of tasks that form the game progression. But without understanding, whether the player is learning a language or just playing for fun, it's hard to assess his progress correctly, if at all possible. That brought an idea to add some other modes that would introduce an element of progression. I wanted to make the player learn something new (if he wanted it) and monitor his progress (welcome back to the educational mode). At first, I thought about Morse code learning mode, but I had to put this idea off as drawing dots and dashes in small square tiles designed for letters would not be an easy task, and the result would not be aesthetics. But the idea was so captivating, albeit deviating from the original concept of "advanced tile-matching word game" to an educational project, that it was soon followed by two other ideas: to incorporate Braille learning mode that focuses on a tactile writing system used by people who are visually impaired and Sign language learning mode that is mainly used by hearing impaired people.

At first, both modes completely replicated the functionality of the standard one, with letters substituted (as if another natural language was introduced). But if you are unfamiliar with the language, it's impossible to make up the words in it. And so, it was time to recall why had I started all this? Because I wanted progression! And both systems fit this aim perfectly, with the letters being opened gradually after several mini-quests on making the words containing the last opened letter of chosen mode are completed. Again, it can’t be called a full-fledged educational mode, but when new letters are opened, new neural paths are formed. So, it's a win, yet it is small one.


And then, with the game having gained the weight, it was time to define its appearance.

[hr][/hr]
https://store.steampowered.com/app/676320/LetterSetter/