LINGUAR'S PROFILE

Well here's September and only now did I get the scratch to build the system.

Though admittedly the specs changed a lot.

Here's what it ended up being:
Dual Dodeca Core Xeon E5-2680 v3 (24 physical cores with 48 logical cores)
128GB DDR4
GTX 980 Ti
HAF X Case

And a picture for proof (since some say 'Picture or it didn't happen'):

Hello Everyone,

I'm just reintroducing myself since I've been silent for quite some time.

My standard call sign from 2000 was 'Linguar' as a part of the original (before this one!) RPGMaker.net's four Co-founders (Rast, Airzone, Kindred, and Linguar.)

My primary interest deviated from the RPG Maker world and focused on Compiler and Computer Language theory.

I did a few drawings in the past, but stopped around 2007-2008.

I'm posting again here because within a year, I hope to be finished with my language theory fun stuff and want to try my hand at game design once again. To Actually make a game, instead of just focus on tooling.

I'm a Junior Programmer where I work by title due to being self-taught, I'm bored to tears by academics so I never got anything beyond an Associate's.

Nice to be back, and here's hoping I can actually make a game for once. :-)

Edit:
Also, to help get into 3D Design, I aim to purchase the following components in May.

author=kentona link=topic=710.msg9546#msg9546 date=1203708400
. . .
So, are you making a framework for making game makers...? Interesting.
. . .

Yes that's one way of putting it.

The idea is: the simple parts of the program should be simple to manage consistently.

Such as what images are used to represent a certain kind of project, or an element of said project (like a map). Others include what extension is associated with a project/element, what editors are used for a project and its elements (like a map editor and a map).

The logic of how to use these individual parts would be managed using other behavioral attributes.

The IDE itself would use an abstract view of how things work, instead of selecting a given editor by the type of project/element, since the logic to do so is detailed by the attributes. Same applies to the images used in the project view, the attributes tell where to source the data, instead of selecting them by type.

The logic described is simple in many ways, but I figured that worrying less about the small details, and scattering around multiple different areas of code to do very specific work all related to the same item, should be brought together into one spot; to reduce the overall manageability of the code.

All of what I'm talking about is of no consequence to the end user. But it is important to someone like myself who wishes to one day make a program that can really be called a 'game construction kit'. Which requires it to have more than one project type that covers more than one game genre. While I could just require the user to make everything from scratch, I figured it was easier to adopt a modular approach that would enable me to make an add-in for a given type of game, that would add-in a standard set of functionality for the user to start with, at the very least.

The modular approach makes things consistent and maintainable, for me at least. This is the solution I came up with after trying the same thing last time, and many times after. I had to spend so much time worrying about the trivialities that I couldn't focus on the act of making an RPG maker itself. If I can reduce the confusion of what's what and streamline the approach, it gives me something else to focus on, the specifics of game logic related to Role-Playing Games, Action Games, Fighter games, and so on.

I'll admit, that made me laugh.

It makes it even more amusing because I tried it and got the same thing.

Greetings,

I'm posting to be sure there is still interest. RPGCK was a project I started in 1998 to make Role-Playing games. It was continued through the original version of the website RPGMaker.net, and later adapted the name C G C K, for complete game construction kit. The name was changed to EGCK, Etoc: Game Construction Kit, because the font I used for CGCK made people read something related to the phallus; so I figured that name was counter-productive to promoting it.

The question I have for people, should I bother trying to revive this old project? By revive I mean start anew, because the old project no longer exists in a format that I can use (I no longer use the language it was coded in: VB6).

Here are a few of the sub-projects that I'm actively working on that would help in the design of the project:


Abstraction - A comprehensive Integrated Development Environment (IDE) geared at making IDEs easy, using the features of the .NET foundation to make bringing the ideas that make up an IDE easier to handle. An IDE to the user would be the user-interface you use to make your game. It handles bringing up the proper editor, based upon which part of the game your modifying (called 'Elements'). If you're working on a script element, it would bring up a script editor, a map element, the map editor, and so on. Basically Abstraction means nothing to the end user (most of the people here), but to a developer wishing to expand whatever uses the IDE, it's gold because it greatly simplifies adding new types of projects, and the elements that make up those projects. As well as the designers that create the elements/projects.

OIL - OIL is another Developer-specific project aimed at abstracting the concepts of code used in the .NET foundation. It provides access to creating, on the fly, Assemblies, Types (Enums, Interfaces, Classes, and Structures), and the members that make up each of them, including the code that defines what the types do. The point of this project is to allow you to generate code on the fly, but it also uses another project called 'OILexer' to understand what a script does, in programmatic sense. It also allows the translation of OIL objects into the Common Intermediate Language, or CIL, which is the core language of all .NET languages (C#, Visual Basic, et al. respectively).

OILexer - A project aimed at helping make a programming language. It takes your language description-language code and builds your language, and compiler respectively. Due to the abstract nature of this project, I won't go into the specifics, because it's beyond most coders that I talk to, and I'm terrible at explaining it in general terms.

This project is one of the most necessary but one of the most complicated as well. The project is in a boot-strapper stage where I'm building a program, parser, interpreter, linker, compiler, that builds simpler parsers, but parsers that would be difficult to do by hand. I will then use it to make another project that uses the same concepts to build the final version of the project, which will, in final form, be able to build itself.


The projects mentioned above are not completed, but they are making good progress. These projects are the types of projects I think would be necessary to make a readily adaptable IDE for Game Creation Program developers, and game developers alike. There are more projects that would be necessary, so it's the tip of the iceberg, but the "OILexer" project is the most key, since it basically would allow them to build their own scripting systems (for example, allowing their system to use Ruby, or another programming language). There's a lot of potential for this project, but I figure before going to the effort of bringing everything together, I need to see if there's interest.

You could say I haven't exactly been idle over the past seven years after RPGMaker.net died the first time. Much of my time has been devoted to research at abstracting the processes used in making makers. You might even call the result Comprehensive Development System Construction Kit (CDSCK) instead of EGCK, but that's just because I find automation fascinating.

By now you might be wondering, "But what about making games?" You'd be right to assume that what's planned, so far, has nothing to do with games. But the largest issue with most makers is good tools. So my first goal is to solve the problem of the irritation of making tools and integrating them into an IDE. This includes tools that handle scripting, and any other type of editor (including image editors).

To the end of making good tools, a good foundation for them to sit on top of is necessary. Without a good foundation, any flaw in the foundation will be reflected in every designer made from the foundation. If you don't use a foundation to base things off of, you have a higher level of inconsistency, which is generally a bad thing. The foundation, in the case of Abstraction, is also a good means of information and control. It uses the information to control the interactions of the primary IDE. It uses the information contained within the meta-data associated to projects, elements, and designers of each to determine which designers to expose to the user and when.

If you have no clue about certain parts of this post, please inform me and I'll clarify to the best of my ability. This post is aimed at game developers as much as it is game kit developers.