Jack-0-Nine 2 development thread

**Guifurst** · 10-29-2015, 03:49 PM

This thread is dedicated for the development of the game, remake in a different engine, of the original Jack-o-nine-tails.

Spoiler

The Godot Engine

The engine I've chosen for this is called Godot. Its a very nice, open-source and cross-platform, development engine with SDK^{(software development kit)}. This is has built-in editor for any visual element and script writer with auto-fill and error check. It has its own scripting language that is very much based on Python, called GDscript, high-level and very easy to use. Several built-in classes for all our needs.

Links:

Official site: http://www.godotengine.org/
Github wiki: https://github.com/godotengine/godot/wiki
Reddit: https://www.reddit.com/r/godot/

Project Repository

The project ~~will be~~ is already shared on Github. It is a great way to collaborate and get you to follow proper versioning, plus the Godot engine is very well suited to this kind of workflow. The basic of it is that, the main project will have its Github repository, a collaborator clones it, pull to his personal computer for development, makes changes, push back and then makes a merge request. If the developed code is ready, suited for the project, and conflict free then it will be merge as part of the main project.

https://github.com/Gfurst/Jack-o-Nine-2

Long Term Goals
updated 09/11/2015

These are our major goals for the final project.

Clean and smart code
High customizable, any data concerning lore, locations, dialogs, personalities, are kept in Json formatted data text files
Version safe save game, all data needed to be kept will be written to Json file as well, following its own order of contents
Custom modular girls graphics, in order to allow for variety sets of modular graphics to build girl bodies
Custom slave generator, all data pertaining slave will be randomly generated when needed
Custom settings, like difficulty scale are planned
Rework of the UI and substitution for quality images for the backgrounds (rome and activity scenes)
Proper documentation not only of the coding but also gameplay manual.
Streamline of gameplay features and balancing

Short term Goals:
updated 09/11/2015

More immediate things we need to get done, if you can contribute with any of these, feel free to do so.

Definition of all data, data types and usage for slave and slaver
Definition of all data world files: dialogs, residents, personalities, patriarchs, etc...
Develop code to handle world data above. (explanation on this ?¿)
Conversion of backgrounds to new format and icons (the main scene background is 1024x768)
Conversion of music files to ogg, and apply dynamic range compression
Develop system to handle background music ( I want a system that will randomize playback and change on demand)

**Guifurst** · 10-29-2015, 04:25 PM

Just an quick update on what I've done so far. We started the discussion about remaking the game around last week. Since then I've followed most of the tutorials and documentations. Started out working in the game it self, and its progressing very nicely.
Actually I've made only the main menu so far, but the exercise is proving to be very fruitful, getting familiar with the engine and all. Now I feel much more comfortable with awareness of how everything should be built.

If you check out stuff about Godot, you'll see most updated documentation is on the project's github wiki, and still its not very deep. A lot of resources can be found on the in-built object references, to find info on something specific does, but still a lot of that is incomplete. On the plus side, its a very active and helpful community, the engine it self and the project site are still in very much development, but its promising.

Soon I'll be posting some actual results and publishing what I have on github. Others are very much welcome to join and collaborate. I'll specifically need someone to translate to me how data is processed on the original game, like what operations are done on skill gain, slaves stats and everything else, plus very need dialog text and lore. This will speed up a working release a lot.

Extra stuff that is very much welcome, is original and standard art. I very much want a working modular girl (different source images for bust, butt, body, face, hair, etc) so that we can have a multitude of possible results without having to rely on several images for every single slave. A random slave generator is in my plans. So for that goal, ideally we need an average talented artist, but if we can't find one not all is lost, we could still manage to extract such images from existing games, such as CM3D2, I've already seen a way to do this. But this is probably hard and boring work, so an extra hand will be needed.

**Lulu le gland** · 10-30-2015, 08:30 AM

Yeah, ren'py isn't good enough for this kind of game. Did you take a look at the engine running HHS? I feel that would be perfect for a game of management. As for godot, I don't know. Do you need programming at all? If not, that's pretty swell but you don't really need much help aside of writing, design, story and graphics. The godot scripting thing looks a lot like managing xml files. With nodes and childs and stuff. Simple enough.

As for the slave generator, I'm pretty sure you or somebody will need to pay somebody to work on this or find somebody hyped enough to work with you. That probably means creating a good prototype to show them all you're serious. Anyway, images aren't always needed, you can show text instead, right? Anyway, I think Strumpets have some kind of character generator, looks good enough.

And please, don't take stuff from jack. You'll probably take some of the default with some of the features, not a great thing IMO.

**Guifurst** · 10-30-2015, 09:33 AM

hey Lulu le gland,

I did not look at HHS yet, if you can tell what is engine specifically.

Do you need programming at all? ... The godot scripting thing looks a lot like managing xml files. With nodes and childs and stuff. Simple enough.

Well, you don't need to know much programming but it sure helps, the whole of game creation in Godot is made through high-level scripting language. Its very similar in python as instance.
But no doubt knowing object oriented programming helps a lot, finally those abstract stuff I've learned some years back are being put into use. As you've said, all of godot is built around the concept of nodes, child nodes and such, there are several built-in node types with classes that inherit from each other. The built-in classes and pretty much the whole back-end of Godot is built on C++ language, so you can delve into the code further or write parts of your game in C++(for performance for example)...

Anyway I digress, I disagree it looks much like managing xml files, though xml is a format you can use to save scenes and resources. One plus side is that it has built-in json support, that is support of the text data to dictionary data, which I believe is the same used in the original game as well. In any case, we shall use this thread to get familiar with the engine too and troubleshoot code and stuff.

**Lulu le gland** · 10-30-2015, 10:15 AM

HentHighSchool uses windows form or something like that. It's quite weird, but it's doing the job alright. I don't think their engine is usable anyway.

**Guifurst** · 11-05-2015, 06:06 PM

So I thought I come by and share my latest developments, lately I've been more and more familiar with the engine and done nifty stuff:

First you'll notice I'm only using assets from the original Jack. One of the first things I did was the initial screen.
Now if you pay attention you notice minor differences to the main UI. Mainly I've adopted the format used before, the main screen 1280x800 (16:10) makes things easier, the main portrait in the size of 1024x768 standard, with a top and side panels.
In the original game, I don't why but black borders appears on both sides. Anyway, you will notice that the wood border thingy is different. I've made an tile asset, as small image that is tile to look like that, which means all of that is built with that single resource. Potentially other windows ands screen can be done like that too.

One minor annoyance is that the top panel only had 32 pixels of size for it, too small to show anything, plus the border size of 16 I've think. Working with multiples of 2 makes things a lot easier too.
Now one of the best things I've come up with yet is shown on the menus... as shown in the second picture, the menu is properly built with names and icons, but the others aren't. The deal is that these menus are automatically generated based on parameters, instead of having to build each scene manually my crazyness drove to do something like this.

For each location there is a data file in the json format, its human readable and easily customizable. All of the "world" data files are loaded upon game start, if they pass a few check they're loaded on memory as a dictionary, as sort of database for the game playable data. So as long as there is an available target the menu is shown properly... in the third and fourth picture you can see that it detects a invalid button and deactivates it, its kinda foolproof. Just tonight I've played around with animation and come up with nifty fade-in/fade-out between locations.

Code:

{
"title":"Rome",
"name":"rome_main",
"type":1,
"menu":
	["rome_whitetown",
	"rome_taurus",
	"rome_serpentine",
	"rome_necropolis",
	"rome_outcasts",
	"rome_border"]
}

The data file is a simple as this, there needs to be a title, a name and a type, the rest should vary with what data it contains. Since locations plainly only show a menu it should be pretty simple. The type is a set of constants, each describing a situation, for example, 1 is for location, another could be for shops and other for residents and so on... Another nifty trick that I've accomplished almost by accident, is that icons and background images will be loaded automatically based on the "name" of the data, properly placed in the appropriate directory. For the example above, the files "background/rome_main.jpg" and "icons/rome_main.jpg" will be loaded when referencing the data "rome_main", icons will be in menu, and the background you change to this main scene.

Remember when I've mentioned the "world" data, in quotes earlier. Well that was another happy part of my accident. Technically the way I'm doing this, you could have a set of worlds or with completely custom lore and set of images. I'm already planning for the future to have this option on the main menu or on start game. I'm also planning to have a similar thing for set of slave graphics, so lets say one has a set of images they want to use but the other does not... plus it will fit well if I ever pull off the modular images for the girls...

On that side I also have some news... I've found this game "Custom Reido V", one older title from our beloved KISS. it has custom girl maker in 2d with some good variation, plus seems to have plenty of h-scene with it. All this data is packed in .xp3 files, they manage to open that previously for translation of the UI, I still haven't accomplished that but seems really promising!

And as usual any help is appreciated. With the config files it should be much easier if you want only to contribute in building the world, plus formating of the images and icons. If you know how to draw proper borders too it would be awesome. And finally, I do need someone to translate some of the code from the original QSP, even if its just copying the whole thing to a pastebin.

Cheers!!!

**silli** · 11-05-2015, 07:30 PM

Originally Posted by Guifurst

If you know how to draw proper borders too it would be awesome.

You'll need to elaborate. Anyone with a freeware image editor can draw borders onto an existing image.

If you want someone to write code which will automatically apply a bordered "overlay" image on top of an existing image, then that's a different task.

If you want someone to design a customized border (e.g. ivy leaves) in order to beautify the GUI and build up a specific look-and-feel for the game, then that's a different task.

And finally, I do need someone to translate some of the code from the original QSP, even if its just copying the whole thing to a pastebin.

The code is already available on Github. If you want the latest-and-greatest then you'll need to download QGen and open up the RC files created by crushboss.

If you want someone to actually translate each code file into a different language and send you the results, that's probably a bad idea. The Jack QSP code is rife with action-at-a-distance (e.g. global variables). If you duplicate this behaviour then the Jack2 game will be just as buggy and hard to maintain as Jack1.

Ideally, you want someone to analyze the code and reimplement each feature in modular form. This task is less about "reading QSP code and translating it line-by-line", but rather "understand what the QSP code was trying to achieve, and then implement it in a sane way." We have access to many new features which obviate a lot of the QSP bullshit. For example: stats can be implemented as floating-point numbers, so the entire _rate system should probably be abandoned in favour of simple numeric growth with diminishing returns.

I'd suggest starting with one of the following:

locations
- the key question here is "how heavily do you want to rely on the Godot Scene feature?"
- you could potentially implement each location as a separate scene, but it might make scripting more difficult
- you could try to implement most of the locations as a single scene (with separate scenes for Combat, Chariot Racing, etc), but it might make modding more difficult
- you'd need to decide whether navigation is going to be strictly point-to-point, or whether shortcuts (e.g. "click here to return home") are allowed
- you'd need to decide whether navigation will involve the possibility of random events or random encounters
- you'd need to decide whether the entire map will be available to navigate at the beginning of the game, or whether some sections will remain locked-off until the player has completed certain objectives
object-oriented implementation of characters
- the crucial decisions here involve inheritance
- slavegirls are obviously a subclass, since they have extensive emotions in addition to the more common attributes (name, location, health, etc)
- the player character has a limited system of emotions. It could therefore be a superclass of the slavegirl, or it could be an instance of slavegirl which simply doesn't use all of the features (e.g. player character can become depressed, but doesn't actually suffer mindbreak)
  - if you want to get REALLY fancy, then you could try to implement the slaver and slavegirl as instances of a single class without any special logic. Both could be killed in combat, both could suffer mindbreak (which would be a gameover for the slaver), both would have arousal and sex-drive, both can train their stats, etc. The only differences would be due to biology (e.g. slaver doesn't be milked because he lacks breasts, slavegirl can't assfuck anyone because she lacks a dick, both can bathe someone, both can dildo someone, both can attempt to cook a meal, etc)
- any character who participates in combat will need physical stats. You could ensure that NPCs have such stats (which would allow you to create quest-chains which potentially end with the player or a designated slavegirl fighting against the quest-giver NPC), or you could assign NPCs to a more rudimentary superclass which lacks physics stats (note: this approach would probably simplify the workload for modders)
quest and objective system
- this feature is much simpler than the two discussed above, but you'd still need to make some "design" decisions here. The main question would be: "is Jack2 intended as a straight remake of Jack1, or do you want to start adding new concepts and features early in the development process?"
- do you want to include hints?
- do you want quests to have actual scripting (e.g. "upon quest completion, player gains permanent +2 strength"), or should the quest system be more of a journal which guides the player but doesn't actually influence the simulation?
- should quests always begin during a conversation with an NPC, or should it be possible to acquire a quest simply by acquiring a specific item (or visiting a specific location, or gaining a certain amount of money, etc)
- what kind of quests do you want to support? Is it just storyline stuff and major NPC's slavegirl requests? Or do you want to support small-scale MMORPG/achievement stuff (like "cook an S-rank meal" or "beat up 5 orcs" or "fail to brew a potion 5 times")?
- should players be able to view quests that they've completed, or do you prefer a simpler quest system which merely tracks the ongoing quests?
- should players be able to permanently abandon a quest if they have no intention of completing it?

**iloveanimation** · 11-05-2015, 07:35 PM

Nice Work! Can't wait for your version!

**Guifurst** · 11-06-2015, 06:15 AM