MakeWebGames engine?

[Dave]

2 minutes ago, Alan said:

I'll just go with...

Blockchain... pfft, I was writing blockchain code a *long* time ago - good for preventing rogue database admins from changing datasets. Nothing to do with currency.

Prizes.. yeah gods. Last time I won a prize here - I got a full copy of Alain's NWE engine - the worlds most friggin' convoluted and standards escaping product known to mankind. Still sitting in my "must-get-around-to-it" folder.

Yeah I don't want to repeat the issues that many of the engines created on these boards before hand. Clever people making bad decisions in the name of owning their creations entirely. 

[Script47]

Ya know, if I'm quite honest, I've always been of the opinion that an engine or anything for that matter that isn't massively complicated and is well written, is fine being procedural. I'm not a die hard advocate for OOP in all cases. If your aim is to make some that is easy enough for newbs to use then keep it as such.

Edited March 15, 2019 by Script47

[Dave]

Just now, Script47 said:

Ya know, if I'm quite honest, I've always been of the opinion that an engine or anything for that matter that isn't massively complicated and is written well is fine being procedural. I'm not a die hard advocate for OOP in all cases. If your aim is to make some that is easy enough for newbs to use then keep it as such.

One issue with procedural code is duplication of code and poor structure of the modules where in. For instance most the engines we have today combine the business logic and presentation layers which is just gnarly.

I think basic MVC (or similar) it's fairly integral to ensure this engine is modern and teaches good practices.

Procedural has it's place and it's not for these things personally.

[Alan]

@Script47, my friend, have hit the nail firmly on the head. An engine - certainly for a text-based game - should be lightweight and efficient. Bonus points for making it easy to understand and extend. Procedural, well.. that's a little old hat but still viable today though I suspect most of the grown ups are using oops (Sorry, that sounded condescending, not meant in any way). If you consider the market place (these hallowed forums), then in 3,4 or 5 years, the people that hopefully pick up this "engine" will be the next generation of programmers, so getting them on the right footing to start with is the key. 

 

@Dave MVC? PHP's never been overly good with that concept though I'm willing to be be disproved. Model, Template, Controller perhaps is sufficient. The view paradigm in PHP always seems so arse about face. $twig->render($template, $context) .. more than sufficient.

[Script47]

10 minutes ago, Dave said:

One issue with procedural code is duplication of code and poor structure of the modules where in. For instance most the engines we have today combine the business logic and presentation layers which is just gnarly.

I think basic MVC (or similar) it's fairly integral to ensure this engine is modern and teaches good practices.

Procedural has it's place and it's not for these things personally.

Aye, no doubt.

Just to clarify, when I say procedural, I don't mean completely lacking classes, sure, you'd have your helper classes but the bulk of the system would be procedural.

I guess it boils down to preference and what you are making.

Edited March 15, 2019 by Script47

[Dave]

50 minutes ago, Alan said:

@Dave MVC? PHP's never been overly good with that concept though I'm willing to be be disproved. Model, Template, Controller perhaps is sufficient. The view paradigm in PHP always seems so arse about face. $twig->render($template, $context) .. more than sufficient.

Yeah, that's why I said or something else, just some separation of concerns however that looks.

51 minutes ago, Script47 said:

Aye, no doubt.

Just to clarify, when I say procedural, I don't mean completely lacking classes, sure, you'd have your helper classes but the bulk of the system would be procedural.

I guess it boils down to preference and what you are making.

Sounds like McCodes already, you'd struggle to achieve that in an existing framework as they do impose some structure.

[Djkanna]

3 hours ago, Alan said:

Heck even Perl is a decent choice assuming you can tolerate the number of £$%^&*'ing symbols

*Possibly found a new signature quote...

- To make sure my response is somewhat in relation to the topic:
I am all for the adoption of Vue, and I perhaps may be able to offer some assistance to the project once off the ground. - also can I have a prize just for participating? Like a well done you've come last sort of prize? 

 

 

[KyleMassacre]

14 hours ago, Alan said:

/me inserts oar...

I've rewritten a number of small ""engines"" over the years, and what I personally discovered was a number of things.

a) Like a lot of projects, if you start arsing around deciding on the name or the framework ... you are royally fracked. You are talking about Laravel, rather than a PSR-7 compliant system, so as far as I can see, you have already shot yourself in the foot. Laravel is good, but it suffers from a number of problems. A game framework needs to look at a number of issues; there's the core command dispatching which itself needs an event listener - not a framework. Solve *that* problem, and you might be able to make something which is framework agnostic as not everybody has the capability or wish to run a Laravel based system.

b) Why are still talking about PHP? There's a wealth of languages out there that are *potentially* better for a gaming project. Python being an obvious choice, though there are some other languages such as Go which may be suitable.

@KyleMassacresince you replied before I could post... mm Laravel modules; see point a). Yes, I agree a modular system is a *good thing* (tm), but you have automatically tied yourself to a specific framework. Perhaps something a little more open?

Okay, so I've inserted oar... so what would *I* choose? A fully PSR-7 compliant system - Laravel breaks down here as it likes to do things *its* way - And what about a DI? I seldom use the DI that is provided with a framework preferring something a little more flexible. Laravel uses a service container principal which is ... slightly smelly for those who are purists. It's a nice concept but again suffers from some odd problems which will bite you from time to time. Actually, given a choice, I'd choose Python probably using Flask or Django or perhaps Go. Heck even Perl is a decent choice assuming you can tolerate the number of £$%^&*'ing symbols.

tl;dr;

1. Don't "name" the project - nobody cares what is called as long as it works (wip will suffice for instance)
2. Look at simpler, cleaner frameworks that are more generic allowing the end-user [programmer] a greater degree of flexability
3. Don;t ever trust SRB - he really does like midgets
4. Look outside of PHP, there is a lot to be gained by looking at other languages

You do raise some valid points here but I would like to respectfully disagree solely based on what I believe the objective is. Just note that I could be completely wrong here.

From my understanding with zero evidence is that the point of this is more along the lines of like a “MWG Welcome Back Community Engagement Project”. For a “personal” project, I think everything you stated would be spot on. Sure, with the combine knowledge of anyone here that is taking the slightest bit of interest in this, we could create a killer end product.

Using a framework like Laravel for example imho would be ideal for a community type project where you potentially have everyone’s hands in the cookie jar because of the standards it sets forth from the get. Take a gander at a lot of the sub forums here for any particular engine, go to the free section and pick a thread. What do you see? Probably a lot of *explative* code that doesn’t work and a laundry list of files you have to edit/add/replace for a single database call. At least with some (for lack of a better term) major open source framework, that type of thing is very minimal. It may just end up being: “Add this trait to `SomeClass`“,or “this class needs to inherit that class”.

I just think using something like this in the end makes it easier for everyone. Like to use Vue? Go for it! Like HTML better? Blade isn’t too far off. Want a different language? Just edit the language files. 

 

Edited March 16, 2019 by KyleMassacre
Double post.

[Alan]

I think my point about frameworks can still be upheld, however it probably depends on your experience with frameworks in general. Personally, I dislike full-fat frameworks as the massive amount of code that comes from a 3rd party makes for more complex debugging when something funky breaks. Take the quick-start example from Laravel - outside of the fact that the installer fails on PHP 7.2 & 7.3 as it is not quite ready for those, a line-count of PHP files suggests 230,000 lines of code before I have written anything. If you choose a lightweight framework, then that can easily drop down to < 80,000 lines.

Yes, there is no question that this means a little more work on your part, but what is the aim here? Adding a couple of lines into your routing for login and register is great when we are at work and need something done in a hurry, but *how* do those controllers actually work? A clean login controller can be written in what? 12 lines or so - and with that you get ability to actually see the code that is doing the work.

With light-weight frameworks you are in control, not some third party; this gives you a lot more flexibility however I'll agree it does come at the expense of actually have to learn PHP.

Saying that - if you think that Laravel is the ideal starting point - go for it. I'm no expert in Laravel and I'm very willing to see how others would implement a basic core system; I'm pretty sure that given the current marketplace, that is where this project will end up in fact, however I'll stick to my guns and take the approach that actually learning the language is the target here rather than learning a specific framework.

I'm certainly very interested in seeing the different approaches by people to solve this problem as each person will have their own views based on their experiences and the sharing of those experiences makes us all better programmers - I'll look forward to seeing your code. While I will be submitting code, I've no reason to think that it will be the winner here; however it may - as is its intention - give people food for thought.

[Dave]

2 hours ago, Alan said:

I think my point about frameworks can still be upheld, however it probably depends on your experience with frameworks in general. Personally, I dislike full-fat frameworks as the massive amount of code that comes from a 3rd party makes for more complex debugging when something funky breaks. Take the quick-start example from Laravel - outside of the fact that the installer fails on PHP 7.2 & 7.3 as it is not quite ready for those, a line-count of PHP files suggests 230,000 lines of code before I have written anything. If you choose a lightweight framework, then that can easily drop down to < 80,000 lines.

Yes, there is no question that this means a little more work on your part, but what is the aim here? Adding a couple of lines into your routing for login and register is great when we are at work and need something done in a hurry, but *how* do those controllers actually work? A clean login controller can be written in what? 12 lines or so - and with that you get ability to actually see the code that is doing the work.

With light-weight frameworks you are in control, not some third party; this gives you a lot more flexibility however I'll agree it does come at the expense of actually have to learn PHP.

Saying that - if you think that Laravel is the ideal starting point - go for it. I'm no expert in Laravel and I'm very willing to see how others would implement a basic core system; I'm pretty sure that given the current marketplace, that is where this project will end up in fact, however I'll stick to my guns and take the approach that actually learning the language is the target here rather than learning a specific framework.

I'm certainly very interested in seeing the different approaches by people to solve this problem as each person will have their own views based on their experiences and the sharing of those experiences makes us all better programmers - I'll look forward to seeing your code. While I will be submitting code, I've no reason to think that it will be the winner here; however it may - as is its intention - give people food for thought.

I’m excited to see your framework free submission ?

[Alan]

So can we assume we are looking for something like ... https://sandbox.node86.com ? It's very simple - running to < 600 lines of code + a small framework of just over 80,000 lines (which is I suspect far too much). Code BTW at https://git.node86.com/?p=sandbox.git;a=summary

Edited March 18, 2019 by Alan

[Guest]

5 hours ago, Alan said:

So can we assume we are looking for something like ... https://sandbox.node86.com ? It's very simple - running to < 600 lines of code + a small framework of just over 80,000 lines (which is I suspect far too much).

I get mixed content errors with your jQuery link, which seems to break everything else. Then I get errors on registration

Didn't realise Slim also uses Whoops error handling. Whether it's 80k, 150k or 200k lines it doesn't really matter that much. It's how the framework uses that code that matters, obviously it doesn't use all the code on every request, take Magento for example, it's huge, a behemoth of an application, but you add caching and such and you can still get it pretty speedy. Less code doesn't mean something is bad. Bad code is bad ?

[Alan]

Slim doesn't use Whoops - that was simply an addition so that I could debug the code locally - and for whatever reason clearly my username exists validator is wonky! Mixed content - odd, never noticed that on testing; that will teach me for trying to rush something out the door. For those that cba to create an account; you can login with makewebgames/makewebgames.

As for big code-bases and caching; yes, you can get decent speeds out of them, however my point was not about speed, but more about reducing the potential complexity of the code. I have multiple applications in the 4-6 million line mark all run sweetly, however with reduced frameworks, the reliance on 3rd party code is reduced (look at Node's problems with ZeroPad for example) and certainly makes for easier debugging since I'm not having to single-step through so much library code - and as can be see from above; even professional programmers make mistakes.

[SRB]

Before we even get to the polling stages, I vote for Laravel.

I like Laravel. I like Eloquent. I don't like writing more of the code than I need to.

[Veramys]

I vote make SRB write all the code. Especially more than he needs ?

[KyleMassacre]

1 hour ago, SRB said:

Before we even get to the polling stages, I vote for Laravel.

I like Laravel. I like Eloquent. I don't like writing more of the code than I need to.

I agree but also agree with Alan here. There are just some pros/cons to both. I mean, if we came up from scratch it would be more fulfilling and we would only be bound by our own code. But on the flip side to that, we wouldn’t have to reinvent the wheel. 

I am just torn

[SRB]

3 hours ago, Veramis said:

I vote make SRB write all the code. Especially more than he needs ?

I vote to ban this guy. Reactions = agreement.

[Guest]

2 hours ago, KyleMassacre said:

I agree but also agree with Alan here. There are just some pros/cons to both. I mean, if we came up from scratch it would be more fulfilling and we would only be bound by our own code. But on the flip side to that, we wouldn’t have to reinvent the wheel. 

I am just torn

Using Laravel though you already have all the documentation written for the core framework (Laravel).

Would it really be more fulfilling to rewrite what frameworks already do? Remember our track record of actually building an engine. imo better to start with cake already made and just add the icing.

[DopeboyGFX]

Vue.js huh

[Dave]

5 hours ago, DopeboyGFX said:

Vue.js huh

It’s a front end JavaScript framework: https://vuejs.org/

[DopeboyGFX]

3 hours ago, Dave said:

It’s a front end JavaScript framework: https://vuejs.org/

I looked at it. Looks interesting 

[Guest]

Something happened on Github.

[Veramys]

Now now SRB, no need to be mean ?

[Aventro]

Laravel is approachable, well documented and its ecosystem is solid. +1 

Edited July 22, 2019 by aventro2

[Aventro]

On 3/15/2019 at 12:42 PM, Dave said:

• Authentication
• Communications
• Notifications / Events
• Donations / Payments
• Stats
• User Attributes (money, etc)
• User Preferences
• Admin Framework 
• Theming 

?

On 3/15/2019 at 2:26 PM, KyleMassacre said:

If you weren’t too concerned with using all custom code with this there are a few things out there like a modules plugin for people to easily create modules within their own app/namespace easily without having to mess with their composer file in the root.

Looks interesting. Using this architecture the engine could be a set of modules. This allows for a separation between the engine and the game (the Laravel application).

Edited July 24, 2019 by aventro2