I have translated the English document below.
0. 들어가며
이번 Plus 업데이트를 통하여 최대 조건을 달성하였습니다. 이제 남은 연구 거리를 언급할 수 있게 되었습니다. 지금부터 언급할 해당 사항들은 실현 가능성이 매우 낮다고 판단하여 후순위로 밀렸으며, 이제야 언급된 것입니다.
그럼, 남은 연구사항을 작성하도록 하겠습니다.
1. 최적화
의존관계 이슈를 해결하였지만, 실은 옵션만 딱 하나 바꾸기 위해 넣은 의존관계까지 존재합니다. 이러면 그 옵션 수정을 위해 필요없는 모델링들이 대거 투입되는 비효율적인 상황입니다. 거꾸로 말하면 최적화 작업의 기대값은 맵이 가벼워져서 로딩 시간 및 단축키 충돌이 줄어든다는 얘기가 됩니다.
이는 추출을 통해 해결하려고 합니다. 그리고 아예 섬멸전 지도 세팅이면 해당 옵션 수정들은 필요없는 것으로 확인되어 더더욱 이 지점에서 퇴보를 결정하였습니다. 이러한 결론으로 인해 지도를 처음부터 재작성해야하는 상황이긴 합니다. 하하하 하지만, 제가 심각하게 보는 문제는 지도를 재작성하는 것이 아닙니다. 바로 이번 개발을 통해 알게 된 것 때문입니다.
의존관계가 지역 별로 다르게 세팅된 것 같습니다. - KR의존관계로 EU서버에 배포 불가 현상. 즉, KR 서버의 모델링이 EU 서버의 모델링과 다를 수 있다는 것입니다. 정말 이러한 추측이 사실이라면, 모델링을 추출하는데 각별히 신경 써야하는 상황입니다. 왜냐면 자칫 '검열' 영역을 침범할 수 있기 때문입니다. (이러한 점은 여타 다른 게임에서도 볼 수 있듯이 지역별로 번역은 알맞게 현지화 되어도, 캐릭터의 그림, 모델링 자체가 다르게 세팅되어 서비스되는 부분입니다.) 물론, 각 영역에서 모델링을 추출하면 되는 일이긴 하다만... 그래도 좀더 살펴보겠습니다.
최적화는 잠시 보류하도록 하겠습니다.
2. 밴픽 시스템
스타크래프트라는 게임은 사실 게임 시작 전에 종족을 선택하는 '픽'시스템이 기본으로 장착되어 있습니다. 하지만, 전설의 유산 유닛 셋이 스1+스2 이기에 단순 종족 선택만 진행하면, 굉장히 많은 유닛을 다뤄야합니다. 이는 유닛 간 수치 밸런스의 문제는 아니고 그냥 운영 자체가 어려워진다는, 게임 난이도가 급상승하는 효과를 만든다고 봅니다.
따라서, 픽은 이미 있으므로 차후에 '밴'시스템 만을 도입하면서 해결할 수도 있겠다고 봅니다. 실제로 만약 금지 시스템이 도입되면 전설의 유산 유닛셋 기준으로 몇 개의 전략 자체를 사전에 제거하면서 인게임에 들어가는 형태가 됩니다.
따라서, 금지 시스템은 종족 선택이 이루어진 이후에 진행될 예정이며, 상대 종족의 유닛 몇 기(현재는 약 5기)를 금지하는 형태로 꾸며질 것 같습니다.
하지만, 여기서도 짚어야할 부분이 있습니다. 주요 핵심은 각 종족마다 금지시키는 비용이 다르다는 점입니다. 예를 들어 [테란-불곰]과 달리 [저그-히드라리스크]는 금지시키는 비용은 다릅니다. 왜냐면 불곰은 딱 한 유닛만 금지시키면 되는데, 저그의 히드라리스크는 가시지옥으로 변태할 수 있습니다. 그러면, 히드라리스크, 가시지옥 둘 다 금지시키는 것이 됩니다. 이는 프로토스의 [고위 기사 금지] > [집정관]까지 금지 와 같은 상황을 찾아볼 수 있습니다.
즉, 유닛 하나 금지시킨다고 다가 아닐 것 같다는 생각입니다. 여기에, 동족전에서의 금지 시스템, 무작위 종족 선택 시 금지 시스템이 어떻게 적용될 지는 아직 생각도 못한 부분입니다.
이 부분은 더 고민 후 결정하도록 하겠습니다.
3. 채팅 신호 체계
이 부분은 위에서 다룬 게임 역학이나 공학 영역과는 다른 게임 법학과 관련된 이야기입니다. 참고 부탁드립니다.
스타크래프트Ⅱ 에디터를 연구하면서 든 생각이 클라이언트 기준으로 해당 프로그램은 마치 스타크래프트Ⅱ 게임 그 자체라고 보였습니다. 하여 저는 조금더 쾌적한 플레이 환경을 조성하고자 이전에 썼던 제 SF소설 부분의 극히 일부분을 한번 구현해보고자 합니다.
내용은 채팅에 대한 수위 구분을 자동으로 해주는 일종의 봇입니다. 자세히 말하면, 전 어차피 채팅 관련 신고나 채팅 차단을 해야하는 상황이면, 알아서 해주는 봇을 떠올린 것입니다. 이는 게임 플레이 기준으로 굉장히 쾌적한 환경을 제공하리라 생각합니다. 그리하여, 우선 채팅 수위에 대해 적색, 황색, 녹색 등을 점멸할 수 있는지에 대한 물음이 들었습니다.
샘플로는 이렇게 됩니다.
색깔 | 처리 기준 - 정의 | 처리 후 - 심판 |
적색 | 예시문) 육두문자, 비속어, 은어, 잦은 사투리 사용, 특정 신체 부위 비하 및 범죄, 테러 관련 발언 등등 해당 언어를 사용하는 국가에서 데이터 제공 (데이터를 개발자 및 사용자가 조회 가능) |
******** >> 적색 신호와 8글자로 해쉬화 후 별표처리 채팅 전체 내용 유추 및 추론 불가 채팅 배포 계정 정지 7일, 30일, 1년, 100년 |
황색 | 예시문) 흡연, 음주 등의 심하지 않은 선정성 및 폭력성 묘사 혹은 특정 계층 비하 발언, 3-4회의 짧은 사투리 사용 등등 해당 언어를 사용하는 국가에서 데이터 제공 (데이터를 개발자 및 사용자가 조회 가능) |
부분 출력 > 유추 및 추론 가능 채팅 배포 즉시 채팅 정지 7일, 30일, 1년, 100년 채팅 신고 지속 접수 시 심사 후 계정 정지 혹은 유예 집행 |
녹색 | 예시문) 표준어 사용 및 게임 내에서 사용하고 있는 단어들 위 데이터를 제외한 나머지 |
사용자가 해당 문장 판단 후 신고 처리 유무 결정 |
- 이 신호등은 채팅을 작성할 때부터 점멸되기 시작하여, 쓰는 이에게 어떤 수위의 글이 배포될지 미리 알려주도록 합니다. 그리고 사용자는 엔터 혹은 ESC 키를 눌러 최종 배포 판단을 마칩니다. 이렇게 되면 읽는이, 쓰는이는 모두 동일한 신호의 채팅을 볼 수 있습니다.
- 처리 후, 즉 심판에 대한 부분은 말 그대로 샘플입니다. 지역, 국가 혹은 게임 내 개인의 옵션 선택에 따라 충분히 변경할 수 있겠습니다. 그리고 해당 게임은 18세 게임입니다. 욕 먹을 짓을 했으면, 욕을 먹어야 한다는 생각도 해볼 수 있습니다. 즉, 플레이 자체가 빨간(황색)불이니 빨간(황색) 채팅을 보는 것입니다.
- 물론, 녹색 등이 점멸되어도 읽는이의 판단에 따라 신고될 수 있습니다. 왜냐면, 스타크래프트 즉, 우주전쟁하는 데에 집중이 흐트러지는 상황이면 고 부분을 일단, 침해한 거긴 하니까요. 이럴 때에 처리 이후(심판)는 잘 모르겠네요.
- 정의 쪽도 보면은 사실 일반 미디어 검열방식 떠올리시면 됩니다. 18세 이용가: 적색, 15세 이용가: 황색, 전체 이용가: 녹색. 딱, 그 기준입니다.
>> 신호등 체계는 남녀노소, 인종, 지역, 국가를 통틀어 가장 오차율이 적은 구분 체계(색약, 색맹 등 시 오차 존재)라 판단하여 채택하였습니다. 제가 이번 연구로 얻고자 하는 것은 심판에 대한 부분 보단, 정의 쪽을 얼마나 설계할 수 있는가에 대한 부분입니다. 정의란 죄의 값을 묻는 처벌과는 다른 개념이라 보고 있으며, 심판 전 기준 자체가 정의로 봅니다. 즉, 이 신호체계의 레퍼런스가 되는 '신호등'이라는 시스템, 정의 역시도 따지고 보면 남녀노소, 인종, 지역, 국가를 넘어 적용됩니다. 처벌은 다 다르지만 말이죠.
>>> 최종. 저는 이 신호체계를 제작하는 데에 큰 관심을 가지고 있습니다. 향후 어떠한 형태로 다시 개발될 수 있습니다.
- 생성형 인공지능이 제공하는 데이터는 작성하는 시기(2025-02-07) 기준에서 배제하기로 하였습니다. 사유로는 처리 기준의 명확한 오차율이나 레퍼런스가 제공되지 않기 때문입니다. 하지만 필자는 문명도 기준으로 정의 자체가 변경 및 발전될 수 있다고 생각합니다. 따라서, 인공지능을 도입할 시기가 되면 도입할 수도 있겠습니다.
---
2025.02.09
글을 배포하고 하루 정도 생각해보니 한 가지가 떠올랐습니다. 이미 작년 인공지능 개발자가 노벨상을 가져갔었습니다. 그 사실을 미뤄봤을 때, 내부적으로는 이미 오차나 검증이 인류가 받아들일 만큼 파악이 된 상황이라고 생각합니다. 이는 굉장히 고무적인 일입니다. 진짜, 인공지능 신호등도 가능할 수 있겠습니다. 어차피 클라이언트 입장에서는 적색 신호 데이터 셋이나, 인공지능 프롬프트나 다 API로 받을 구조겠죠...??
---
지금 다루는 툴이 아무리 강력한 프로그램이라 해도, 영역 자체가 법학이고 철학까지 언급되는 부분이니 말마따나 이 부분은 제일 현실 가능성이 없습니다. 따라서 언제든 백지화 될 가능성이 농후하다고 판단 중입니다. 그중 대표적인 이유는 만약 정말 본인이 이 체계를 구현하게 되면 뭔가 많은 것을 빼먹지 않을까 싶습니다. 또한 이걸 구현하는 행위 자체가 어떤 법적인 역학으로 인해 의미 없는 행위, 시간 낭비가 될 수 있다고도 봅니다. 요 설계가 어떤 가능성 자체는 보여주긴 했는데, 나머지는 솔직히 그냥 잘 모르겠습니다.
따라서, 이 부분은 별다른 구현 없이 언급만 하고 넘어가겠습니다.
0. Intro
The maximum conditions have been achieved through this Plus update. We can now mention the remaining research points. The items that we will mention from now on have been pushed down to the lower ranks because we believe that they are not feasible, and they are only mentioned now.
Then, I will fill out the remaining research.
1. Optimization
Although the dependency issue has been resolved, there is actually a dependency relationship that was put in to change only one option. This is an inefficient situation in which a large number of unnecessary modeling is used to modify that option. In other words, the expected value of optimization work is that the map becomes lighter, reducing loading time and Hotkey conflict.
I'm trying to solve this through extraction. And if it's an Melee map setting, it's confirmed that those option modifications are not necessary, so we decided to retreat even more at this point. This conclusion makes the map have to be rebuilt from scratch. Hahaha, but the problem I see seriously is not rebuilding the map, because of what I learned from this development.
I'm trying to solve this problem through extraction. And if it's a Melee map setting at all, it's confirmed that those option modifications are not necessary. That's why we decided to retreat at this point. This conclusion has forced us to rebuild the map from scratch. Hahaha, but the problem I see seriously is not rebuilding the map. It's because I learned from this development.
It seems that dependencies are set differently by region. - Unable to distribute to EU servers due to KR dependence. In other words, KR server modeling may be different from EU server modeling. If this speculation is true, you have to pay special attention to extracting modeling. Because it can invade the 'censorship' area. (As you can see in other games, even if the translation is properly localized by region, the character's picture and modeling itself are set differently and serviced.) Of course, it is only necessary to extract modeling from each area... But I will look at it a little more.
I will put the optimization on hold for a while.
2. Ban-Pick System
In fact, the game called StarCraft is equipped with a "Pick" system that selects a race before the game starts. However, since the set of legendary heritage units is SC1+SC2, if you just go ahead with the simple race selection, you have to deal with a lot of units. This is not a matter of numerical balance between units, but it just makes it difficult to control, which makes the game more difficult.
So, we already have a pick, so I think we can solve it by introducing the Ban system in the future. In fact, if the ban system is introduced, it will be in-game, removing a few strategies in advance based on the Legacy of Legends unit set.
Therefore, the Ban system will proceed after the ethnic selection is made, and it will likely be decorated in the form of banning a few units of the opposing race (now about 5 units).
However, there is also a point to point out here. The main point is that each race has a different cost of banning it. For example, unlike Terran-Marauder, the cost of banning [Zerg - Hydralisk] is different. Because Marauder only needs to ban one unit, and the Zerg's Hydralisk can transform into a Lucker. Then, you ban both Hydralisk and Lucker. You can find situations like Protoss' [High Templar Ban] > [Archon].
n other words, I don't think it's all about banning one unit. Here, the Ban system in Mirror Match, the Ban system in Random race selection, we haven't even thought about how it's going to be applied.
I'll think about this more and decide.
3. Chat Signaling System
This part is related to game law, which is different from the game mechanics or engineering area covered above.
What I thought while studying the StarCraft II editor was that the program was like a StarCraft II game itself, based on the client. So, to create a more pleasant playing environment, I would like to implement a small part of my previous science fiction novel.
The content is a kind of bot that automatically separates the levels of chatting. In detail, I came up with a bot that can help you if you have to report or block chatting anyway. I think this will provide a very pleasant environment for gameplay. So, first of all, we were asked if we could blink red, yellow, green, etc. about the level of chatting.
This is what the sample looks like.
Color | Processing Criteria - Justice | After Processing - Judgment |
Red | Example sentences) abusive language, profanity, slang, frequent use of dialect, demeaning of certain body parts and remarks related to crime, terrorism, etc Data provided by the country where the language is spoken (Data can be viewed by developers and users) |
******** >> Hash it with a red light and 8 characters and treat it with an asterisk Unable to infer the entire chat content 7 days, 30 days, 1 year, 100 years of suspension of chat distribution account |
Yellow | Example sentence) Description of non-severe sensationality and violence, such as smoking and drinking, or disparaging remarks of a specific class, use of short dialects 3-4 times, etc Data provided by the country where the language is spoken (Data can be viewed by developers and users) |
Partial Output > Can be inferred and inferred Chat deployment Stop chatting immediately 7, 30, 1 year, 100 years Suspension or suspension of account after review in case of continuous receipt of chat report |
Green | Example sentence) Use standard language and words used in the game Except for the above data |
The user determines whether the report is processed after determining the sentence |
- This chat light will start flashing when you write the chat, so the writer will be informed in advance of what level of writing will be distributed. The user then presses the Enter or ESC key to complete the final distribution decision. This will allow both the reader and the writer to see the chat with the same signal.
- After processing, that is, the part about the referee is literally a sample. You can make enough changes depending on your choice of options: region, country, or individual in the game. And it's an 18-year-old game. If you've done something to be blamed for, you might think you should be blamed. In other words, the play itself is a red (yellow) light, so you're looking at the red (yellow) chat.
- Of course, even if the green light blinks, it can be reported at the reader's judgment. Because if you're distracted by StarCraft, or space war, you're infringing on that part first. I don't know after the processing (Judgment) at this time.
- If you look at the definition side, you can actually think of the general media censorship method. 18 year olds: red, 15 year olds: yellow, overall: green. Exactly that's the standard.
>>The traffic light system was adopted by judging that the classification system with the lowest error rate (existence of color weakness, color blindness, etc.) in all ages, races, regions, and countries. What I want to gain from this study is not so much about judgment, but about how much justice can be designed. Justice is viewed as a different concept from punishment for asking the value of sin, and the pre-udgment standard itself is seen as justice. In other words, the system called the 'the traffic light', which is a reference for this light system, also applies across all ages, races, regions, and countries. But the punishments are different.
>>> Final. I'm very interested in producing this traffic light system. It can be developed again in some form in the future.
- Data provided by generative artificial intelligence will be excluded from the time of writing (2025-02-07). The reason is that no clear error rate or reference of the processing criteria is provided. However, I think that the definition itself can be changed and developed based on civilization. Therefore, we may introduce AI when it is time to introduce it.
---
After publishing the article and thinking about it for a day, one thing came to my mind. Already last year, an artificial intelligence developer won the Nobel Prize. Considering that fact, internally, I think errors and verification have already been recognized enough for mankind to accept. This is very encouraging. Really, artificial intelligence traffic lights could be possible. Anyway, from the client's point of view, they will receive all the red light data sets or AI prompts through API... right??
---
No matter how powerful the tool is, this area itself is a part that mentions law and philosophy, so this part is the least realistic. Therefore, I am judging that there is a strong possibility that it will be canceled at any time. The typical reason among them is that if you really implement this system, you will miss out on a lot of things. I also believe that the act of implementing this itself can be a waste of time and meaningless behavior due to some legal dynamics. The design itself showed some possibilities, but I honestly don't know the rest.
Therefore, I will just mention this part without much implementation.
---
2025.02.18
왜 내가 이 신호체계를 구축하려는지 깨달았다. 본인이 가지고 있는 이야기 중에 18세 글이 있다. 청소년 물인데, 청소년이 못보는 아이러니를 가진 것이 주 특징이다.
여튼, 그 18세 등급 소설 파일을 그나마 양심적으로 배포하기 위해선 정의가 필요한 상황이라 판단했기에, 일단 해당 파일 배포를 보류하고 정의부터 설계하는 데에 목적을 두는... 그냥 이야기 배포를 희망하는 많은 글방 주인 중 하나였을 뿐이다.
'LEGACY OF LEGENDS' 카테고리의 다른 글
스타크래프트Ⅱ: 전설의 유산 - 공개 테스트 Plus 설계서 (0) | 2025.02.06 |
---|---|
스타크래프트Ⅱ: 전설의 유산 - 공개 테스트 설계서 (1) | 2025.01.13 |
스타크래프트Ⅱ: 전설의 유산 - 공개 테스트 설계서 [지도] (0) | 2025.01.05 |
스타크래프트Ⅱ: 전설의 유산 - 공개 테스트 설계서 [프로토스] (0) | 2024.10.28 |
스타크래프트Ⅱ: 전설의 유산 - 공개 테스트 설계서 [저그] (0) | 2024.10.23 |