I'm a desops engineer and game system designer.
You might say "Hol up what is a desops?"
Well it's a composite word of "Design" and "Operation". Desops is all about integrating a design process and an operation. While operation in a game design field is not quite intuitive at the first time, however it is not so different from traditional meaning of operation.
Operation is a task to manage and serve a product. Deploying a product into multiple servers, reguarly checking server statuses etc. These days, many companies have accepted devops process therefore concept and role of pure operation team is not quite so distinctive. Still, operation's core part is about management and service.
So what is an operation in game design? Game design operation is about managing and serving game designs to developers. Game design has multiple aspects. Firstly, game design is an instruction manual. Programmers' and artists' works are defined by game designs. At the same time, game design is a documentation and history of the game. People refers to game design documents to find out why other programmers and artists made such work and why it should not be modified or removed or even extended.
Because efficient operation is not easy for game designers. Efficient operation should enable continuous integration(CI) and continuous deployment(CD) of game designs.
Continuous integration, or CI in short, enables automatic merge and test process. With proper CI, multiple author's design documents are merged without hassel and gets tested whether the final result is valid or correspond to team's requirements.
Continuous deployment, or CD in short, enables automatic services. Game design should be able to be exported as multiple formats and representation styles without designers modifying them by hand. Such service should let recipients to easily create feedback which can be possibly applied to the original design document.
So let's go back to the original question. Why need desops? We need desops because desops will do many good things for game development teams.
Gesign editor is an editor which supports file references checking mechanism. In the above demo illustration, levelmanager.gdml file is currently outdated. This means that files that level manager is referencing has changed but level manager did not update its contents. In this case, level manager is referencing a level file.
Basic principle of gesign reference check is that parent file should be always checked manually if parent's referring files or children's content was changed, or children file became outdated. For example if level's mechanism changes, it is also very natural that level manager's mechanism might change, thus designer should check for parent files for further updates.
For example, following logic is always applied when checking files statuses
Gesign is not currently activebly developed because of several problems which can not be fixed easily without making fundamental changes.
These are the reaons why I started to make rif library which will be introduced later in this part.
Gdmarp is an automation script which converts .gdt file into a varoius game design formes. Gdmarp consists of various unix text processing programs such as sed, awk and most importantly m4 macro processor. M4 macros are predefined and can be expanded into other lengthy texts for proper formatting.
Gdmarp is a very versatile script which utilizes features like variables, sql macros etc. For example, designers can set variable macros and use those macros in the file. If variable changes, recompilation will change those file's content in final result.
Basic work flow of gdmarp is as follows,
Gdmarp currently support three render formes which are representation(pdf, pptx, html), wiki formes (wikitext for mediawiki instnace) and webui(with bootstrap css) for game UI/UX demonstration.
Gdmarp is distributed as docker container and easily integrated with CI/CD services such as github actions or travis-ci.
Rif is another approach to enable file references checking but without external editor. Gesign was a good start however it was incomplete in terms of fundamentals that it couldn't be extended to higher levels. So I started a new project called a rif.
Rif's architecture is mostly same with gesign's. However rif doesn't have any functionality of file editing. Files' timestamps are stored in a separate file called rif.json. This can enable rif's integration to other editors such as vim or vs code, but you can always manually set the file's status and use simple editor even without integration.
I have made several games by my hand. Why? Because desops is about operating game designs and therefore desops should understand feedbacks from recipients which are mostly programmers.
At the time I first created this game(which was 2017), I had no idea what was game engine capable of and I barely understood what programming was. Therefore it took several months just to make this game. I learnt c# programming language and some networking concepts and extracted game assets from a game called Heroes of Might and Magic VII. Now, that is not so a confident way to make a game, however I was not going to publish a game and I liked the game, plus I just needed sample resourcese to make my game look a little bit "professional."
Making a game was not so easy then, because I hardly knew how to program. However it was doable and I learnt that nothing is impossible, yet it would take some times at worst.
I studied rust language and have been craving for opportunity to make game that implements data oriented programming. Unity was developing their own data oriented technology stack but it felt insufficient compared to their traditional object oriented stack. So I decided to finally start developing when I had found very easy to use command line game engine called amethyst.
Making a game without object orient programming is very refreshing and somewhat confusing experience. Object oriented programming is a very concrete implementation of programmingmethodology. Any programmers who have used unreal engine knows inheirtance is a god sent present. Data oriented programming does not have a concept of inheritance nor polymorphism. They were born not to deter those concepts intentionally but dropped them to gain greater good which is speed. This philosophy made a whole game development process very interesting.
I didn't fully understand data oriented programming on start and went through several trial and errors. I'm not going to go into details how data oriented programming works, yet I want to say that I realized data oriented programming is way better than object oriented programming in a long run. (But you can find a few trials and errors in my blog post if you want to know.)
I wanted to learn how game servers work. There are few open source game servers such as nakama. But again I decided make a game server from scratch.
I made a game server with rust language and used very lightweight http library called warp. I've never learnt about websockets thus it started slow, but when I grasped a whole idea of websockets and how byte streaming works, only several days were required to complete game server.
I made several reverse game design documents to prepare myself for real game designs and to test gdmarp's functionality to yield proepr game design documents.
All reverse game designs are made with gdmarp. If you're interested, follow the link and how it's made of.