Prior to the actual update log, here, have some concept posts — which were originally posted on my tumblr, hence the more relaxed style and assumption of familarity. Also, I'm posting about writing a monster porn sex game, come on.
really i think the very very first playable iteration won't even be pornographic at all; it's just be a really basic example of the main game mechanic loop
THAT BEING:
- enter a new area
- look for the shrine area/sacred spot, killing trash mobs on the way
- trigger some kind of eldrich summoning cry
- hunt down the [x] number of sub-boss type enemies that get spawned in the area; you get pointers to them on your minimap maybe. also now there are a lot more trash mobs
- get back to the shrine, potentially fight a boss (?! probably not, or at least not in most areas)
- spend all the points you got from killing things to revitalize the area + level up
- repeat
and i guess with it balanced so that clearing each area will give you exactly enough points to revitalize one stage-worth of the area, with whatever extra going to level ups. or maybe not, idk, basically what i'd like is: 1. you always have a clear goal to accomplish in each unfinished area, 2. that goal is not "kill things forever to grind up points", with the added mechanics idea that you can kind of fuck yourself over if you spend the points which you ought be using to save the world to level yourself up (since you can only trigger one call per stage; if you level you have to grind to get the points to continue and that's a punishment)
oh right and areas are divided up into stages, which is in terms of how raggedy and desolate they are; they'd start off as basically half-eaten and dissolving wreckage with only a small core of more coherent area, and after you clear the first stage you get a more-or-less solid area that's still a dead wasteland, and from there you can restore bits and pieces of it to life
basically i just want something like, idk, soul blazer or dark cloud (the original), where to a certain degree you can choose what to restore in what manner but for the most part it's just a 0–100% bar with a little flavor depending on how you do it
this has certain implications for the architecture, like: if i do want to show pointers towards the miniboss enemies then that means i have to know where those rooms are in comparison to whatever room the player is currently in, which means areas have to be spatially coherent (as a design issue) and they have to be all loaded into memory (as a system issue). this implies the existence of an 'area' struct, which implies as an aspect of the gameplay the world will be divided up into distinct areas without a lot of interplay between them
oh and you fuck monsters
well
not the monsters you're trying to kill
like with the devouring extra-dimensional monsters; the ones you fight normally aren't really sapient or sentient, so there is not gonna be any sexy yiffing going on there (maybe for the bosses though) but there are still people living on the land and some of them might be hostile for various reasons, so basically you can also encounter hostile mobs that aren't the world-devouring monsters and at the very least you can probably figure out some way of making them no longer hostile
like idk if you wander into the goblin village they're not gonna be too happy about that but you could probably work something out provided you haven't been killing all the stray goblins you come across
and then if that goes well there'd probably be some goblin adventurers you could go with and have explicitly pornographic sex with
probably there'd also be unique npcs for various other reasons and they may or may not be possible travel companions and may not may not be possible romantic/sexual interests
still not entirely sure how the whole leveling mechanic will go though; probably you'll get a selection of various stat upgrades or new abilities based on your current position on the elemental wheel of magical affinity or whatever and those will shift around your physical traits as you pick ones in certain groups
i just don't want to make a game where your options on leveling are "str up, def up, bigger horse cock, bigger breasts"
because that's dumb
and i'd find it quietly amusing if you could play through the entire game without any really obvious signs you're playing a sex game aside from some potentially-salacious dialog choices
November 3rd, 2011
Since I keep mostly posting on Tumblr these days I'm somewhat out of practice at writing log-style logs, and anyway I have to commit all this stuff to the repository anyway, so the new update log format will be "all the git commits done today + explanations of the git commits + screenshots" since I think that might give a fairly accurate presentation of my coding process.
So without further ado:
commit dd1a20ad760cf14a20d4174bb26486eae8100b5b
Split the GUI position part of the menu component into a new GUI component
this solves several issues: a the gui component is a good match for a
generalized "this gets rendered" component, so it's easy to make a system
that can iterate over all drawable objects; many things that are drawable
are not menus but still need positioning information; having bounding boxes
for everything drawn makes calculating gui hitboxes much easier
the height/width values are still unused; they're slightly harder to
abstract from the way they currently work in the menu code
When I started this project I started with the menu code, and as a result once I slowed down and thought about things a little I realized that the menu/menuItem components were really kind of globs of a lot of unrelated GUI information. I started rewriting the code to separate and clarify which parts of the code were really related to each other, and the first thing to go was the positioning information: a menu component stores menu information, and if you want to know where that menu is located or how it's shaped, then you need positioning information.
commit 12f7adc7150a9e14589390f5043ca49a671415b1
Removed render system; replaced with gui system
code to render components is now more in the components themselves rather
than strung out awkwardly from an external system
(though it still might be better to have it in a /related/ system but i
don't know if that's really possible)
...and once I split out the gui component from the menu component, something got a lot more clear. I'd been using a render system, which basically did a bunch of inefficient entity querying to figure out what things needed to be rendered. But now that there was a gui component that made things a lot simpler: anything with a gui component needed to be rendered, anything without a gui component didn't.
It's not an ideal solution, but it is a lot better than what I had previous.
commit 0580d74bfc324f75a412a14c5373397fe4b5bd87
added font unloading
Before this point the font texture data was never unloaded. This wasn't a problem; fonts were never re-loaded so there was no worry about a memory leak, but with memory debugging on I always got a 128-line output of addresses not freed on exit, so I figured I might as well fix that at least.
commit 88661627ae4eb0382d3976446eeb9884fd24866b
added very basic arbitrary shape drawing
Rooms can be made from arbitrary shapes; the support for creating and drawing them is very limited at this point. Very limited.
commit 2ce34f8a89a42eb416a686374c6c9f5c03a76148
Removed the menuText field in the menuItem component; wrote separate "label" component
Lots of things would be helped by having labels, not just menu items.
Further breaking apart the menu/menuItem components: an important part of menu items is that they have text, but the text isn't related to anything else about them, so it goes into a separate component. My only worry here is that this is literally just a string; there's no capacity for multiple labels or keyed labels, in the event I want to add labels to something more complex.
commit 09564ebcb15e37c74c00c33186eb291a712e8337
Removed menuWidth field from menu component; used guiWidth in gui component instead
Menus still stored their own width and height because they were tied more tightly to how they were drawn, but actually removing the internal width variable was pretty straightforward.
commit c8b1919a401318c8c3b45ee34cbe68405658e28f
Partially rewrote menuItem component into a more general "clickable" component
The other important parts of a menuItem: it responds to input, and it can trigger events when activated. It only does the former currently, since I haven't written up the event code yet, so it was pretty much a standard search and replace "menuItem" → "clickable" here, with some additional changes to keep the menu code from getting all up inside the clickable component data. It's still an interdependant mess (hence the "partially") since all the hit detection and rendering code are still dependent on being inside a menu component, but it's at least no longer got internals exposed to the menu component.
commit 22de8a43987408620e104b16e1ed3adabec79765
fixed a memory leak when an entity with no components spoke.
Entities can announce that they've done something or that something has happened to them, and in that case the message gets sent to certain other entities and all the component the entity has instantiated (this was before there was a distinction between components and systems; it's something I have yet to fully fix everywhere). The issue in this case was, well, if an entity had no components it still allocated the system message, but it was never picked up by anything or garbage collected since the garbage collection itself depends on having a reference to it in a system message queue.
commit 6a3371c9698a2909b93344b31ceeb3b53235a221
Added first-draft room component
It doesn't do anything and is rendered in a very poor fashion.
The big one. Rooms are ugly looking and don't do anything, but at least now they can exist and serve as a testing ground for clickable components that are not parts of a menu. Also once I get event triggering components I'll be able to hook them all together and hopefully get some kind of non-trivial response out of the rooms and the menus.
But for now they're just ugly tests
November 4th, 2011
commit 54602199b4d339b8bef87a3faff18be41ffd7651
Split clickable component into its own file.
commit bfa673d6850a06f3aa6c3dca8a50737d9c608c32
Clickable objects can now handle their own drawing.
commit e72d838f92cdd8bddf8699ad5713b907145c5bd8
Room hotspot entities are now made from general components
...instead of being a specific "hotspot" struct. The clickable component
still doesn't work on its own (i.e., outside of a menu component) all on
its own, but it's mostly there.
commit 009e06d61516fe11a1cef771af55ac9fec6831bd
Clickable component now handles its own input
(and is thus completely independent of the menu component) The input
handling in general is still fairly terrible (it's an all-or-nothing
thing) but for 2d ui purposes it's currently workable.
So, I finally fully split the component that handles reacting to click input off from the menu component. This means I can have buttons as completely arbitrary elements. Something to look into would be supporting gui elements of arbitrary shape and size and then having the gui component itself be capable of stating if a given coordinate was inside it or not, which would allow for arbitrarily shaped activation areas too. But that's not really of critical importance right now.
commit 571b65cb60aab60a27c9866373e6212bedab00d8
Added a vague kind of scoping for gui elements
GUI elements can nest inside other gui elements. Currently this only allows for a slight amount of grouping -- nested elements are positioned relative to their parent element, recursively, so this allows for a menu to lay out its sub-entities relative to its own position, and thus move the menu around without altering the menu items at all.
commit c719b93187d4215a7c2bb6aae5dccf059a33e188
Menus now have spacer elements, which allow for finer control over menu item positioning
...and on that note, menus have been retooled to mostly just deal with layout. They have spacers now.
There were also some entity updates, none of them particularly interesting:
commit 0ea0fd4592dd6d5c765a0699bf78cdbe1bca968a
only one component of a type can usefully be instantiated on an entity
(this isn't true really but the lookup will fail for the second instance
so you might as well forbid it)
commit 157cfc0a987ccf3da8f51b88f756f9901e084fb0
Entities now track their systems in addition to systems tracking their entities
this is good if we'll ever need to iterate through an entity's systems
without a lot of lookup (spoiler: we will have to do that)
(We will have to do that because what are currently queued component system messages will be redone to allow for system handling of entity messages. This is another left-over from the days of component systems, before they were split into components and systems.)
commit c45e28cac3868e667233af3fd87af4be03d8d5c3
Added rudimentary text field component
probably the most important; there's now a text field that just lists a long stream of text. Right now it doesn't do much, but it's going to be the most important part of the actual game. Once there is a game. So this is good to have working, even though it's "working" in a state that will instantly break the moment I try to do anything with it.
commit 9a21ca496d38c5dde231cde786bfa9b046af63b2
fixed a minor issue with clickable hit detection
it was one pixel too large; in certain cases (menus) this generated a 1px
overlap which meant you could activate two buttons at once. in the general
case (e.g., hotspots in a room) this is still an issue and it's somewhat
unsolvable given that there's no global hit detection
Bug fixes. Always bug fixes.
November 6th, 2011
Did almost nothing and then mostly fixed bugs and worked on the text field display today. Most importantly: I finally fixed the font glyph warping problem, which was actually cause by the same code as the "crash when loading fonts at certain font sizes" problem. So that's nice.
November 7th, 2011
commit bee255ac5dd81a6fe98af0a364144dbd000a85c4
added entity groups
commit 9b5bd403dc5a10654461ca0f07422f8847a5a8db
this will make sense in a commit or two
commit f711b4dc0c02a8757dfc3e552e8e87be175a7f42
Replaced the main.h "sys[x]" functions with more general entity-naming support
"this will make sense in a commit or two" as the entire explanation of a commit is pretty terrible. That particular commit added some gui code that altered entities when given a list of entities, when there was currently no commited code that could generate a list of entities. That's what the group code does.
A lot of this was just updating the entity code to be more generally useful — I had been using these "main.h" functions to deal with keeping certain entities in scope so that various pieces of code could mess with them (e.g., using an exit requires updating the gui so that the old room is no longer rendered and the new room is) and they were, as previously mentioned, a rather slapdash and not very good solution. So I replaced them, first with the ability to name specific entities, and then with the ability to add entities to a group and then get that group.
commit 12cc111d66be24f727cd320062f7ec9563fd50af
Added a "guiVisible" field that should control if a given gui item is rendered
commit a40ea9213c62c5aa5237433383add862ab9ae796
clickable things now only respond to input if they are visible
Yeah and then I made it possible to hide certain gui things and made things only render if they and all their frames were visible. This made layout a lot simpler, since I could just load up all the views and keep most of them invisible unless active.
commit b2335a44ad836985901e3a9ce5864df80f31a489
Wrote event code for all the menu buttons
commit b70f52580a0cb2cbbbab2d27c63a40fcd22f4223
Added a whole mess of gui components
They currently do nothing aside from render a blank box, but they're all
gonna be used eventually.
commit 99133d0ca4d746000fbf341d47d4bf68e960b1fb
Made exit activation code externally callable
I guess I am trying to centralize event code triggers in the event system
commit 49e43701b6bf4a1a0009a987cfd5f5e940d3c7c0
Added event system and renamed "trigger" component to "event"
commit d9ae719efd6323caee5afa074723d587abf09f1b
made input system process messages
commit 86adbcf939e7d45e93a6515e79909f9e3437d13d
disabled rendering system messages
commit 75d6922596851b36e150ba09ef30e23f460bb9cc
Rewrote system messaging to actually work with systems instead of components.
And I finally fixed the old issue of component systems, since even after splitting them apart all system messages still went to the components, and this made using systems in certain ways extremely inconvenient.
Between having a working event system and having entity groups, it was fairly easy to get the menu actually working. It doesn't look like much, because currently I haven't written the special components most of the menu panes will require, so realy all you can do is get the default layout or replace it with a single blank rectangle. But all the input works properly, so it's still good news.
Having done all that, though... well, part of what I'd like to do is add font colors, but that's somewhat complex and really I ought to be doing something more useful in terms of actual gameplay.
What I need to do eventually is to start loading the world data from data files instead of having it all hardcoded into the game, so I can write area files. But that requires writing a formal definition of what the area files look like and something that can parse that. Thankfully I can just reuse the OGDL parser I'm already using for config files, but that only solves the first half of that issue.
November 16th, 2011
Whoops, and then I didn't update for a while. For once it's not because I just stopped programming; I've still been picking away at the code and making larger or smaller advances, it's just putting together an update with the git commits and everything is a little more work than I'd thought, so I just procrastinated about that.
So what have I done since I last updated?
Things look different. Not massively, but substantally. Here's a list:
- All the sidebar menu buttons work, in that they bring up and close replacement panels for the standard text. They're all still blank, however.
- Travel through the world works
- Areas (currently consisting of rooms and exits) are stored in world files, which are loaded up when the game starts
- There's text coloring
- Text draws correctly; I fixed the persistant issue with glyph warping
- Extremely rudimentary events
What doesn't work still: pretty much everything else. I'm to the point, though, where I know exactly what I need to do to get things working, I just have to go through and write all the code. I must admit I'm not looking forward to that all, but I am looking forward to getting it all done.
Here are some things still left to do:
- Items and mobs, both as entries in the world files and in-game
- A working inventory screen
- A complete overhaul of the layout, that would remove the text scroll and replace it with a description of the current room, with event text appearing in an overlaid panel
- If-checks and branching in the world files, to get some control over events (as triggered by mobs or items or rooms)
- A player character with actual traits that can affect events
- Player (and mob) skills
- A title screen!
After that there's still a whole mess of stuff to try to get working, but getting all the above done would allow for a demo of most of the core features, excepting combat and experience mechanics.