What would you want in future HTML Dating Sims?

[Squeeky]

If you are not sure about your content then try Google, http://images.google.com/imghp?hl=en.
Click and drag your image to the Search Window (to the left of the camera. Google will seek out any sources.
This one for instance shows up with a URL http://www.wehearit.com.

Clip.jpg

And this one shows as belonging to a South Korean artist.

Clip_2.jpg

[TeineWolf]

I am just wonder why people are still coding just within HTML. Has there been a consideration to move from HTML, to a PHP/HTML game engine. The potential down side, is the games would not be downloadable, and would require a HTTP Server with a PHP Server running as well, probably an SQL server. Which is no more, nor less, than what is required to run this forum.

The upside is you are not stuck in a linear environment. Variables would be tracked the PHP/SQL, and would remove all those checking that HTML forces you to do with, with flat (text) files. with nested IF/THEN/ELSE construct. Thoughts?

[Super]

I am just wonder why people are still coding just within HTML. Has there been a consideration to move from HTML, to a PHP/HTML game engine. The potential down side, is the games would not be downloadable, and would require a HTTP Server with a PHP Server running as well, probably an SQL server. Which is no more, nor less, than what is required to run this forum.

The upside is you are not stuck in a linear environment. Variables would be tracked the PHP/SQL, and would remove all those checking that HTML forces you to do with, with flat (text) files. with nested IF/THEN/ELSE construct. Thoughts?

Personally, it's just that I'm not a programmer and just know enough to toy with the variables in game.js. Adventure Creator is easy enough to make the game layout. If Tlaero or someone made a better thing for a similar type of game, then I might switch to that.

[tlaero]

I find value in letting the game be downloaded and played offline.

Tlaero

[me3]

I am just wonder why people are still coding just within HTML. Has there been a consideration to move from HTML, to a PHP/HTML game engine. The potential down side, is the games would not be downloadable, and would require a HTTP Server with a PHP Server running as well, probably an SQL server. Which is no more, nor less, than what is required to run this forum.

The upside is you are not stuck in a linear environment. Variables would be tracked the PHP/SQL, and would remove all those checking that HTML forces you to do with, with flat (text) files. with nested IF/THEN/ELSE construct. Thoughts?

"Potential downside"? it would be a pretty certain downside.
You also don't take into consideration that many/most of the people that release the games don't actually have a site and they are releasing them through others, and their only hosting is either free webstorage sites and/or the forum they are posting on. Which means they would need to pay for a service, which instantly add an expense, which they didn't have before. The more popular the games are, or at least the more heavy they are, the more bandwidth you'll need too, which again means you need to pay more. Which in turn makes it more likely to require charging for the games.

Then there's simple things like ppl wanting to play offline, due to things like lagging servers, bad inet access etc.

As for php/sql, for most/all of the games that's using what you call "just html" you wouldn't need sql, it would more than likely overcomplicate things, and with the very small number of variables and short time span on storage, you'd be better off with sessions, which doesn't have to be stored in sql.
Your claim about "would remove all those checking that HTML forces you to do"; is wrong. You'd still have to do the same checks as your game would still need to comply with the games conditions, you're simply moving the checks from being javascript to checks in PHP, which would be the exact same if and else setup that javascript has.
Nor would it make things any more or less linear either for that matter. The same conditional setup could be applied to the game regardless of it using javascript or php.

With how simple (by that i'm referring the working nature and in no way belittling the games) the games are, a move to something like php and sql would be a very bad one and it would add nothing positive for the players and add negatives to the developers.
The games functions and needs can easily be covered by simple html files for displaying and javascript for the condition handling (put somewhat simplified).
The javascript code can even be expanded upon so that less html files is needed, but that would increase either the knowledge of the developer or the complexity of tlaeros program, but there are games out there that are more javascript driven and it works just fine, the games wouldn't gain anything by a move to php/sql.

[TeineWolf]

Your claim about "would remove all those checking that HTML forces you to do"; is wrong. You'd still have to do the same checks as your game would still need to comply with the games conditions, you're simply moving the checks from being javascript to checks in PHP, which would be the exact same if and else setup that javascript has.
Nor would it make things any more or less linear either for that matter. The same conditional setup could be applied to the game regardless of it using javascript or php.

With how simple (by that i'm referring the working nature and in no way belittling the games) the games are, a move to something like php and sql would be a very bad one and it would add nothing positive for the players and add negatives to the developers.
The games functions and needs can easily be covered by simple html files for displaying and javascript for the condition handling (put somewhat simplified).
The javascript code can even be expanded upon so that less html files is needed, but that would increase either the knowledge of the developer or the complexity of tlaeros program, but there are games out there that are more javascript driven and it works just fine, the games wouldn't gain anything by a move to php/sql.

When I started digging into the HTML games, the first one I ran across what "Getting to know Christine". After that I tried some of the others like "Jessica". When I looked for a walk-through, what I found was a list of complaints about the game. So I downloaded the game, looked at the image files, as thought there has to be more to this game, than what people are seeing.

My personal experience and training, is to debug, from the bottom to the top. Once I figured out of the structure of the gaming engine, I was able to figure out how to play the game successfully, and find most of all the endings and content. That became my motivation. To see an artist take the time, to make so much content, and have no one know it's there. That's not enough for me, so I figured out why no one was seeing it. It's also how I stumbled across that awesome secret ending for "Christine".

The answer was how the variables were being checked. Checking multiple variables on the command line level, was conflicting and overtly complicated. For example, in Jessica it was the mall checking routines that were the stumbling block. If the variables for both mood and tasks, didn't meet any of the multiple checks, the game stalled on that screen. I see people trying to make more complex games like "Brad's Erotic Week. Sure you can add in a restart-restore button to get around that. But bottom line, "IT"S A GET AROUND". Because of the limitations of Javascript.

There's a few PHP game creator programs out there, that don't require a knowledge of coding. I just see the logic of using one SQL query to check something, rather than multiple, and potentially conflicting, javascript checks. If you can understand Javacript, the transition to SQL would be easy. I understand the reluctance. But you guys are the one's doing the creating. So I'll be quiet now.

[tlaero]

Well, Jessica is extremely old. The code in these games has come a long way since then. Christine too is pretty old. I've updated AC a number of times since its release.

It annoys me that JavaScript isn't a strongly typed language, but you really can do just about anything you'd like with it.

Tlaero

[coder]

The upside is you are not stuck in a linear environment. Variables would be tracked the PHP/SQL, and would remove all those checking that HTML forces you to do with, with flat (text) files. with nested IF/THEN/ELSE construct. Thoughts?

The problem with non-linear stories lies in a different area and has nothing to do with the language you use. It can just as easily be done in javascript. They're mainly just more complicated to write.

Non-linearity is mainly a suggestion anyway. You need to program all the possible paths in some way. So how many different possible paths would it take for a story to be considered non linear?

[TeineWolf]

It can just as easily be done in javascript. They're mainly just more complicated to write.

That's the paradox I see with javacript. It reminds me of programming in BASIC many, many, many, moons ago. Program flow is severely limited, and the more decision making, bloats the code. Then when the move to Pascal came out, program flow became a lot easier, because the decision making was more flexible. I haven't programmed in years, but the basics of what I learned stay true.

SQL/PHP would allow you the ability to have better flow of the game. Rather than creating multiple independent javascript checking routines, all could be done with a single SQL query. I haven't had the chance to look at them yet, because I am unsure of the desire to move into the environment. To actually see what makes a PHP/SQL game developing engine work, and how hard it might be for people to use it.

[coder]

You misunderstood me. It's not more complicated to write it in javascript. It's more complicated to write a non-linear story in general. Because it needs to be logical for the player. One just easily makes a continuity error.

It all depends on how you write your code. Javascript is quite a powerful language. The basic syntax doesn't differ much from C. And because it's object orientated the program flow is actually less limited than classic Pascal.

[hrmf]

Javascript certainly has its weird little problem areas, but honestly moving to PHP on the server is not going to get you anything (certainly not in terms of language elegance, if that's what you're worried about). Hosting stuff online means somebody is paying for bandwidth; I personally prefer just to download games anyhow since there's no risk of my internet going out, a hiccup on the hosting server, etc. As far as the coding goes, there's nothing you can do in the one language that you couldn't do in the other.

Parenthetically, I don't want to come off as critical, but as somebody who does a decent amount of javascript programming in my day job, it has occurred to me on several occasions that the javascript seen in most of the HTML virtual dating games is not exactly current with modern practice - stuff like the varPlus10("variable") type functions, for instance, aren't necessarily how someone with more experience would code those sorts of things. And that's fine - the code generally works OK for what it does, and it's also probably a lot easier to understand for someone who doesn't necessarily have a hardcore programming background but wants to make a game anyways, which is important because it's easier for more people to make games.

I have been toying around with the idea of bringing in some more recent libraries (jQuery, backbone, angular, whatnot) and then recoding some games as "single page apps" (running on a single URL) rather than apps which are split up into a million different HTML files - doing it that way would probably ease some of the cookie problems from files running on localhost, for one thing, and could incidentally shrink the size of non-image assets somewhat. The nice thing about games that run in a single browser page is that they can retain state since all the javascript variables aren't wiped out between page views (here's a nice example, but watch out, it'll suck you in). Unfortunately I'm full of ideas like this but I rarely have time to execute them.

[tlaero]

The original point of Adventure Creator was to make the programming easy so that non-programmers could make games. The original user tried to wrap his head around a single page app and heavily preferred individual HTML files, so I tailored it to him. Although I also use the tool, and would do things differently if it were just for me, I'm happy with the balance I've reached between functionality and approachability by non-programmers.

Tlaero

[TeineWolf]

I am trying to keep myself talking conceptually, and not technically. Like the comment about Javascript being like C, where Pascal isn't like C in a lot regards. I have to resist the urge to go into technical details, and explain the differences. As to the assertion of JavaScript being like C. I've served as being the token liaison between tech support, IT and development. So I kinda had to explain the same things, to different people, in different terms. So sometime, things can get lost in translation, but in the end we got results.

Here's about the best way I think I can explain it. Short of going out and buying/developing a 3D gaming engine, like the Unity Web Browser. Currently the option for developing games then is to use a scripting language. Whether it be Java/PHP/Flash. Each scripting medium has it advantages and disadvantage. Java is simplistic. You don't even need an Apache (HTML) server to create games. Flash similarly doesn't need an Apache server, to be standalone. However it does require an extra program/service, which is ShockWave. Normally a plugin that updated in browsers. So like Java not a biggie. Both are still script based, yet they still can end up with more steps when handling variables.

Here's the downfall of PHP, as we'll all know. It's requires the Apache (HTML) server, a PHP server to handle script calls and a SQL server to access a database. To me, if you can find something similar to Adventure Creator, like PHP-Wine. It might be worth exploring if the gaming community here, is shifting towards games involving time management. Like inventory, multiple days, or money management. With the potential to add in mini-games that are more robust, and flexible.

Just trying to present some food for thought.

[hrmf]

The original point of Adventure Creator was to make the programming easy so that non-programmers could make games. The original user tried to wrap his head around a single page app and heavily preferred individual HTML files, so I tailored it to him. Although I also use the tool, and would do things differently if it were just for me, I'm happy with the balance I've reached between functionality and approachability by non-programmers.

I get that, and I hope I didn't come off as critical because I think you're doing great work for the community at large by creating and maintaining Adventure Creator. I haven't used it myself (being on a Mac most of the time) but it seems like you have struck a good balance, based on the games that have been made with your tool. But I still think that a single-page app would a better architecture in some ways (notably with not needing to be so fussy about cookies, dealing with file:// urls, maintaining state, etc), and if game creators are using a tool anyways, there's nothing in theory that would prevent the tool from spitting out code for a single-page app.

TeineWolf, I think I see what you're getting at, but I still think the main difficulty with moving to an architecture based on PHP is that it needs to be hosted somewhere, and that comes with a whole lot of headaches that downloadable browser (or Flash) games just don't have. As far as SQL is concerned, it's really overkill for applications which generally need to store somewhere on the order of twenty integers (at most) in order to track the entire game state. If you were going to host a game on a server, you might use something like mongodb or another key-value store instead, but these days modern browsers have one built-in anyways: LocalStorage.

As for as the language itself goes, each one has advantages and drawbacks, but I'd point you to towards PHP: a fractal of bad design if you're interested in a dissenting view of PHP as a programming language. There's really nothing you can't do in javascript these days, though some applications are better-suited to it than others. Web games are an area for which javascript is definitely well-suited.

[tlaero]

I did spend some time investigating single page with a data file holding arrays of strings, but it's more complex than you'd think. You need the following arrays:
Toptext
Preload
HeadOverride
Sound
Animation
Hit targets
Image
Says
BodyOverride

At the point where you're doing that much stuff, you might as well just do individual pages.

Although the underlying implementation of state through cookies is pretty clumsy, the game creators never see it. I DO wish I had been consistent with capitalization, though. The mix bugs me, but not enough to break back compat. I started with a "when in Rome" approach, but I really should have cleaned it up first. Oh well.

Tlaero