Others Dev Something-kly, Starting my own game, Build-a-Waifu!

[papel]

Hello there, I'm a long time lurker and finally decided that I should make an eroge! YAY!... Gentlemen, please, don't give me that murderous look...
Anyway, here's the TL;DR; version:
Game uses Godot, which can export to all big platforms + html5
Programming in Godot is almost 1:1 as Python
Gameplay will be similar to Zelda: top down exploration and looking for items
Sex animations will be tweened, like those Flash games. You know, those.

Spoiler: Who the fuck are you, Papel?

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Why Godot?

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Why make the game?

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: What's the idea behind the game? What is it supposed to be

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Why tweened animations?

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Do you have, like, ANYTHING done yet, at all?

You don't have permission to view the spoiler content. Log in or register now.

^ Yes, I do.

You must be registered to see the links

. No sex anywhere yet, tho.

Spoiler: When can we expect a demo or something?

You don't have permission to view the spoiler content. Log in or register now.

Spoiler: Other thoughts

You don't have permission to view the spoiler content. Log in or register now.

I am thinking of giving the game a post-apoc, futuristic style, so you're literally building up your waifu. However, this isn't fully set on stone and I can easily rework things to make it a different style, so I'd like to know what you people think, which style would you rather see this game in: space level sci-fi, cyberpunk, modern, steampunk, medieval fantasy. Maybe I should make a poll? You guys decide.

Spoiler: August 2021 $TODO

You don't have permission to view the spoiler content. Log in or register now.

Holy shit, this was a very long post! Stay tuned for an update wherever, hopefully not too long from now!

 

[papel]

Jesus fucking christ, making a working save/load system was an absolute mess.
First, had to make player variables global.
For some reason, whenever i went back to the main menu and started a new game, the engine never reset the player values. So you could load a game with all flags set as true, go back to main menu, start a new game and it would act as if you never left! Since I only save health and flags and always spawn the player at home (much like a Zelda game, might look into different spawn points later), that was easy to check.
Needless to say, that was a serious problem. So I had to manually reset all the values and that took a lot of time, ffs. And because it couldn't be "that simple", there's still a bug where loading a game, going back to the main menu, then loading again, will behave like a new game instead... Fucking hell.
So, if you are already in game, loading works as expected. If you're in the main menu, it only loads properly the first time around. If you enter the game, get back and load, it "works in mysterious ways". Imagine the fun of trying to figure why some stuff I defined as Global was automagically updating themselves to null references. On the plus side, the save is perfectly editable like a .ini file

Screen transitions were simple enough at first, then turned terrible when the damn thing decided that it should flicker once it finished getting fully dark. There's a reason I said "I have the bare minimum of an idea of what I'm doing" instead of "I know what I'm doing", because I already have loose variables that I can't exactly get rid of without something misbehaving. Later, the screen decided that, you know what? Let's fade as a rectangle growing downwards from the player position! You'd literally see a black rectangle covering the lower right part of the screen. Fucking shit. Lots and lots of messing around and this was "properly fixed" (read: hacked enough to no longer be a problem while testing).

Thirdly, talk box is working! A simple animation where it comes from below and expands, which I think is really neat. The current box looks terrible, but does the trick and the font should be legible even in small screens. Also, I'm still trying to figure out how to load several pages of text and make it go through them.

Overall, my code already feels and looks like a fuckload of hacks, questionable decisions and terrible design that "it just works". This is partly due to me not starting the project with the player as a global variable/instance/whatever, though I might have to make it global to avoid further headaches. Seriously, the amount of problems that would've been avoided if I had the player as global from the start would've been drastically reduced.

So, from that first $TODO of mine, i've made some progress, but none of them are working fully as intended yet. I'll have to rework the player into a global node to make save/loading work as expected, always have access to the camera globally and also to set its boundaries later.

 

[quarzo]

GL men, seen very smooth.

the last time I work a little in my game, i was fighting with the save system too, a total pain.

 

[osanaiko]

Programming your own game engine is a huge exercise in learning how to solve the near identical issues that have been solved in existing engines. It can be a lot of fun, and force you to study new areas and think through many issues.

But it's not the same as making a game. Making a VN and/or Sandbox game is another huge amount of work creating content and story and dialogue, even when you have an existing platform that solves all the "plumbing" for you.

Godot framework looks great. I expect it will likely be a near competitor to the current level of unity/UE in ~5 years. Although of course, by then both of those platforms will have also progressed forward. At least it's 100% free and open source.

So... good luck on your game engine.

 

[papel]

Haven't had much time to mess around with this lately due to work and study. As expected, but oh well.

Some good news, saving is actually working 100% as I expect it to, which means it saves the data to a file and doesn't keep garbage in game once you get back to the main menu. Also, on load, it takes you back to your home room, which I intend on making it take you to the "last checkpoint", so I won't have to worry about enemies' state, health or whatever. Might have to come up with an autosave.

I've decided to scratch the idea of a hookshot subweapon for now. The variables checking for them are still there in code for later. Anyway, I've mostly decided to scratch it being a hookshot, since moving the collision shape of it was all wonky. A fixed distance collision for a whip or chain works fine, so i might go for that instead.

I also tried my hand at making a couple of ground tiles. They all got something that makes them look off, which is not surprising, given that the last time i tried something like this was ~15 years ago, messing with RPG Maker 2000. Case in point:

You must be registered to see the links

I made a mental and written note to take a look at GPL tilesets and work on top of one, so after I finish creating the maps, I'll just need to paste the "new art" on top of the original file.

I'll probably take most of the day tomorrow looking into camera boundaries. From the little I've already looked into, it seems I'll need to rework quite a bit: the camera should be an entity independent of the player. Depending on how much work this might take me, I'll scratch it, too.

GL men, seen very smooth.

the last time I work a little in my game, i was fighting with the save system too, a total pain.

It's ironic how simple the idea is and how damn difficult it can be to make it work properly. In my case, it was carelessness. When loading the values of a savefile to show on the menu, I was setting the player's values with them as well.

Programming your own game engine is a huge exercise in learning how to solve the near identical issues that have been solved in existing engines. It can be a lot of fun, and force you to study new areas and think through many issues.

But it's not the same as making a game. Making a VN and/or Sandbox game is another huge amount of work creating content and story and dialogue, even when you have an existing platform that solves all the "plumbing" for you.

Godot framework looks great. I expect it will likely be a near competitor to the current level of unity/UE in ~5 years. Although of course, by then both of those platforms will have also progressed forward. At least it's 100% free and open source.

So... good luck on your game engine.

I was never a big fan of Unity and even saw some "horror stories" of projects just up and vanishing because of bugs. Godot being fully FOSS is the biggest plus for my situation. As soon as a "big game" comes out that says "made with Godot", the engine will get a real boost. The community is large and there's plenty of learning material, too, so that helps a lot.
It's far from perfect, though, using it for 3D stuff is painfully slow and heavy on the GPU (hell, one video compared a simple project, Godot was grinding to a halt with ~1750 3d physics objects, while unity went over 25k without a hitch), and updates can sometimes take forever to come. For 2D, though, it's a great option.

 

[papel]

Small progress:
- Enemies now have a simple detection area. They also keep moving in the same general direction if they lose track of you which is amusing, but not what I intend for in the end.
- Camera boundaries for each map. After much trial and error trying to offset the camera's position, which always reads 0,0 as it's origin is the player itself, I realized I could simply set the limit variables once the map loads.
- Current situation.

You must be registered to see the links

--
EDIT: - Enemies are now knocked back when hit by the player. Player is also knocked back if hit, though it looks like a teleport right now. Both have a short window of invulnerability, 0.8 and 1.5 respectively. The player still gets knocked back even if invulnerable, this is to avoid having the colliding bodies touching but nothing happening. Here's how the simple combat is working at the moment ->

You must be registered to see the links

Spoiler: The code for blinking

You don't have permission to view the spoiler content. Log in or register now.

I feel kinda bad when I look at what I wanted to focus on first and what I end up doing. I guess I go for low hanging fruit whenever I hit a programming wall, which is what happened when I tried to make text load from a file, because Godot really hates saving info as plaintext, except for strings.

Case in point: i tried using the same type of file reading as I use for save/loading. Godot kept complaining that it couldn't read the file, instead of complaining that it couldn't figure what was inside, Error 43 - could not parse.

Ironically, as I was writing this post, I was also fussing around and preparing a question to ask why the Parse error was so damn useless. Then, as I tried that again to get all the messages and stuff, it worked. Bamboozled as heck. So, using configfiles, which neatly separates things into [sections] and keys, while being perfectly readable, is now working as I wanted it to. Next stop, figuring a way to make text load from said files.

 

[Kinderalpha]

So... good luck on your game engine.

He's not making an engine, and I'm sure he doesn't appreciate the disrespect either. Do your homework.

Small progress:
- Enemies now have a simple detection area. They also keep moving in the same general direction if they lose track of you which is amusing, but not what I intend for in the end.
- Camera boundaries for each map. After much trial and error trying to offset the camera's position, which always reads 0,0 as it's origin is the player itself, I realized I could simply set the limit variables once the map loads.
- Current situation.

You must be registered to see the links

--
EDIT: - Enemies are now knocked back when hit by the player. Player is also knocked back if hit, though it looks like a teleport right now. Both have a short window of invulnerability, 0.8 and 1.5 respectively. The player still gets knocked back even if invulnerable, this is to avoid having the colliding bodies touching but nothing happening. Here's how the simple combat is working at the moment ->

You must be registered to see the links

Spoiler: The code for blinking

You don't have permission to view the spoiler content. Log in or register now.

I feel kinda bad when I look at what I wanted to focus on first and what I end up doing. I guess I go for low hanging fruit whenever I hit a programming wall, which is what happened when I tried to make text load from a file, because Godot really hates saving info as plaintext, except for strings.

Case in point: i tried using the same type of file reading as I use for save/loading. Godot kept complaining that it couldn't read the file, instead of complaining that it couldn't figure what was inside, Error 43 - could not parse.

Ironically, as I was writing this post, I was also fussing around and preparing a question to ask why the Parse error was so damn useless. Then, as I tried that again to get all the messages and stuff, it worked. Bamboozled as heck. So, using configfiles, which neatly separates things into [sections] and keys, while being perfectly readable, is now working as I wanted it to. Next stop, figuring a way to make text load from said files.

Don't underestimate or put off Art too long. I made the same mistake with my previous project. I like what you're doing though, and the process replicates what I was doing back on my previous project. Something important to remember is all your save data has to be serialized therefor when you're designing your systems and mechanics, design them around that idea. Getting saving in early is the way to do it, since you will now have the headache of building everything around it. Every looks really good thus far! I like the little pizazz you're adding as you go.

Some tips from somebody who gave up on a similar project in Love2D. Get your art figured out. The difference between a conventional game and an adult game is heavily based on the art. You're not gonna want to put hundreds of hours into programming with nothing to show because you have no art. Secondly, pace yourself and set realistic milestones. There's a hundred and ten talks on GDC vault about pacing, focus, time management, and resource management when it comes to development but I think it's key. It's a monstrous task. Lastly, hats off to you, and I'm happy to see another person working on a project from scratch!

 

[papel]

Something important to remember is all your save data has to be serialized therefor when you're designing your systems and mechanics, design them around that idea.

I'm aware. I did think about using SQLite to manage saving data, as that'd allow for a much easier growth and storage, which I might use in a future project that needs a fuckload of data to be saved.
However, since the data saved for this is small - health, subweapons and waifu parts unlocked (boolean flags), time played - and you always get back to the starting area, using a simple file works fine. Luckily, it's fully working as intended, as all that data is read from/written to a struct type field, so if I decide something new needs to be saved, I just add it there.

Don't underestimate or put off Art too long. (...) Get your art figured out. The difference between a conventional game and an adult game is heavily based on the art. You're not gonna want to put hundreds of hours into programming with nothing to show because you have no art.

I know, art is the soul of the project, even more so for a porn game. The thing is that I really want the game to also be at least decent, even if a bit forgettable. Played too many h-games that controlled like shit and collisions were all over the place.
I'm also experimenting with the waifu parts, I'm almost-kinda-decent at drawing. Since the parts are all separate, it's easier to draw and redraw until it looks right, compared to making a whole scene with characters posed.
There's also the interface. Right now, my UI is ugly and barebones, but i'm often looking around opengameart, games and other places to have an idea of a good interface, something that shows the important info without getting in the way nor looking out of place.
I don't know if this was the case with your project, since LÖVE needs you to write a lot of stuff, but with Godot, once I have a proper placeholder in place, replacing it with semifinal or final art is a matter of renaming files.

Secondly, pace yourself and set realistic milestones.

That was probably the first thing I did. My original idea was much bigger, with a lot of story to explore, combat would be about avoiding enemies altogether and exploration would have both a persistent map and random dungeons.
Writing down all that stuff, thinking how things and data would interact, what would need to be saved and how much work I'd probably have with things, I started trimming stuff down until I got to the 1st post. Snes zelda style gameplay, static maps, one or two subweapons to explore other parts that were inaccessible (and even this might get cut).

Sometimes I think about focusing more on art, getting at least some assets closer to what I envisioned as, and focus on creating at least 2 animations (which can be VERY time consuming), so people can have a taste of the game proper. I doubt more than 3 people would play a pre-alpha demo that didn't offer even a single h-scene