Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Skullcoder

Pages: [1] 2
Programming / Re: Generic algorithms for complex data?
« on: June 21, 2016, 11:45:24 PM »
Pointers are a "simple" type.  Substitute arrays of a simple unsigned char type with arrays of pointers to a complex room struct (or linked list, or whatever), and Bob's your uncle.

"All problems in computer science can be solved by another level of indirection."
- David Wheeler.

"...except for the problem of too many layers of indirection."
- Kevlin Henney

Pointers are a level of indirection.  As are methods for working with 2D data of dynamic raster width in a 1D array.

Design / Re: Corridors considered harmful
« on: June 21, 2016, 11:31:35 PM »
"Save scumming considered harmful.
Don't allow saving in your roguelikes because this can be abused by save scummers."
That comparison doesn't hold, though. Save scumming is cheating, whilst corridor fighting is a viable (and in fact the optimal) strategy in most RLs. So in a classic rooms+corridors dungeon,  you need to balance the game around the assumption that the player will draw back whenever possible.
So, you agree...  The comparison was not meant to hold. It was an extreme example meant to illuminate the exact conclusion you've drawn.  I felt my point was clear: In a classic roguelike "you need to balance the game" assuming that valid player actions such as "draw back whenever possible" don't break the game, if that means smarter AI, so be it.

Thus, if you assume that saving the game is not a legitimate option and design a system that has resuming from save breaking the game then you've badly designed the game.  This doesn't indicate that saving itself is bad as a feature at all, which is what the comparison was for: To have you conclude, "That's preposterous, saving the game is a legit feature; reloading doesn't make a game crappy but other issues might".  And then go on to conclude, "corridors are a legit feature, something else must be the problem rather than simply having corridors themselves".  Broken game designs are not the result of the use of corridors, but the failure to design gameplay which addresses those who would obsessively exploit corridors.  The core point is that features such as saving or having corridors between rooms are not inherently shit, and that there are other factors such as faulty mechanics or exploitive behaviors at play.

Even considering a primarily cave-formed or room adjoined generation system, the exclusion of all corridors would be an oddity.  Corridors can be effective at creating a precise scenario that should be available to the (procedural) level designer, otherwise if one does appear your game might break.  Not focusing on such pinch points doesn't mean they won't exist.   Corridors themselves are not "considered harmful", but games which suck due to poor consideration of gamplay in corridors do exist.  Likewise, saving a game is not considered harmful, and games should not break on save/load (even if via external VM) but rather take consideration that saving and loading behavior does exist (just as corridor use exists).

Design / Re: Corridors considered harmful
« on: June 21, 2016, 06:03:51 AM »
"Save scumming considered harmful.
Don't allow saving in your roguelikes because this can be abused by save scummers."

Compare the above with the following:

"Corridors abuse is considered harmful.
Don't allow corridors in your roguelikes because they can be abused by corridor campers."

If the pinch points are exploited it's not the pinch point's fault.  Eliminating corridors won't remove pinch points, just make them less prevalent, and they'll still be abused by abusers.
Likewise, if the gameplay breaks in the presence of corridors it's not the corridor's fault.  Gameplay needn't break due to corridors.  A more intelligent adversary can exploit pinch points as well or better than most players can.  Dumb AI isn't the fault of corridors.

Bad dungeon gen that has shitty corridors doesn't mean all corridors are evil.

Translation: Don't do bad dungeon gen, and also don't use shitty AI.

Design / Re: Info line idea
« on: June 16, 2016, 05:20:28 AM »
Wow, ya, you're legit nuts, bro. "All larger gaming forums" are not "under subversive attack," even if you're silly enough to consider PR flacks for game companies "subversive."
You're just ignorant.  There are paid astroturf campaigns in all of the larger gaming forums.  Moderators of several gaming forums have been called out numerous times for being paid shills.  Hell, even on 4chan's /v/ where you'd least expect anyone to be able to subvert.  As for the other stuff, there are videos of the portable devices being used by lowly detention officers, of course COINTELPRO has more advanced secret tech at their disposal today.  The US counter intelligence program is carried out by secret police (DHS / FBI) and they use the Stasi's Zersetzung tactics.  The UK, France, Spain, esp. Germany all have similar programs in place to silence dissenters.  It should be common knowledge to you, esp. after the Snowden Leaks -- Which also revealed the widespread use of JTRIG techniques to subvert online forums.

You seem overly focused on painting others as "crazy" while remaining willfully ignorant even when presented with ample evidence.  Any roguelike fan is going to be one who digs into the details.  Do you actually play roguelikes?  If so, what is your stance on the use of Info Lines in their UI?  It seems you're here just to advocate for censorship and attempt to discredit anyone who advocates freedom from closed minded safe spaces...

I would like to point out that you're acting like the worse troll ever.  At least Krice isn't insulting people by claiming they have mental health issues.  I guess you should advocate for yourself to be banned now.

A good place to start would be offering a convincing narrative of the stakes involved in what you're talking about re: game forums, since at first glance they appear to be nil, and some analysis of how it could make sense for some malign actor to invest resources in view of those stakes.
Would you acknowledge there are vested interests who pay online shills to promote movies?  The games industry is bigger than the movie industry.

Design / Re: Info line idea
« on: June 14, 2016, 10:00:40 PM »
What I will tell you is that none of this has anything to do with this forum with 15 users. Obviously.
You brought up the term "targeted individual".  You thought the comparison would paint me as a nutjob, but I thought I should educate you just in case you've been disinformed and aren't just willfully ignorant.  This is a fourm and even small forums are frequently targeted.  As the Gentleperson's Guide to Forum Spies notes, size doesn't matter.  Subversion targets anywhere new information outlets exist with the potential for greater audience.  There are numerous examples even on small Usenet communities about niche software.  I'm not saying this forum is actively being subverted but the possibility exists.  Since the roguelike[-lite] genre is becoming more mainstream and all larger gaming forums are under subversive attack even if just by advertising shills, this forum could easily become a target if it begins to grow beyond "15 users".  Obviously.

Also, am I correctly understanding you as believing that so-called "gang stalking" is actually real?
I didn't say I did.  Nice assumption though.  No, "gang stalking" isn't real, but coordinated psychological operations by unofficial collaborators are part of the real COINTELPRO and Zersetzung tactics.  Since you seem interested you should have read up about Zersetzung, which I already linked to, but you seem exceedingly resistant to any information not matching your literally ignorant narrative.

The Stasi in Germany called that specific technique "street theater" when they used it and it was called this in the US/UK too until the more recent wave of disinformation re-branded the documented use of "unofficial collaborators and informants" under Zersetzung as "gang stalking" or "cause stalking" to more easily discredit those who complain about it.  In the same way, "targeted individual" is used rather than "political dissident".  The Internet is rife with false claims of such attack sometimes by legit crazy people, but the use of the tactic in question is a documented fact.

I guess next you'll say, "am I correct in understanding that you believe secret police will break into a home just to rearrange the furniture of a political dissident?", and my answer is "yes" because this is also an extensively documented practice in Zersetzung, and a complaint of those targeted by COINTELPRO.  If they'll do that why wouldn't they have a few people in a crowd or neighborhood harass some political target in their effort to make them seem insane?  The Germans deemed dissidents as insane and had them reeducated, or put them in a mental hospital, typically after a Zersetzung campaign to generate evidence of "mental derangement".

Street theater is just one method among many of organized psychological warfare, with over 5,000 documented cases revealed after the Berlin wall came down and the Soviet union collapsed.  It's not far fetched to assume the method is still in use today, considering that the directed energy weapons that "targeted individuals" complain about are also real and have been in steady development and deployment since the 1970's.  There are patents for the devices in the US Patent database.

For someone who apparently knows about this stuff you obviously have ridiculously flawed opinion of it, and I therefore question your ability to form opinions in regard to everything else you advocate for.  You might want to try basing your opinions on evidence, history and experience rather than propaganda and disinformation.

I'm not your personal Google, so that's the last I'll say on the matter.

Design / Re: Info line idea
« on: June 13, 2016, 08:40:19 PM »
@Skullcoder: Uh, I can 100% guarantee there's no chance of the forces of darkness developing an interest in discussion going on here.

Yes, "the forces of darkness" are mythical.  However censorious authoritarians are not.

While there surely is plenty of the kind of thing you describe out there, the connections you're drawing here are a reach
Those links are simply points of evidence that support a general claim of political correct authoritarian censorship. A forum topic about a completely unrelated topic is not the place to dump an overwhelming amount of evidence.  The scientific minded individual would further research the claim given that these breadcrumbs exist, and fill out the graph themselves coming to a conclusion of their own afterwards.  The ideologically minded simpleton is trained to ignore such data points and ignorantly reinforce their stance that anyone poking holes in their narrative is a conspiracy theorist (or use some other deflection device).  To those that care, you'd do well to read the Gentleperson's Guide to Forum Spies,  and Traits of the disinformationist.

If you grant that these cited events are not fiction then it adds credence to hypothesis.  You've got your mind made up and are impervious to reason, so I'll not waste any more time debating the nature of reality with you.

Sounds like "targeted individuals" kind of talk.

You obviously don't investigate claims before forming your opinions:  That's so ignorant it hurts. The terminology "targeted individual" is included in documentation and marketing of The Active Denial System.  Does the use of that term discredit all claims that such systems are in use by COINTELPRO in your mind?  Protip: There are active disinformation campaigns to make claims of such systems being used against activist appear "crazy".

This place probably accounts for less than one tenth of one percent of the broader discussion, the vast majority of which goes on in irc channels, mailing lists, and forums devoted to particular, actual games. Further reason to doubt the supposed prophylactic value of rudeness.
And also a reason to doubt the supposed value of silencing rude people, since there's no one here that needs a safe space devoid of any words they may choose to take offense from.

Design / Re: Info line idea
« on: June 12, 2016, 12:38:18 PM »
  Krice may be single handedly defending the Temple from Orwellian speech codes by acting as a caustic test for thin skin. 

Okay, I rest my case in the face of such next-level rationalization.
That's one hell of a non sequitur.  I think you missed "may".  No reason to make leaps of logic if hypotheticals aren't your thing.

However, if nothing else the existence of rude folks with harsh language is a time tested canary for free speech online.  RLs are doing better than ever even though Krice is here.  The burden of proof is on you to prove harsh people are a detriment to the forum.  I assert the null hypothesis to claims in the contrary: People who rage quit mightn't be the kind of folk you want to be around.  Gods forbid they dev a roguelike and have to handle an even larger dose of harsher criticism from the world at large...  There are plenty of popular forums where being crass is common so I'm not convinced a little foul language is the reason this site has low traffic.

Going back to my earlier analogy, these Japanese  soldiers they found after 40 years on remote islands also thought there`s a war still going on - but there wasn`t.
If anyone is ignoring the reality of the situation it's you, and that could be a hazard to your health.  There's mention of examples of Voat and reddit forums being subverted in this very thread.  Recent experience has proven that games are certainly not off limits in the culture war.

E.S.R., Linus Torvalds and many other prominent people in Free (Libre) Open Source Software and STEM have been the target of Stasi style Zersetzung attacks for not towing the Politically Correct line.  Take the case of the late Ian Mudock (Ian of Debian, founder of one of the most popular Linux distributions).  This has familiar elements reminiscent of other attacks against activists, such as this Fresno man who was critical of police corruption. This guy spreading non-politically correct messages predicted his death and was found stabbed to death in his burned down home.  It's not just forums that get subverted, but everything from FLOSS projects to education and even police forces.  Let's compare the claims like rational beings: Got any evidence that the subversive war isn't still on?  You'd have to ignore that the subversion warned of by that ex-KGB agent all those years ago are seen playing out in today's culture at large.  You'd have to ignore the recent ideological schism in the indie game community which boiled over even into the mainstream press, even spawning a Law and Order SVU episode.

I've been a target of some shady shit myself in the recent past.  It's nice that you can proclaim "the war is over" since you don't have bullets whizzing past your head, or false accusations sent to your place of business for an article you wrote in the gaming press...  Personally, I'll stay vigilant and keep spreading awareness in hopes others don't fall victim.  Modern day subversion is a real threat.  I merely warn of the methods that are employed.  Thankfully this place isn't fully on the front lines of the culture war, but it could quickly become such.  You need only examine the ideological slant of some prominent community members to see the possibility.  Personally, I hope roguetemple remains neutral territory.

I warn against advocating the silencing of others, no matter how much offense you choose to take at mere words.  People like me are a counter balance to the claim that rudeness is scaring people away.  If rude people and caustic language weren't allowed here I wouldn't have signed up.  If the canary is dead, I don't go into the mine.

We need games that take everything that was good in roguelikes and go beyond it.
I wholly agree with this.

Off-topic (Locked) / Re: I'm moving to linux.
« on: June 11, 2016, 03:30:23 PM »
C++ is a bit better than C, but it introduces its own exploit vectors: You put pointers to code on the heap to implement their "virtual function" VTable for polymorphism.  This means that any data structure overflow (not just a stack overflow) can overwrite a pointer in C++ and result in code execution vulnerabilities.  If you just stick to C and don't try to implement any OOP (putting function pointers in structs) then your attack surface is very small.  C++ doesn't do range checking on arrays by default so it's not really any safer than C (consider that the STL still uses the underlying plain C data structures) so that's why the "safer" C++ string interface has about 10 remote code execution vulnerabilities out right now.

Languages like C#, Python, Perl, PHP, etc. just add more attack surface full of holes to exploit via increased codebase size available to exploit to provide their convenient functionality.  A C or C++ program that links only what it uses has a much smaller attack surface than, say Python which every single program presents the entire huge attack surface.  There are great big bugs in Python, Perl, etc. interpretors which mean that damn near every program that uses them is succeptible to exploit.  Let's say your program doesn't use some feature that's exploitable.  In C / C++ that won't get compiled in, but in most VM / scripting languages that code will be present to the host environment for every program that runs and thus accessible to exploit.  That's why Java Web Applets became such a HUGE security vulnerability even though Java is supposed to be a virtual machine language and thus incredibly sandboxable.

Static analysis, unit testing and input fuzzing toolkits exist but few projects actually use them.  Besides, someone had to write that unit test or static analyzer, and they screwed up somewhere.  If they didn't screw up then eventually they will be screwed up because people just can't leave languages alone and let them be hardened, you've got to keep making new languages and adding more features and causing more bugs that prior code didn't expect.

C++ is used in Chrome, but it calls out to C libraries like OpenJPEG, and Chrome devs NOOP most asserts in release code for speed, but some libraries depend on assert to catch things like the buffer overrun which can now cause remote code execution by reading a PDF with Chrome.

It would be great if we could write libraries in C++, but C++ is just C with a fancy preprocessor, so to implement method overloading it munges the names of functions by adding some gibbering to encode the type of parameters in use.  Each compiler does this differently because the C++ standards committee is full of idiots.  That means you can't call a C++ function on a library unless everyone is using the same compiler and potentially the same compiler version, because your different compiler might tack on some different gibberish.  They SHOULD have just started from scratch and thus had a different intermediate object representation to supply to their own linker, but since all C++ implementations rode the coat tails of C and used a C linking subsystem, they got stuck doing kludges like this.  Because the idiots in the standards body thought that dictating an object representation was beyond the scope of C++ standardization it's been decades before the C++ compiler implementers have finally started to get together and hash out a way to make C++ actually able to produce libraries that work across multiple compilers.  You'd have thought that basic feature would have been priority #1 for any language, but it's not because C++ is not managed by smart people who care about interoperability, and thus don't give a flying fuck about security.

And here's why: The real messed up thing is that sometimes two C++ compliers will appear to generate the same munged name for a method call.  Your C++ program calling into another library made with C++ will appear to work, but both are supplying different parameters to the function call, and thus smashing their own stacks.  This might not become apparent until some buggy behavior is noticed at best, or at worst systems are being compromised by the messed up code you released that is only messed up because of bad decisions the C++ implementers and standards bodies made, not because of any of the code that was written in their languages.

There's not really any "computer security" because no one gives a fuck about "security".  They just expect to fix their broken shit whenever people complain loud enough about a specific case of "security" being compromised.

Sorry for all the ranting, but it's just sick how the whole software industry pretends that "security" is actually a thing they care about.  It's not, that's just a marketing term.

Off-topic (Locked) / Re: I'm moving to linux.
« on: June 11, 2016, 02:48:12 AM »
Stock Ubuntu Linux was sending your Unity App / Doc search results to Amazon and embedding purchase recommendation affiliate links in the results for things you're trying to find on your system.  Fortunately, you could actually turn that behavior off, but it was on by default.

It's only marginally more difficult to put sneaky shit into Open Source software than to get your malicious backdoors into closed source software.  Microsoft is actively snooping though, so by default a Linux or BSD distro is going to have less backdoors in it.

Security from state actors or targeted attacks is practically zero for any OS on this planet (aside from some Alternative / Experimental OSs which are small enough to actually audit but lack all the features you want).  Security from malware thugs is better on Linux and BSD not only because you're a smaller target (less desktop users), but also because Linux is so fucking fast at fixing bugs.  I submitted a critical vulnerability to Microsoft 5 years ago which is still not patched, and they've released two OSs since then and all OSs from Vista on up are vulnerable.  I've submitted a dozen bugs this way to MS and only 3 have been fixed, the other 9 are still valid, but are going ignored because MS only really cares about their latest OS.  I've sent over 20 security patches to the Linux Kernel and all but two have been accepted.  Two were no longer bugs because something else changed the the codebase.

If I published my exploit code then MS would be forced to fix it when bad guys started using them to infect systems with malware.  I won't publish the white paper and proof of concept code publicly in order to keep bad guys from using it.  There's a "Responsible Disclosure" code to let vendors like MS have time to fix a bug after notifying them that white hats try to live by (esp. ones who aren't pressed for time to disclose vulns on their blogs for advert traffic; most security researchers are under pressure, but that's not my day job so I don't have such pressure).   

On Linux and BSD most people don't use "Responsible Disclosure".  All exploits are just bugs.  If MS published their source code I would fix the vulnerabilities myself and they'd just have to review the patch and apply it and be done.  That's how it works on Linux and BSD.  I find a critical vulnerability that enables remote code execution and then I fix it and get another patch into the kernel, Apache server, or some other system.  The FLOSS ecosystem is so much more hostile for viruses to live in because if there ever is malware crawling around, we disassemble it, find the bug it exploits, and get the patch out to everyone the same week or even the next day in some cases.  Frequently I've seen a bug in the news and that morning my Linux OS updater had already patched it.

Microsoft only releases patches on the 2nd Tuesday of every month.  This is GREAT! (for malware authors) because they know not to push their malware out until just before the 2nd Tuesday so that they have the most time to run amok before anyone even has a chance to get an update if it's deemed critical enough for MS to pay attention to.

Now, not everyone notifies the software vendors of the bugs they find.  Some greyhat and blackhat hackers sell the vulnerabilities they find on the black market.  There are several attack toolkits which allow you to add some boilerplate code to your exploit and package the vulnerability for use with whatever payload code a customer wants.  I use them for penetration testing, but bad guys use them to attack systems.  A script kiddie buys or make a malware payload in damn near anything, I've even seen malware as Python scripts (compiled into an executable with Cython).  Then they simply buy one or more 0-day exploits on the market which have wrappers for the exploit toolkit the skiddie is using.  Then they literally drag and drop the malware together, joining the exploit vector with the payload.  You don't even have to know how to write code to be a "malware publisher" today.

As it turns out, there are FAR MORE exploits on the market for Windows than for Linux and even fewer for BSD.  Mac and iOS and Android are steadily climbing though.

As I said, even though Linux / BSD etc. are somewhat more secure, it's still pretty easy to get shady backdoors into Free (Libre) Open Source software.  Let's take the case of Heart Bleed.  A bug in the OpenSSL library that many web enabled servers and applications use for their TLS / HTTPS security.  The code has a "performance optimization" where they keep a memory pool of objects rather than calling free() and malloc() they get memory from the process's pool if it's available and return it to the pool when not in use.  That memory pool is used by all sorts of code in the OpenSSL library, and can contain the private keys for your connections.  When this is combined with a buffer overrun error which causes OpenSSL to fill a packet with "junk" data beyond the small response data you can leak some of thah memory pool and sometimes it can include parts of the server's key.

Now, the patch that introduced the buffer overrun bug which copies more data than should be sent was accepted to the OpenSSL codebase on New Years freakin' Eve while everyone in the world was getting shitfaced and not paying attention.  This is the sort of thing that state actors do to introduce bugs.

Even a code audit isn't necessarily going to find the bugs because we're humans and our brains make us see things we expect to see even if it's not quite the right thing.  This is why proofreading your own writing is near impossible.  Well, with code it's even worse because it's following familiar patterns so we know what to expect even if we've never read the source before.

Code: [Select]
if ( command  == UPDATE_ACCESS_TIME && user = root ) { return fstat( ... ); }

Some people might read past this in a block of code and think everything is on the up and up.  In fact, if this was in a patch that was changing instances of the costant UPDATE_FILE_ACCESS to UPDATE_ACCESS_TIME then you especially might not notice that the '==' was changed to a '=' in the patch you just accepted.  Now when the UPDATE_ACCESS_TIME function of this code is used it also sets the user's level to root rather than just checking if it's root level.

There are people who make a living selling malware or working for governments that are combing through code just looking for exploitable places like this, and if they find a spot that a small modification might make exploitable them they submit crazy patches, maybe on New Years holiday and have their inside guy accept the patches when everyone is distracted.  Of course the maintainers have plausible deniability.  "It looked good to me, shit happens".  in the case of OpenSSL the maintainers were so fucking inept there were security bug-fixes in their issue tracker for years.  They changed to another issue tracker and didn't put out a press release, and then they even stopped looking at the issue tracker they were supposed to be getting patch requests through.  This for the most used SSL library on the planet?  It reeks of a con job, and that's how "secure" open source software can be.

Just because everyone COULD look at the OpenSSL code and just see how shit it was (and many people had, and have been bitching about it for years) doesn't mean the bugs will get fixed at all, unless some serious shit like Heart Bleed goes down and everyone has to pay IT overtime to generate new SSL keys for their servers and test it all out to make sure no old keys are lingering about...  You see, when that happens you're supposed to just be able to publish a revocation certificate and then browsers are supposed to check a certificate they have to make sure it hasn't been revoked.

Well!  Chrome doesn't do that!  Chrome and the open source Chromium it's based on uses it's own janky system where the browser keeps a list of the certificate revocation lists for the "top sites", but if you're not a "top site" (whatever that means), then Chrome / Chromium do not check to see if the cert is revoked at all and so crackers can use your old exposed invalid certificate and spoof connections even though your site is trying it's hardest to be secure.  Why does Google do that?  To save a few milliseconds on the first time you make a connection to a website in a day.  Oooh, so much "faster" than Firefox... Yeah, because it cuts corners on security.  And they get away with it because NO ONE CARES ABOUT SECURITY.  "Secure" is just a marketing buzz word.

That's not even the half of it!  We have known bad actors with shit security policy as TRUSTED ROOT CERTIFICATE AUTHORITIES who get hacked by skiddies multiple times with no repercussions.  Oh, and if you check your certificate list the fucking Hong Kong Post Office is a trusted root Certificate Authority!  That means the Chinese government (and any other government that's in your root store, Saudis, India, Russia, USA, Turkey, anyone really) can insert themselves between any connection and you'll see a big green "this site is secure" bar and everything.  Unless you manually check the certs you're using on each page load there's no way to know the connection is secure.  And how are you even supposed to find out which CA is SUPPOSED to be granting the certs for the site in the first place?  A web search over your possibly hijacked and intercepted connection?!

I say this to point out that there is really no such thing as "computer security".  There's just relative levels of exploitability.  Every damn OS and large software project is so full of holes that damn near any security researcher can crack it with the most minimal of application of force.  I just lean on a library by throwing in some random values until it crashes (input fuzzing) and sure enough I'll find a way to make an exploit to break it.  Even the damn libpng reference library had a fucking buffer overrun remote code execution vulnerability sitting in it for DECADES and no one noticed, even though EVERY implementation of PNG decoding involved reading the reference implementation code.

Writing and testing code to be very secure is hard.  No one actually gives a fuck about security, and so you get as much security as you paid for: NONE.  This is true for Microsoft, Linux, BSD, Mac, iOS, Android, Tails, Plan9, BEOS, and every other OS that will actually run on your damn insecure hardware!  Yes, even the motherboard, hard disk drive, NIC and etc. firmware contains crap code full of holes.  Everything you depend on for "security" is swiss cheese.  That's the real reason Microsoft takes so damn long to patch exploits that aren't being used in the wild: They know the whole damn hardware / software stack is crap, and there will just be more exploits found tomorrow.

That said, at least Linux isn't OPENLY trying to spy on you, unlike Microsoft.

Design / Re: Info line idea
« on: June 10, 2016, 09:35:13 PM »
But whoever thinks that bunker mentality and arrogant front will help the cause, they`re kidding themselves.
Funny thing, but I still visit the same local BBS I used as a kid.  It was full of old geezers which are mostly dead now, but the bunker mentality has kept the BBS alive while iteration after iteration of ICQ, Yahoo Chat, Friendster, Myspace, etc. have blossomed and wilted, like so many tool-tip triggered Info Lines.  Not that I think this place should be a bunker, but just that RLs have always been niche and never appealed to the unwashed masses.  Social people played all their video games at arcades, the masses had an Intellivision or other console, etc. while RL players dabbled on "limited" terminals at university or at home on P.C.s that were more expensive than consoles.  The "Muh Graphics" folks were around bashing Info Lines even in the 8bit era, see also: the perpetually undead Demoscene.   I think your rose colored glasses might need some more tint.  RLs are doing better than ever.  Whether this is due to the "bunker mentality" or despite it is moot (in both UK and US meanings of the word).

The kids will just move on, streaming around this place like US did with those small Japanese island-fortresses in WW2. And some of the "true" RL devs won`t bother coming here either, because of the bad rep.
Most kids are childish impulsive spoiled brats, esp. when it comes to the games they say they "love" but only DL the demo, play it once and then never open the app again.  RLs are expressly designed NOT for that type of mentality.  No one is surprised that toddlers hate Backgammon.  And yet that ancient game is still around, just as good as ever, with more players now than ever before, and despite its terrible Metacritic score.  To say nothing of chess...

One hacker social engineering tool is called the "social filter".  A social filter is a porous barrier to entry that when exposed to the flow of persons naturally screens out all but a desired set of individuals.  A social filter typically works passively, usually to select for people most susceptible to the sort of influence the engineer wants to wield.  Layers of filters can be applied gently so that only those with a very specific mindset are targeted.  There are naturally occurring social filters too. The nature of roguelikes gameplay is a sort of social filter.  It's folly to compare the level of attention that classic RL gameplay attracts to that of games with dumbed down gameplay designed to have as little filter as possible and thus ensnare the greatest number of general public (who mostly abhor the cerebral exercise oldschool-ish RL's demand).  You can't expect to pack an entire screen worth of data into a single Info Line, nor should you expect all gamers to enjoy roguelikes.

Point being: The foolish foxes will always pass by and shun our delicious grapes.  Such is the RL social filter.  Just exposing more people to RLs is all it takes to cast our net.  What we should be aiming to catch is more devs who will work on classic / hardcore / traditional RL gameplay.  Unfortunately when motivated by money any perceived barriers to entry come crashing down and the result is a stunted RL, Roguelike-lite, or even more distant descendant that exhibits only minimal commonalties with classic RL gameplay that use heretical icons in place of a traditional Info Line.

Just take a look at DF or Cata forums, even though dedicated to single games, these places are buzzing. Here, not so much.

To be fair there's no 'Temple of the Roguelike' game to attract players and their eyeballs and fingers.  There hasn't been a kickstarter scale advertising adventure with roguetemple in the title.  Those games forums were able to apply their filter more broadly because they could use game content as bait.  You have to come hunting for the entrance to Roguetemple, with an open mind to new Info Line ideas, and hungry to expend your hunger clock further on discussion alone.

If official DF and Cataclysm discussion subforums were here instead then this forum would be buzzing too.  Players buzz around the game they like.  I think there could be ways to improve readership and participation here but the implementation would require so many Info Lines that they'd be more of an Info Block and thus beyond the scope of this thread.

That said, I see Krice and others here as part of a social filter.  We may actually be better off with more Krices.  Linus Torvalds is notorious for his scathing criticism of idiocy.  This is a social filter against those who would be offended, as are the zany Linux kernel names.  Time and again we have seen the permanently offended gain a foothold and then destroy a community around a software project, and the project itself too.  Mozilla is in the death throes of such an internal battle of the crybullies, and it sadly shows in their browser since key talent is jumping ship.  Many people have Ragequit the Linux kernel development community over taking a flaming from Linus, and that's a good thing. They were thin skinned spoiled brats who threw a tantrum for not getting their way; The filters are working as intended.

Even if you think Krice only a negative influence, a roguelike fan should be acquainted with taking the bad with the good.  Krice may be single handedly defending the Temple from Orwellian speech codes by acting as a caustic test for thin skin.  A forum without a troll to keep our guards raised is ripe for subversion by malevolent social engineers who secretly seek destruction or despotic control but peddle their thought policing in the guise of promoting a "nice safe space that's welcoming to all" (except those "rude" boys they banned for wrongthink).

First they came for the trolls, but I did not comment because I was not trolling.
Then they came for the rude boys, but I did not comment because I was not rude or a boy.
Then they came for the Info Liners, but I did not comment because I prefer stat bars.
When they came for me there was no one left to comment.

Design / Re: Info line idea
« on: June 09, 2016, 01:39:41 PM »
The whole concept of roguelikes is so ancient and many developers think it should remain like that. I don't agree with that. That's why it's easy to surpass them. And I'm not even doing anything special, just thinking that there can be something else than copying 1:1 old roguelikes like everyone seems to do.

I agree the roguelike genre needs a few shots in the arm. In some cases it's happening as many games become popular by being less roguelike than roguelike-lites and borrowing only a few roguish features.  Popularizing the RL labeling (even when incorrectly applied) has attracted some new roguelike devs interested in making what's old new again.

I'd disagree that it's easy to surpass long running projects like Nethack.  It may be easy to come up with better designs, like this Info Line Idea (now with visible history), or Gods that employ Machine Learning, etc; However, at some point one has to factor in all the dev hours it takes to get something as complete as one of the big old games out of the dungeon and released. Therein lies the "difficulty"; Even more so for One Man Army development teams.

The big old roguelike projects have had the benefit of having many devs and/or starting out modifying a working game (one way to get devs), or at the least borrowing heavily from an existing working design (but forever being a slave to past design decisions).  There's a reason so many devs start out (re)making a crusty "classic" roguelike, and there's nothing wrong with that.  It seems impossible for most devs to avoid coming up with fresh ideas while working on any old project, whether they can make them a reality is another story.

For instance, here is the W.I.P. tile sheet for the Roguelike that Derek Yu was developing when he came up with the idea for Spelunky and made that instead.  I personally wouldn't say that Spelunky surpassed Nethack or ADoM as a roguelike since it's so far from the original genre and is much closer to Notch's Infinite Mario than a RL, IMHO.  It's the extreme example of adding new things to a roguelike (so much that it's not a RL anymore).  If only more devs didn't pander to the Fakebook generation with such dumbed down gameplay we might get more innovations in the hardcore RL genre.

It's hard to compare any solo project to a decades old existing game.  1 Man Army successes seem to be at the cost of neutering much roguelikeness.  Personally, I'd avoid spreading FUD about ambitious solo projects.  They rarely materialize because of the time and effort required to climb that mountain, not due to any fault of the developer (except for being ambitious).  Props to the "starving artist" devs that actually try to pull it off.  We can use all the dedicated souls we can get. 

P.S. I like shy Info Lines that autohide but aren't so timid they disappear before I'm done checking them out.

Design / Re: Info line idea
« on: May 31, 2016, 03:59:17 PM »
As much as I enjoy BBS politics, I'm far more interested in the fate of this Info Line character.

Info Line seems utterly dead, having been chopped into three pieces then disowned by its parent, but have we really heard the last of the Info Line?  Mightn't further developments demand Info Line's resurrection?  Perhaps the transient Message Box will bring Info Line back from the dead as a slavish companion?

Will keyboards ever measure up to mice in terms of cursing at look targets?  Is the plight of this Info Line caused by Roguelikes themselves straddling the gap between line based and graphical displays?  These and more thrilling questions remain.

With nary an animated GIF to sate suspense or spurn speculation, we wait with baited breath for the next installation of 'Info Line Idea'.

Having functions that operate on the data separate also helps in organizing the code and reduces amount of 'doers', 'managers' and 'utilityclassxes'. It also helps to answer the question "if I want to read a scroll, who has the method? character, scroll, some manager?".

I agree with and enjoy the procedural and functional paradigms.  However, I think that "OOP" suffers from its own flexibility.  The name "method" is poorly chosen, IMO, as is the term "function".
In fact, I also object to "object" as it's objectively been selected only for the purpose of requiring an object lesson in ambiguity rather than objectivity. QED.
I hold a similar stance on the objectively subjective terms "definition" and "declaration", but I digress.

Despite my admittedly unpopular views I do recognize the value of Agent Aware Programming.  An agent is like an "object", except is should be clear that an Agent can act, while objects are only acted upon.  Thus in your example, the ambiguity is easily resolved.  The scroll is an object.  It has only properties and does not perform actions of its own.  Thus it is the Player (or some other Agent) which should activate its .read() action while passing the Agent which scroll to read.   Spells act upon the world so they are Agents invoked by Players or other Magic capable Agents.  Which Spell to invoke when reading a Scroll is a property of the scroll entity.
Code: [Select] scroll ){ scroll.spell.invoke() }
... scroll ){ scroll.identified = 1 }

In other words, OOP shouldn't be "objects all the way down".

One of the things many OOP implementations fail at is they neglect to provide their objects with a facility to determine what container object they may be a property of.  For instance, an object can access its properties.  Properties should be able to determine the object to which they are attached.  This is far more useful for the same reason that a doubly linked list is more useful than a singly linked list.  In theoretical terms, the "" relationship is broken in nearly all OOP implementations' symbolic dimensions, as the relationship is only accessible from the scope of one half of the pair.  This is the cause of many unnecessary headaches in today's OOP languages.

For instance.  If the Spell is invoked, how does it know to delete the scroll to which it is attached or if it is attached to a scroll at all?  Most OOP systems would force you to pass spell.invoke() an optional scroll reference and if it's a non nil value, then the spell would destroy the scroll object passed in -- Or, perhaps you fall into the trap of adding actions to POD via giving scrolls a state transition, perhaps through data hiding: scroll.setRead( bool ){ ...; destroy( self ) }, which causes the the scroll to be an Agent with actions of its own to perform (or object with methods), thus causing the "Classness" to proliferate onto what could otherwise be merely a data structure.

Perhaps I should explain first that a "symbolic dimension" is a language construct imagined as a dimension of the n-dimensional language-space.  So, when you create a construct, such as the ability to give a symbolic name to an offset in memory (create a variable) you are mapping the data dimension to a symbolic dimension.  The same symbolic dimension that allows you to name global variables allows you to name properties of structs.  Each property of the struct is a named offset in memory, relative to the struct's starting address.  Therefore the variable naming symbolic dimension is universally applied in these examples.  In a "complete" language you would be able to apply any symbolic dimension (any language construct) to any language primitive.  Furthermore you should be able to traverse in either direction along an unbroken dimension, in order to reverse the mapping.  C (and most languages) fail at this because there's no way for me to say: Give me the name of the property at memory offset 0x100, or Give me the Nth property name of structs having type T.  Likewise the symbolic mapping between is broken.

Instead, consider an unbroken symbolic dimension of mapping:
Code: [Select]
// If a spell is the property of a scroll, the scroll is destroyed upon invoking the spell.
Spell.invoke(){ if ( typeof self.owner == Scroll ) destroy ( self.owner ); self.applyMagic(); }

This codifies the relationship of "ownership" which RAII implicitly creates, but I digress.

Though I've been using c-like pseudo code syntax a RL need not be so.  However, since Java, JS, C/C++, and a host of other languages use similar syntax, an RL lang might benefit from the principal of least surprise by adopting some commonly familiar syntactical idioms.  On the other hand, in keeping with the roguelike spirit a RL lang might utilize as many strange symbols as possible, as RL players (and thus devs) tend to be able to cope with such things more easily than others...  I've always found it odd there weren't more roguelikes implemented in Perl (oh look, another C-like syntax [or more correctly called Algo-like syntaxes]).

And yet, on the gripping hand, a Roguelike language that allows new symbols to be added to the Lexer's tokens in order to extend the language, could also have an "import Roguish" which would randomize the language's syntax using the source's file name as the seed.  Then the programmer would get to play a Rogue-like identification game where compiler errors act as your identify spell, and you slowly get to learn what symbols to use in the source file in order to program -- Need to rename the file?  Sorry, that causes confusion which lasts until the source is reprogrammed to use the new symbols and may result in project permadeath.  Note that removing "import Roguish" would have the same effect.

I'm not saying that an OOP or Agent Aware paradigm is required in a RL language, simply that such things are useful and probably should be possible to use as the optimal RL language would probably support multiple programming paradigms.  This is one reason why I implement virtual machines before languages, so that one need not cram every paradigm under the sun into one language syntax.  Multiple languages can compile to one common bytecode, but I'm getting ahead of myself.

I like syntax of lisp quite a bit, so I think I would take that as a base.
I like the reflection and dynamism of Lisps, but think the syntax could be improved : )))))))
Using the Sexp for everything is powerful because it simplifies the implementation of self modifying code, or self aware code (macro facilities).  IMO, Lisp is a nice language to write programs that write programs in...  However, any new language can gain the features of and/or surpass Lisp (esp. in terms of usability) so long as: the compiler is self hosting, the macro language is the same syntax as the programming language, and the syntax tree being compiled is accessible from within macros.  One could take things a bit further and have the macro language be aware of the tokenizer too.

Personally I prefer compiled languages with strong typing because it catches a crap load of errors at compile time.  I can't tell you the number of times I've had to resort to hunting through diffs line by line for hours to chase down a bug in a large library coded in dynamically typed languages.  IMO, dynamic typing is great for small projects, but its usefulness is quickly outpaced by the pitfalls introduced.  Case and point: Most successful dynamic languages eventually adopt a "use strict" facility to enable stronger type checking.  Strong typing need not restrict run time dynamism in a significant way (though in most strongly typed languages have little to no dynamism).  Duck typing with compile time type analysis can yield much of the freedom that purely dynamic languages have, while introducing far less headaches.  "Adapter typing" is another feature strongly typed languages can use whereby methods with the same parameters but differing names can be mapped from one type onto the other to add more dynamism.

The key feature missing in most compiled languages, I think, is they lack a runtime scripting language that is the same syntax as the compiled language.  IMO, if you find yourself "embedding" a scripting language then the core language has failed you as it lacks valuable features you need (namely, ability to compile code at runtime).  "I heard you like languages so I put another language in your language so you can program while you program", ugh, no, that's just shameful.   IMO, the optimal compilable roguelike language would include an embedded scripting language which is of the same syntax as the compiled "host" language.  Thus, enabling the compiled code and scripted code to transparently call from one into the other with no "wrappers" or "binding layer" required.

Scripting languages tend to become prohibitive to use for performance intensive computation when they're not designed to also be compilable.  With a compilable scripting language: A complex script running too slow interpreted at runtime?  Have it compiled at compile time rather than runtime, and it goes faster with no change to the code.  Want to quickly prototype a feature without recompiling a bunch?  Just implement it as a script, then have it be compiled later when you're done rapid prototyping.  This would also greatly assist in adding "mod support".

Think about it: A macro language is simply a scripting language that runs at compile time.  If you could link with the compiler's "macro facility" code in your program, presto you have an embedded run-time scripting language.  All the better if all three (compile time, macro, and runtime code) share the same syntax as the compiled language -- Unlike, say, C/C++ or Assembler preprocessor macros.  IMO, it's as easy as reusing the compiler's code: Make the compiler part of the standard library's API, and if it's used then the compiler's code gets included.  Having a design goal of (optional) compilation tends to improve performance over languages meant to be interpreted like Lisp and JS which suffer loss of language features to compilation constraints (I wish Lisp Machines were still a thing).  At least Lisp doesn't actively fight against being compiled (like JS, hence ASM.js & WebAssembly (sacrifice JS features to the compiler gods!))).  Additionally, having the goal of linking with the compiler (and potentially an interpretor) in programs helps keep the language lean and fast (design naturally tends towards less bloat then).

While there are many Lisp implementations readily available to extend, they're typically written in C.  And if we're going to do that, might as well just port a C compiler to the VM and be done (then you could compile your favorite Lisp on the C compiler for the VM and then code in Lisp on the VM).  An explicit VM meant to run only Lisp might be a worthwhile project, but the last time I tried designing a real CPU like that in VHDL (which you could fab or output to a FPGA), the chip grew so large that I couldn't afford a FPGA with enough gates on it to actually run it (maybe because I tried to implement a Lisp with lots of features rather than a minimal Lisp).

Of course a RL lang could ditch the VM underpinnings and just extend an extensible language like Haskel or Lisp, but I'm wondering more along the lines of what a from scratch RLLang syntax would be.

Of note, I think the @ needs to play a prominent role in a RLLang's syntax.  Perhaps it could be the "loop" symbol?

say "hello world" @( 1 ); // infinite loop while true of hello world.
[1 2 3 4 5] @ say( "count " #); // map over an array; outputs hello 1 hello 2 ... hello 5, # being a symbol for the value.

That or @ could be a valid identifier character, so that your player var could just be: @

In one of my VM's Assemblers @ is used to denote indirection (like dereferencing a pointer).  Here's a manual implementation of a switch / case block (jump table).

Code: [Select]
// Switch: /r0
up 2 /r0
add main_jt0 /r0
set main_jt0_max /r1
// jump to default case if value (reg 0) is beyond the jump table (reg 1)
jae /r0 /r1 main_jt0_default
set @/r0 /r0 // sets the value at reg 0 into reg 0.
jump /r0

// Jump table #0
#inline main_jt0_0 main_jt0_1 main_jt0_2 //... snip

// JT0: Case 0: syscall EXIT( status )
// Set the exit status to user specified value, then die.
pop /r1
set /r1 @sys_exitStatus
pop /r0

Having ability to model the basic constructs like state machines is very good idea.
I tend to agree.  Support for state machines at the language level eliminates the headache of huge switch statements within functions, or forgetting to call state transition functions when change.

Another option I would like to have is relational or logic programming. Instead of describing an algorithm, I would describe problem domain and relations of things within it and let the computer to solve the problem.

That's pretty nifty.

I've done something like this before (at work) using neural networks to map and emerge a solution for abstract problem spaces, but I'm having a hard time thinking of how one would implement such things at the language level (rather than programming them).

An AI with weighted decision trees could do the trick.  Give the player the ability to access a sufficiently advanced AI agent -- in other words, let the player call upon the AI code that NPCs / enemies use to defuse traps, etc.  However, this might be best left up to the programmer rather than the language, since some programmers may prefer that traps be explicitly disarmed rather than have a "move cautiously" trap solver.  Perhaps I've also simply misunderstood your intent.

I find this topic fun. Perhaps if you ever end up building a custom chip for your new roguelike language, you could include the option to turn permadeath on, which would instantly fry the chip when you lose. Then you have to go solder another one in!

Coincidentally one of my virtual CPUs can enter an evil state of permanent death.  This VM assembly code documents the feature, it's status #13:

Code: [Select]
// Constantly recognized evils.  Encountered when misfortune has befallen.
#const E_BREAK 0 // Debugger demands a break from execution.
#const E_PERM 1 // Permission level not high enough.
#const E_INVALID 2 // Operator is lame or otherwise severely unwell.
#const E_EXEOFLOW 3 // Execution has overflown the stack.
#const E_EXEUFLOW 4 // Execution attempted below the stack.
#const E_NOMEM 5 // RAM's inventory is full.
#const E_ACCESS 6 // Thwarted an improper access attempt.
#const E_ALIGN 7 // Incompatible alignment for RAM.
#const E_UNKNOWN 8 // All attempts to identify this mysterious evil failed.
#const E_ENV 9 // Evil lurks in the environment beyond the skull's safety.
#const E_HALTED 10 // Can't run, but not dead yet; Just waiting for a spell.
#const E_PAROFLOW 11 // Parameters have overflown their stack.
#const E_PORTAL 12 // Engram unable to traverse the skull's portal.
#const E_DEATH 13 // Brain has permanently died, and can not be resurrected.
#const E_NOSUPPORT 14 // Feature known but abandoned (hopefully temporarily).

While I can force a hard reboot of the "hardware", I haven't discovered a way to fry a chip in VERILOG / VHDL (hardware definition language).  I guess i could include some NVRAM on chip, then set that to "permadeath", and check the non volatile storage to see if that's been set before executing any instructions...  I do accidentally fry a motherboard sometimes working with custom PCI boards and/or badly wired custom peripheral devices.  For this reason it's recommended that in-development devices be attached only to a separate controller board not on a port integrated with the mainboard since it's far cheaper to replace a fried expansion card.  So, it would be trivial to make an off-chip facility for the feature, however impractical that may be.  One could supply an optional serial or parallel device which responds to permadeath messages by suicidally dumping a bank of capacitors onto the system's IO bus, frying your computer when your game is over.

After sleeping a bit, I think I have another perspective to this. Maybe we should look from point of view of primitive, means of combination and means of abstraction too? They're the basic parts of pretty much every programming language and the essence that really tells them apart.

Primitives: the usual suspects like numbers, text, lists and such are obvious. But since we're talking specificially roguelike language, should there be higher concepts here too? Like character/creature, item, coordinates, action, ai-routine and such? If they're very detailed, building different kinds of roguelikes might be tricky, but if they're too vague they're maybe not so useful? Code is one primitive too I would say. Things like lazy and infinite datastructures and asynchronous operations would be nice to have built into language.
Yeah, that's the stuff!  One way to implement a "code primitive" would be to make them special literals of the type "script" which can be executed by a run-time interpreter.  The difference between a String and a Script would be that a Script has been lexicographically analyzed, tokenized, and potentially parsed into a syntax tree (or bytecode) and is ready for interpretation.  Scripts that are dynamically linked could be fetched and processed at initialization time.  The RL lang would need a standard function (or constructor) that created a Script entity from a plain string.  This would allow compiling and running of arbitrary text strings at runtime.  One could then implement an optional "console" feature simply by executing user input (like an eval() function).  However, due to the nature of roguelikes (and games in general) it would be useful to have a way of specifying the scope available to a piece of runtime code, as well as which API functions can be accessed.

I've often wished I had the ability to write small scripts to search inventory or perform complex repetitive actions...  My terminal emulator has sufficed for most games, but an in-game console would potentially enable far greater control and script-ability.  With the right data in scope players could even code up an AI / bot to play for them via such "user script" features.

The question of some primitives would be, what characteristics / properties should roguelike primitives have.  E.g., a "generic RL item" has: brief text, detail description, possibly text for when its not identified, a symbol (or tile#) to display when it's visible on the map, etc. If it can be equipped, to what slot, what "action" uses the item, etc.

Of course a base "RL Item" could be part of the RL lang's standard library.  Coders would be free to implement their own Item, but we could provide a basic item and inventory implementation to extend if they so desired. The trick of good language design is not to provide everything everyone could ever need, but to provide some useful things to some people, and allow those with specialized needs to roll their own.

Incubator / Re: Intro to the Incubator
« on: April 08, 2016, 12:04:06 AM »
Many separate indie devs have come to the same solution and attempted building a platform for game distribution, even before Steam and GOG were a thing, with various degrees of success.  The realities of creating and maintaining such a platform typically diverge quite a bit from those of gamdev, and aren't particularly "fun" to manage...

I've been studying game distribution platforms & bundles for quite a while and have a few opinions on the matter to share.  In my experience, the value of Bundles, Steam and other distribution platforms is primarily not in its unification of game distribution and/or uniform platform compatibility.  Rather, their primary usefulness is in aggregation of games and content for the purpose of advertisement and discovery.  The same holds true for Kickstarter and other crowd source platforms: Their monetary incentive is secondary to the benefit of promoting your game to the eyeballs the bundle/funding-platform/online store has already attracted.  See also: Ye 'ol disc on a retail shelf bearing a title such as, "200 shareware games only $4.99"

Community / achievements / etc. features of distribution platforms are all tangential to game discovery.  Note that you can easily talk about games and even gift games on Steam -- This promotes discovery.  There's a competitive and social angle to scoring which can reinforce a community, this also reinforces other methods of discovery such as word of mouth and "Let's Play" advertising.  The Humble Indie Bundle incorporates charity donations and leverages positive social signaling -- people like to point out how much they've helped some charity (meanwhile advertising your game).  Like most devs, I find marketing to be quite a soul sucking affair, but that's the nature of the beast.

At this time I'm unprepared to participate in an incubator bundle.   However, I can propose an alternative that anyone can participate in even if the developer can't comply with "open platform" restrictions:

If you are making a roguelike (or any game) then you should make a Press Kit.  A typical press kit consists of game logos, gameplay screenshots, your catch phrase, an "elevator pitch" (short description of the game), a primary bullet list of features / mechanics (what makes your game worth playing), what platforms are supported, a link to get the game at, and etc. information that would be useful for creation of an article about your game by a game journalist (assuming they exist in this reality).  The purpose of the press kit is to make it easy for others promote your roguelike.

Next, post a link to your presskit in a thread dedicated to the promotion of roguelike devs here.  Maybe even try sending the kits to game "journalists" and "Let's Players" (along with a copy of the game).  Don't ignore the lesser known outlets since they're usually hungry for unique or niche content... but I digress.

Before releasing your roguelike use your discretion to select a few roguelikes from among the other devs' games you appreciate, and promote them in-game by using content from their press kits on a "you might also like" screen, menu item, etc.  Think of it like having a separate "credits" screen that promotes other roguelikes you like.  The promoted games should optimally be in a playable state and of a sufficient quality or at least in the same vein of the game you're releasing.  Try to include links to the other games if possible.

In this way roguelike devs can help promote each other as a dev community while aiding players in discovery of more roguelike games.

I think that an Incubator Bundle could utilize a similar method of cross-game discovery in lieu of or in addition to bundling.  You can opt to employ Incubator bundle-branding and quality standards.  Meanwhile, those not bundling could promote the Incubator bundle as well as other roguelike devs not in the bundle.  My point is to make it easy to do so.

It's a rare thing to help your competitors compete with you, but it seemed to work for us sharware game devs back in the BBS days, and I think the strategy might still be useful today.  This wheel has been reinvented many times.  Remember Webrings?  See also: Amazon's, "people who bought this also bought these", Pandora's music genome project, Netflix, and etc. recommendation engines.

TL;DR: Make & post your press kits, get recommended by other helpful roguelike devs / players, with or without being officially incubated.  "A rising tide lifts all boats."

Programming / Re: Heterogeneous saving and loading objects in C++
« on: April 06, 2016, 06:54:52 PM »
A word on the type property definition: For the purpose of object serialization one only needs to record the number of object pointers within the type data record, and the offset of each pointer within the type record.

etc.. You wrote lot of text not related to this problem. Why? What you are using is "ridiculous C tricks with C++ hater attitude". Didn't you see the 'C++' in the title of this thread?
It's foolish to interpret criticism as hate.

I did see the C++ and, as it turns out, C++ added facilities expressly to pull off "C tricks" because they're so damn useful, such as allowing you to overload the new operator rather than dick around with macros that wrap the malloc() calls.  The designers of C++ realized that you may also need to do things the C way sometimes in order to route around a language edge case (or add new features to C++ itself), and so they provide full compatibility with C.

I don't hate C++, I just recognize that it could be much better than it currently is.  A decade ago I helped petition to have hashmaps added to the STL, it was denied...  Now we finally have hashmaps in the new C++ STL (after having rolled our own for a decade).  Our constant criticism of C++ for not standardizing on a hashmap implementation and instead necessitating many separate fractured libraries eventually improved C++.  Perhaps some day we'll have other improvements such as "virtual variables", which I mentioned because there is a common pitfall when implementing object hierarchies that need per-instance state (called the diamond inheritance problem) which, in the absence of virtual variables, can be avoided by moving that global state into your fully C++ sanctioned custom Allocator bookeeping data.  I then explained the lower level implementation details (call it C if you like).

I fail to see where most of what I said is unrelated.  What you think is not related to the issue is actually related in my experience.  For example, if you want to create a generic parent (template) class which has the ability to recursively store itself and any pointers to other objects its subclasses (or template instantiations) may contain, you will need some type introspection, AKA a "property definition".  C++ traditionally has had very poor support for type introspection, and so we perform "tricks" via macros and template functions to make up for the deficiency.  Once C++ had no run time type ID at all, and now most compilers support this, largely thanks to criticism.  Because no version was mentioned of the particular C++ in use, I mentioned these methods and including a method universal to any C++ compiler whereby you resort to adding your own run time type information.  Note: manually calling save( this.propertyptr ) on each property in a .save() method is functionally equivalent to providing your own type information, you'll just be doing so explicitly in source code rather than implicitly via the language's metadata (if it provides such).

It's a rather involved topic.  It would be beneficial if C++ had serialization standardized in its STL, but it does not have that yet, and so we've delved into the deep implementation details of such a low level language feature as introspection (that most other high level languages have standardized support for today).  As it turns out that brushes into memory allocation.  In fact, the method for saving and loading this data that I posted previously is essentially the same as a generational garbage collector algorithm, and once implemented can be used as such.  The naive approach would be: When memory gets fragmented, save the game state, then load it, and you've just performed a generational GC pass (or a mark/sweep pass, depending on how you look at it).

And, that's why the heterogeneous (de)serialization of  object hierarchies touches on a wide range of topics.   Feel free to ignore any information provided.  Consider that I didn't write it just for you...

Also of note: C++ frequently takes implementations and/or hints on where to go from the popular Boost C++ library.
Boost was one alternative to rolling your own hashmap back in the day, and as it turns out the Boost library also has generic serialization support.  In other words, while waiting for C++ to get around to adopting new standard features, they rolled their own so you don't have to.

  •     Code portability - depend only on ANSI C++ facilities.
  •     Code economy - exploit features of C++ such as RTTI, templates, and multiple inheritance, etc. where appropriate to make code shorter and simpler to use.
  •     Independent versioning for each class definition. That is, when a class definition changed, older files can still be imported to the new version of the class.
  •     Deep pointer save and restore. That is, save and restore of pointers saves and restores the data pointed to.
  •     Proper restoration of pointers to shared data.
  •     Serialization of STL containers and other commonly used templates.
  •     Data Portability - Streams of bytes created on one platform should be readable on any other.
  •     Orthogonal specification of class serialization and archive format. That is, any file format should be able to store serialization of any arbitrary set of C++ data structures without having to alter the serialization of any class.
  •     Non-intrusive. Permit serialization to be applied to unaltered classes. That is, don't require that classes to be serialized be derived from a specific base class or implement specified member functions. This is necessary to easily permit serialization to be applied to classes from class libraries that we cannot or don't want to have to alter.
  •     The archive interface must be simple enough to easily permit creation of a new type of archive.
  •     The archive interface must be rich enough to permit the creation of an archive that presents serialized data as XML in a useful manner.

I bolded the part in which Boost's implementation overlaps specifically with the example you gave, indicating that both myself and Boost believe this is relevant to object serialization.  Indeed this list of goals from their library covers many (if not all) of the implementation details I touch on, such as proper resolution of nested data structures ("Proper restoration of pointers to shared data" and "Deep pointer save and restore"), or "don't require that classes to be serialized be derived from a specific base class or implement specified member functions" (which is what my "C tricks" using C++ Allocator overloading and macros or complex templating shenanigans allows).

There is now a detailed description of the full implementation details of such a system in this thread, and links to two separate implementations, one of which may be adopted by C++ some day, if only we criticize the standards makers for not having it long enough.

Pages: [1] 2