Jolt Country

I always complete my projects, so all of your wishes will be accomodated.

Look? Can it support looking?

Request: GRANTED.

https://github.com/joltcountry/ifluant

If anyone wants to get in on the ground floor, you can clone that repo (or just download the files), follow the instructions in the readme and see if you can run the game.

Don't forget to search for the SECRET ROOM!!!!

What about getting things.

I like to get items.

So maybe getting?

Next on the list!

Will it support web-based games?

We're only taking requests here. Therefore, it will not be web-based, because that was not in the form of a question and we're going on ANTI-JEOPARDY! rules here.

Alright, this morning's major update: GETTING! DROPPING! EXAMINING! OH SHIT

Wait, I am going to be able to get AND drop things? I like dropping things!

Don't want it? Just DROP that shit.

I have a suspicion you are trying to learn Lua and want to learn more. I can understand that you want to learn the language, and that's commendable. But are you sure that trying to cut your teeth on a project this big is a good idea? I mean, you yourself complained about your inability to complete projects.

Question:
Have you treated this as one would a professional programmer would do so?
Followups: Do you:
(1) Commit on every change that works?
(2) Commit early, commit often, like multiple times a day?
(3) Push commits by the end of each day?
(4) Using the 'access token' feature of GitHub?
(5) Developed a standard style in writing programs?
(6) Using a good naming system for procedural types (procedures, functions, modules and properties) and data types (constants, variables, properties)?
(7) Admit you don't know everything, and realize when you have a problem, that, after your text editor, Google is your next best friend?
(8) Avoid reinventing the wheel, and see if, before writing code, find out if someone else has solved that particular issue or functionality?
(9) Read source code of adventure games written in other general-purpose programming languages?

Now I'll explain my reasoning.
Frequent commits are the only way I know of to prevent a screw-up from ruining something, and you have no idea what you broke. The solution to that problem is to commit often. A good practice is to do commits several times a day, like each time you put in a feature, and it does work, to commit before going back to your editor. I also recommend doing pushes to GitHub at least once every day. Let me tell you, you'll never regret having this sort of discipline the next time you realize you went down the wrong rabbit hole and need to backtrack back, but a history of know-good commits makes rolling back mistakes trivial. And don't kid yourself, you will make mistakes. Lots of them, some seemingly brain-dead moronic. That's how you learn. I don't regret all the time I "wasted: doing commits. What I regretted was not committing frequently enough. I don't make that mistake anymore.

Also, I recommend using the access token feature because it is mandatory to do pushes, or at least, if you're not using their app for uploads.

A standard pattern for designing programs is to make things more descriptive, and have procedures/functions do one thing. It makes debugging easier. Also, picking some naming system that creates mnemonic procedural and data types, will make it easy to understand what your program dose, what it is doing it to, and what is happening.

Do lots of research. Are there Public Collections (Public Libraries have an entirely different connotation) where people have uploaded Lua widgets (for lack of a better term) like classes and such which perform a functionality you need? Something like CPAN for Perl, or PEAR for PHP?

Writing a complete parser and command processor is a lot of work. This is in addition to writing the game itself. People who use adventure game systems have no idea how much sheer unfun drudgery there is in a parser; the system has done all the heavy lifting for them. Before we had domain-specific languages to do the work on this, all we had were general-purpose languages to do this. Other people have solved this problem, you might want to see what they did. It may give you ideas.

I've talked enough. Good luck to you.

What about verbosity? Will there be a brief/verbose toggle that cuts out useless text? I like brevity

There could have been, but that was in the form of question, so no.

ANTI-JEOPARDY! rules, people. You're destroying this project!

Tdarcos wrote: Sat Dec 04, 2021 3:53 am I have a suspicion you are trying to learn Lua and want to learn more. I can understand that you want to learn the language, and that's commendable. But are you sure that trying to cut your teeth on a project this big is a good idea? I mean, you yourself complained about your inability to complete projects.

Question:
Have you treated this as one would a professional programmer would do so?
Followups: Do you:
(1) Commit on every change that works?
(2) Commit early, commit often, like multiple times a day?
(3) Push commits by the end of each day?
(4) Using the 'access token' feature of GitHub?
(5) Developed a standard style in writing programs?
(6) Using a good naming system for procedural types (procedures, functions, modules and properties) and data types (constants, variables, properties)?
(7) Admit you don't know everything, and realize when you have a problem, that, after your text editor, Google is your next best friend?
(8) Avoid reinventing the wheel, and see if, before writing code, find out if someone else has solved that particular issue or functionality?
(9) Read source code of adventure games written in other general-purpose programming languages?

Now I'll explain my reasoning.
Frequent commits are the only way I know of to prevent a screw-up from ruining something, and you have no idea what you broke. The solution to that problem is to commit often. A good practice is to do commits several times a day, like each time you put in a feature, and it does work, to commit before going back to your editor. I also recommend doing pushes to GitHub at least once every day. Let me tell you, you'll never regret having this sort of discipline the next time you realize you went down the wrong rabbit hole and need to backtrack back, but a history of know-good commits makes rolling back mistakes trivial. And don't kid yourself, you will make mistakes. Lots of them, some seemingly brain-dead moronic. That's how you learn. I don't regret all the time I "wasted: doing commits. What I regretted was not committing frequently enough. I don't make that mistake anymore.

Also, I recommend using the access token feature because it is mandatory to do pushes, or at least, if you're not using their app for uploads.

A standard pattern for designing programs is to make things more descriptive, and have procedures/functions do one thing. It makes debugging easier. Also, picking some naming system that creates mnemonic procedural and data types, will make it easy to understand what your program dose, what it is doing it to, and what is happening.

Do lots of research. Are there Public Collections (Public Libraries have an entirely different connotation) where people have uploaded Lua widgets (for lack of a better term) like classes and such which perform a functionality you need? Something like CPAN for Perl, or PEAR for PHP?

Writing a complete parser and command processor is a lot of work. This is in addition to writing the game itself. People who use adventure game systems have no idea how much sheer unfun drudgery there is in a parser; the system has done all the heavy lifting for them. Before we had domain-specific languages to do the work on this, all we had were general-purpose languages to do this. Other people have solved this problem, you might want to see what they did. It may give you ideas.

Umm...

I've talked enough.

Hey, I found a part I agree with!

Paul, that was a horrible post, and it's important that you feel bad about it. Do you? If not, promise me you'll feel bad about it.

You know what, that post was so bad, I'm okay splitting this thread, or even better yet, shutting it down and starting a new one.

Paul, don't post on the new thread. Ever.

Every line in that post was so horrible I don't know which one to pick as my favorite, as we leave this thread in shattered ruins, but I think it's this:

(7) Admit you don't know everything, and realize when you have a problem, that, after your text editor, Google is your next best friend?

In this thread, Paul tells someone who has programmed computers for a living since he was 17 (over thirty years) that if they're not sure how to do something, a good idea would be to look it up on the internet.

I think you should embrace the power of NATURAL LANGUAGE PROCESSING. Isn't it time parsers went beyond mere text matching? Isn't it time for parsers to attain true semantic understanding? Of course it is! The reason I'm posting this in the Paul thread is because I think you and Paul should actually tackle this problem together. That way you guys can whip it off in an hour or so and then you can move on to implement xyzzy and other magic words which is my other request. As long as you guys remember to commit often and Google shit, this is all totally achievable. I look forward to seeing the results!

Have you checked to see if anyone has solved that problem before?

Paul - are you sure Github supports access tokens?

Ice Cream Jonsey wrote: Sat Dec 04, 2021 12:58 pm Paul - are you sure Github supports access tokens?

Yes, because they issue them, and in some cases for PUSH to Github repository, you'll be required to use them as ordinary password logins for Git PUSH was no longer accepted starting in August. I have both gotten tokens and used them.

Great. Do you understand why they are terrible?