ZEJ Statplay Engine

ZEJ Statistical Roleplay Engine
{ GitHub }
​

[hr]

Introduction:

Hello ZEJ! So a longstanding topic of discussion around these parts has been the creation of a statplaying engine. It's been discussed every now and again to varying degrees -- people talking about making one of our statplays into a video game, for example, or our many computer science minds letting the idea simmer as a collaborative effort.

And really, since we do have so many people involved in computer science (or who otherwise dabble in the world of code), it does seem like a natural question; why not put our many heads together and create a labour of love for our own community?

What this thread is for is laying the groundwork for the project. In a sense, it's going to be an "interest check" to start off, in order to gather people who would be interested in crafting the statplaying engine. But in the future, I imagine this thread as being the hub of the project's development, so to speak.

- Coded in Java (@"Nebulon Ranger" is working on a port to C#)
- Hosted on GitHub (using Git for version control)
- Based on the principles of ShadowSystem

[hr]

Project Plan:

Stage 1: (In Progress)

Stage One is going to be all about getting the Grid functional. No units, no interactions, just constructing the thing that makes up the very basis of our system. In this stage, we will primarily be tackling the Cell and Grid objects, as getting them functional and displayed is going to be essential to making further progress.

The current idea is to implement a variety of our "basic types" of Cells first, so that we can construct a few basic Grids (such as the ones in this thread) from said basic Cells.

The different Cell types that we will need are:
- Blank/Empty Cell { }
- Nonexistent Cell { }
- "Starting Zone" { }
- Wall Cell {w}
- Water Cell {~}
- Unbreakable Pillar Cell {p}
- Bag Cell {B} / Empty Bag Cell {B}
- etc.


Targets:

○ A functional empty Cell class
○ A Grid class that constructs the standard 9x9 Grid's information (i.e. positions of Cells) from a 2D array of Cells
○ Flexible Grid construction
○ Ability to identify each Cell by its labelled position (e.g. A1, B6, etc)
○ The current Grid can be displayed to the user visually


Future Stages:

Spoiler

Spoiler: Undefined Versions

Long-term goals:

Allow users to create Cells with custom properties.

Read in an external file containing the current Turn's configuration (including positions for everything, character stats for calculations, etc).

Output that contains formatted BBCode with the new current Turn's configuration.

[hr]

User Interface Design:

What this is is the "look and feel" discussion for our UI. Maybe someone with more graphical sense that I can draft us up a rough mockup for what we think the system should look like when it is being displayed to the user.

For now, just a couple bullet points...

- Grid itself can be displayed just as we currently have it represented on the forums
--- Should resemble old-school ASCII roguelikes.

- Light theme and dark theme, toggle-able (a basic white bg and black bg should suffice)

- Needs to display:
--- Unit information (permanently)
--- The current Phase (Player, Enemy, Neutral, etc?)
--- Cell Legend

[hr]

Software Design:

<Under Construction...>

[hr]

Spoiler: Previous Content (before April 11th)

ZEJ Statistical Roleplay Engine

Hello ZEJ! So a longstanding topic of discussion around these parts has been the creation of a statplaying engine. It's been discussed every now and again to varying degrees -- people talking about making one of our statplays into a video game, for example, or our many computer science minds letting the idea simmer as a collaborative effort.

And really, since we do have so many people involved in computer science (or who otherwise dabble in the world of code), it does seem like a natural question; why not put our many heads together and create a labour of love for our own community?

What this thread is for is laying the groundwork for the project. In a sense, it's going to be an "interest check" to start off, in order to gather people who would be interested in crafting the statplaying engine. But in the future, I imagine this thread as being the hub of the project's development, so to speak.


So... getting down to it. When I say "Statplay Engine," what is it exactly that I have in mind?

That's something that still needs to be deliberated a little bit. The idea could be pretty extendible, as there are a variety of applications that it could be used for.

For one thing, we could configure it to automate the RNG, grid updates, and damage calculations to spit out formatted update text for the Game Masters of statplays on ZEJ. Easier updates would certainly make GMing more accessible for most people.

It could also work as a platform for PvP statplay showdowns online. It'd be an interesting thing to make an actual game out of the engine.

But, in my mind, the top priority would be to get the actual engine up and running locally. The rest of these applications are just extensions of the project.


A few more bullet points of my thoughts... these are things that have been discussed in the IRC.
- Will be using ShadowSystem (although it could presumably be tweaked for use with Masq's system, or other GMs' systems)
- Short-term goals: get the grid functional, populate the grid w/ cell objects
- Coded in Java
- Hosted on GitHub (using Git for version control)


After more has been concretized, I'll continue to update this post with more details. But for now, I'd just like to get an idea of who would be interested in getting in on some of this sweet, sweet coding action.

Spoiler: a chatlog

[4:47:32 PM] [Jake]: Yo Flem, we (Zio, Muddy, and I) were talking the other day about trying to actually start the statplay engine project. Get a Git repo up and running for it, etc. Would you still be interested in doing something like that?
[4:48:36 PM] [Flem]: Sort of.
[4:48:44 PM] [Quinn Xavier]: Statplay engine?
[4:49:13 PM] [Flem] Actually a friend from work wanted me to start helping him learn Java, I'm supposed to be figuring out Github this weekend.
[4:49:22 PM] [Jake]: Essentially coding an engine to run statplays on, Silv
[4:49:36 PM] [Jake]: It could probably be configured to spew out update code, as well
[4:50:04 PM] [Flem]: Anyway, I would be happy to help but currently don't have the energy to lead, if that makes sense.
[4:50:12 PM] [Quinn Xavier]: So essentially easier updates?
[4:50:34 PM] [Flem]: If you break the work down to modular parts I'm more than happy to do any work you put on my lap.
[4:51:29 PM] [Jake]: That'd be one benefit of it, Silv. We could automate the updating so it does all the RNG and damage calculation and grid-updating for you, presumably
[4:51:57 PM] [Jake]: It could also be useful in making an actual statplay video game, a PvP environment, etc
[4:52:24 PM] [Codsworth]: Ooh
[4:52:27 PM] [Codsworth]: Shiny
[4:52:36 PM] [Jake]: And that's fine, Flim. If you're interested in helping out with it, that's all that we'd really need~
[4:52:36 PM] [Flem]: The actual format you want it in is important. Do you want it to take inputs and spew out a play by post update? Or do you want it to be it's own platform?
[4:53:22 PM] [Jake]: I don't see why it couldn't /do/ both, necessarily. If we can get it running its own platform, then it could also work the battles out locally and spew out update code if the user so desired, I'd imagine
[4:53:36 PM] [Jake]: running as its*
[4:54:08 PM] [Jake]: But the first focus would be, obviously, to make sure that a statplay battle can occur on it locally
[4:54:22 PM] [Jake]: Have all the grid features working, all the calculations in place, etc
[4:55:04 PM] [Shadow]: I'd think making it visually look like one of those old ASCII-only roguelikes would be pretty fucking cool
[4:55:27 PM] [Shadow]: So that you'd have the grid exactly like it is in our forum version
[4:56:01 PM] [Jake]: Yeah
[4:56:13 PM] [Jake]: Would you be interested in learning Java for this, Shadow?
[4:56:26 PM] [Shadow]: Yeah
[4:58:38 PM] [Flem]: I might have to talk to that friend who was learning Java about this.
[4:58:54 PM] [Flem]: But I'm going to wait to see if it actually goes anywhere first.
[5:00:07 PM] [Jake]: That's fair enough
[5:00:41 PM] [Jake]: I mean, given the nature of this group and working collaboratively on things, it's understandable that there would be scrutiny of it actually getting off the ground
[5:01:27 PM] [Jake]: But this is a pet project that I really would like to see come to fruition. I think it'd be useful for GMs, and if we could get it working adequately, it could be cool for real-time statplays too

 

Alright, so I guess it's time to post some of my preliminary thoughts that I've had while driving back and forth from university.

I think that the grid could be stored in a two-dimensional array of Cell objects. The first order of business would probably be to have a basic Cell class set up (probably a dummy class that just displays the standard, blank Cell { }) so that we could create such a 2D array. Using that, we could probably create a basic grid. A 2D array is probably not super efficient, but it was the first thing that came to mind for easy reading/writing of the Cells. If someone has a better/more elegant idea, that'd be cool too.

A big part about statplaying is, of course, its extreme degree of mutability and customization factors, so down the line we might have to start thinking about ways to allow people to make their own Cells with their own properties. But for now, just the "standard" types should be fine -- walls, things that can be destroyed, impassable cells, etc.

We'd also need a way of populating the grid. I figure that could be done fairly easily with a text file or something, and just have a method that parses letters/symbols into their respective Cell type. It shouldn't be that hard.


e: Also of note, as far as IDEs go, I've been using Eclipse and Netbeans the most for school, although I'm sure there are better IDEs out there. If anyone has any good Java IDEs in mind, let me know

 

I've set up a basic Git repository on GitHub, in case anyone has anything to contribute. I've added a very barebones [tip id=1 content=Basically just a brain dump for now. There's nothing terribly useful in there aside from accessor methods.]Cell.java[/tip] class, as well as a basic README for the project that basically just links here. Fair warning that I haven't actually used GitHub proper before -- I have some experience with Atlassian's Bitbucket which is similar and uses Git for version control, but I'm still fumbling around with GitHub for the time being.

As far as laying down the principles of Software Engineering goes, I have a few thoughts about the structure. Wait warmly while I type them up.

 

I was discussing this with @Shadow earlier, but we both kind of came to the conclusion that the Cells are more just "containers" for the objects that inhabit them -- be that a piece of terrain, a Unit, or what have you. I guess this could either make them a "data structure" in their own right, or something that could be divided into a parent class and two subclasses (i.e. one for Object/Terrain Cells and one for Unit Cells).

Still going to work on setting up something for the structure of the project, though. I like the idea of what @Muddy has laid there, and agree with Shadow about the primary goal. For starters, we should chunk it out and work towards having it be functional and able to work with dummy inputs.

 

Yeah, that's probably a good point to elucidate. What the variable is for is denoting the "Block Property" within ShadowSystem -- i.e. does the Cell block a spell or ranged attack. So maybe we'll call it "blockProperty" instead.

 

Did a quick update to the repo and added a super-skeletal Damage.java class. Also moved the Java stuff into a subfolder so that @"Nebulon Ranger" could share the repo if he so desired.

 

I've updated the original post to reflect some thoughts and changes. I encourage everyone working on or interested in the project to give it a run through and respond accordingly with their thoughts.


Now, what we need to work on is the Software Design section. This is the meat-and-potatoes of what we're going to be working on for the first little bit because it'll determine how we're going to structure the program when we do start diving into the coding aspect of it a little more. Besides that, it's not necessarily super knowledge-heavy; people with knowledge of statplaying but no knowledge of code can contribute.

I've hashed out a super basic setup for how I visualize things going. It's nothing even close to representing the finalized structure, but I thought it'd be worth getting out into the open so that we could discuss how we want to set up a class structure, what needs to be in each class, etc.

I've also set up a Google Doc for easy editing and collaborative purposes. If you do make an edit, sign somewhere at the top with a timestamp or something and a brief description of what you've changed.


For now, here:

Spoiler: Grid

A 2D Array of Cell Objects.

Attributes
* x Dimension
* y Dimension

Constructors

Methods

Spoiler: Cell

The most basic unit in statplaying. Cells are measures of distance, contain units, and make up the Grid.

Our Cell class should act as a "container" of sorts, housing the various objects and units that can occupy them. They themselves should be a parent class that does nothing without some sort of content inside of them.

Attributes
* Existence flag (boolean)// For Cells that don't actually exist within the Grid, i.e. the &nbsp Cells
* Passability flag (boolean)
* Occupiability flag (boolean)
* Breakable flag (boolean)// This might need to go into the Object Cell subclass?
* CON (int)

Constructors

Methods


Subclasses

Spoiler: Object Cell

*

Spoiler: Unit Cell

*

Spoiler: Unit (Interface)

Attributes
* Name (String) // Use charAt method to get the ID?
* Team (int) // Probably an int from 0-8 or something, so we can support up to 8 teams. Team "0" should be universal units that do not have a team alignment.
* Status (array of strings, probably)
* Level (int)
* Experience
* Next Level

* Professions
--- Profession 1, 2, 3, 4
--- Innate Properties
--- Stat to use for Basic Attacks

* Equipment
--- Weapon
--- Armor
--- Accessory
--- Shield

{
Abilities

A-Ability

R-Ability
S-Ability
B-Ability

E-Trigger
X-Ability
Overdrive
}

* Current HP
* Max HP
// * Type? i.e. does the unit use MP, Malice, ENG, SE, whatever
* Current MP
* Max MP
* Atk
* Def
* Int
* Spr

* Evasion
* Critical

* X-Gauge

Constructors


Methods

 

Updated my code as well. Now the Cell object implements the ICell interface, and the EmptyCell object extends the Cell object (and implements the ICell interface). So we've got the basic workings going.

I also forgot to post here to update that I made a very very basic GridDisplay class, so I've been tinkering around with that a little bit.

 

While I haven't made any particular advancements on the actual coding of it, I've been thinking about how we're going to get units / phases / teams functioning for the engine.


- A "Team" is an array of Units for the purposes of organizing combat into discrete phases in which units can be selected and utilized

Units will be assigned an appropriate letter for display
- might need a "formatter" class to do the representation of this identifier-letter on the Grid display
- also an "exception" for two units sharing same identifier, so that there's no ambiguity?


---

I'm thinking we'll need a "repaint()" method for the GridDisplay class to make sure that the Grid is appropriately updated each time something happens. And an "undo()" method to allow for reversibility of erroneous Movement Commands. Not sure how I want to handle the actual interfacing-with-the-Grid/Units proper, yet.

Over at Eternal Dream, Durn came back with an idea on how to "more easily" do updates (particularly for himself, by doing them in Excel) but aesthetically I think that, with a couple tweaks, this same display could be used for our Statplay Engine. It's somewhat more economical in terms of the space that it takes up, I think.

Spoiler: Graphic Display

Things I'd Change:
- Put values of HP and MP inside of the graphical representation
- Add Level and Profession in Namebar
- Put X-Gauge where HP/MP numerical values currently are
- "Hoverable" status effects (I'd display the effects of a given status effect, as well as its duration, if the user hovers over them)