Project Valenguard: A retro MMO with a Chrono Trigger live action Tech combat!

[CptOvaltine]

I'm following this thread, even if I don't always reply.  I'm very interested in seeing how this develops.

[unenergizer]

Hey bud, triple posting is okay over here. So is thread necromancy! As long as it's not blatant abuse, of course. But we don't discourage others with overly-stringent posting rules. Just as long as it's not insanity.

Sweet. Now I can make all the posts! 

I'm following this thread, even if I don't always reply.  I'm very interested in seeing how this develops.

No problem man! Glad to have peaked your interest regardless!

Alright quick update.

I plan on getting a lot of combat stuff done, after I get some other basic functionality done. My thoughts are to have a few things implemented so when people go to test, they feel like they are playing a real game. When I say real game I mean I want you to be able to kill stuff, pick up items, trade items with players, use npc shops, etc.

Combat is the funnest part and I am saving that for last. Well not completely last, but you probably get what I mean.

Tonight I started to implement trade windows. Because trading loot with friends is cool.



Things we have left todo:

1. NPC Drop Tables [completed]
2. NPC Alignment (hostile, neutral, friendly) [completed]
3. Player Leveling (exp gains) [completed]
4. Player Item Trading [completed]
5. NPC Shops (add currency) [completed]
6. Player Banks
7. NPC Factions [completed]
8. Player Class System <in progress>
9. Player Party System
10. Player Guilds
11. NPC Walk/Run Paths
12. Quests and Story Telling
13. Cinemetaic map fly-throughs
14. Attributes such as resistances, damage, armor class, and more
15. Combat Spells, Special Moves, Combos, and Buffs
16. Dungeons/Raids
17. Professions (mining, wood cutting, etc)
18. Crafting
19. World weather
20. Day/Night Cycle
21. Automated/Fast Travel (boats, teleport pads, flying on birds)
22. Minigames (arenas, battlegrounds, gambling, card games)
23. Player Stat tracking (monsters killed, miles walked, etc)

[unenergizer]

Trading now works! Took about 5 days 



Next up: NPC shops! I plan on being able to finish this one today!

[unenergizer]

Okay we've been hard at work on the game! Everyday I get something done.

Since I don't have any awesome combat to show yet, how about a cool code visualization?

The following video shows the process of building a mmo game. Watch the little guy fly around and zap dots. Every time this happens code is being written, edited, or deleted. It shows about 5 months of work!

Enjoy!
https://www.youtube.com/watch?v=0lKLCAjl0Oc

[CptOvaltine]

That is both a really weird, and really cool thing to watch!

[chrono.source]

That was actually pretty cool

[unenergizer]

Alright I wanted to get this done a lot earlier, but the framework is now setup for NPC shops!



A long with this a lot of tiny features were added and tons of bugs fixed.

When we get some more of the features built and some combat spells/effects going I will be reaching out to you guys to give you the ability to access and try it out. Expect bugs and some ugly user interfaces, but when the art direction is established everything visual will be cleaned up and polished.

Cheers guys!

[CptOvaltine]

Sounds great!  I'm looking forward to it, and would be happy to help test it out!

[unenergizer]

Alright got factions implemented into the game. In the gif below it shows an example. When you kill a factions friends, they can become hostile towards you.

Killing a npc can lower your reputation with his faction and raise your reputation with his enemy factions. Notice how when one NPC dies, his faction friends turn hostile towards you (indicated by a red name) and his faction enemies turn friendly towards you (as indicated by their names turning green).



So this is done and works well. A lot of design needs to go into this such as faction types, how many reputation points you gain/lose when attacking NPC's etc.  For now the base system is sufficient.

Next up we will get MySQL database up and running to save player progress. After this is done, we will begin doing combat related code. This would include making armor stats work, giving player entities classes and races, and then the good stuff. Chrono Trigger like combat! <- That is what I am most excited for!!!!

[Boo the Gentleman Caller]

This is coming along pretty quickly and nicely!

[unenergizer]

This is coming along pretty quickly and nicely!

Yes sir! Were trying to get it done

Today we have completed the login protocol. When you sign up at the ForgeStorm website, you will use this same username/password combo to login to the game.

Currently registration is closed on the website while I figure out the best way to prevent bot signups. Forum spam is annoying, as you all already know. It needs to be hard for computers and easy for humans to register. No system is perfect, but the more bots we block the better!



Also, the website uses BCrpyt to hash/salt your passwords. Plain passwords are never stored in the database. The website also uses SSL to make sure your connection is safe and secure.

The game login protocol also uses SSL to make sure that when you login to the game, your information can not be read by others on the network.  This is useful for say your somewhere like in a hotel playing the game, your credentials can not be easily stolen/deciphered.

Now that this works, I will begin saving information about your user account to the database. These things will include your bag items, equipped items, logout locations, money saved, faction reputation, and other things!

The website also needs a bit of work as it is using a plain old template with no additional styling. But I guess one thing at a time? lol

https://forgestorm.com/

So here is a bit of extra info for those who like technical details. I was asked why someone has to use the forum to signup to play the game, so I will cover this answer here for you guys too.

We use the XenForo forum software for our community forum. This software already has powerful tools such as the registration system, password reset system, usergroup permission system (or user ranks), friend system, and much more. By using this software as a base for our user system, it saves us tons and tons of time creating these things ourselves. This brings pros and cons.

Pros:
We don't have to make extra support systems (registration, password reset, etc)
Because other people code it, its like we have extra programmers on the team!
The people who make the software have much more experience in this area in terms of security with web development

Cons:
If a flaw or exploit is discovered with their software, it means we are vulnerable too :'(

However in terms of exploits, we will keep an active paid subscription to their software to make sure we maintain the latest and greatest in terms of feature sets and security patches. The best thing todo in terms of keeping player progress and user data safe is to make sure we do automated backups of the database. When the game goes into beta we will begin testing out a system that will create backups. This way if the database is ever compromised, little to no player progress will be lost.

Hope that explains it well enough!

If you have questions/comments/concerns please let me know!

Your friend,
unenergizer

[CptOvaltine]

I'm getting excited for this!  Make sure to let us know when registration is open, and I can try it out!

[alfadorredux]

Currently registration is closed on the website while I figure out the best way to prevent bot signups. Forum spam is annoying, as you all already know. It needs to be hard for computers and easy for humans to register. No system is perfect, but the more bots we block the better!

It's been a while since I needed to secure anything of this sort, but consider the strategies bots typically use:

1. Playing back an old copy of the sign-up form filled out by some human: just place a timestamp in the form and refuse anything too old to block this. Extra credit if you use the timestamp to hash other parts of the form to make it difficult to tamper with. Humans never see it.

2. Filling out every single field in the sign-up form: include a field hidden by CSS or javascript that isn't supposed to be filled out (mark it clearly for people using screen readers or whatever who might still be able to "see" it). Bonus points if the honeypot field is named something tantalizing like "password" in the page source and the actual password field's name is a timestamp-salted hash of "Spekkio" or something. Humans never see this, either (unless they're using very unusual browser configurations).

3. Tailored bots that were carefully set up by a human to manipulate your specific form: This is where the captchas come in, and sophisticated bots used to only appear if it was worth someone's time to set them up, which means your site is already popular. Of course, using a generic sign-up form from a common web application makes it possible there's already a tailored bot out there.

Unfortunately, captchas are human-visible, and they're universally considered a horrible nuisance. How much of a nuisance which kind is going to be depends on the site's audience. In my case, I have to want what's on a site pretty badly to activate image loading or allow third-party Javascript, but most people don't even notice those things, and I'm not your audience anyway (I prefer single player only).

4. Not-a-bots: there isn't much you can do to guard against signups by people in a third-world tech sweatshop. You end up in a three-legged race involving blacklists if your site is significant enough to attract these.

I think we're still another ten years or so from having AI bots sophisticated enough to emulate humans well enough to fill out an unknown form accurately without guidance, thank the Entity.

Excluding IP address blocks and certain User-Agent strings can help curtail bots, but risks excluding some legitimate sign-ups. You could flag sign-ups matching those lists for observation/manual intervention, I guess.

The website also uses SSL to make sure your connection is safe and secure.

The game login protocol also uses SSL to make sure that when you login to the game, your information can not be read by others on the network.  This is useful for say your somewhere like in a hotel playing the game, your credentials can not be easily stolen/deciphered.

Careful, there. SSL is not a silver bullet, even with additional protocols layered on top to mitigate man-in-the-middle attacks. (Having it is certainly better than not having it, though.)

[unenergizer]

Currently registration is closed on the website while I figure out the best way to prevent bot signups. Forum spam is annoying, as you all already know. It needs to be hard for computers and easy for humans to register. No system is perfect, but the more bots we block the better!

It's been a while since I needed to secure anything of this sort, but consider the strategies bots typically use:

1. Playing back an old copy of the sign-up form filled out by some human: just place a timestamp in the form and refuse anything too old to block this. Extra credit if you use the timestamp to hash other parts of the form to make it difficult to tamper with. Humans never see it.

2. Filling out every single field in the sign-up form: include a field hidden by CSS or javascript that isn't supposed to be filled out (mark it clearly for people using screen readers or whatever who might still be able to "see" it). Bonus points if the honeypot field is named something tantalizing like "password" in the page source and the actual password field's name is a timestamp-salted hash of "Spekkio" or something. Humans never see this, either (unless they're using very unusual browser configurations).

3. Tailored bots that were carefully set up by a human to manipulate your specific form: This is where the captchas come in, and sophisticated bots used to only appear if it was worth someone's time to set them up, which means your site is already popular. Of course, using a generic sign-up form from a common web application makes it possible there's already a tailored bot out there.

Unfortunately, captchas are human-visible, and they're universally considered a horrible nuisance. How much of a nuisance which kind is going to be depends on the site's audience. In my case, I have to want what's on a site pretty badly to activate image loading or allow third-party Javascript, but most people don't even notice those things, and I'm not your audience anyway (I prefer single player only).

4. Not-a-bots: there isn't much you can do to guard against signups by people in a third-world tech sweatshop. You end up in a three-legged race involving blacklists if your site is significant enough to attract these.

I think we're still another ten years or so from having AI bots sophisticated enough to emulate humans well enough to fill out an unknown form accurately without guidance, thank the Entity.

Excluding IP address blocks and certain User-Agent strings can help curtail bots, but risks excluding some legitimate sign-ups. You could flag sign-ups matching those lists for observation/manual intervention, I guess.

The website also uses SSL to make sure your connection is safe and secure.

The game login protocol also uses SSL to make sure that when you login to the game, your information can not be read by others on the network.  This is useful for say your somewhere like in a hotel playing the game, your credentials can not be easily stolen/deciphered.

Careful, there. SSL is not a silver bullet, even with additional protocols layered on top to mitigate man-in-the-middle attacks. (Having it is certainly better than not having it, though.)

As far as the signup form goes, you are correct pretty much as basic change in the underlying syntax of the page would/could break most automated signup bots designed for the XenForo forum software. And if someone wants its bad enough, they can modify their code to continue the automated registration. If one man can build it, another man can tear it down.

As far as encryption their is no silver bullet. But we do have something close. For instance this website has a SSL cert that defines how you connect to it. You probably don't think much about it when you sign into this forum. Most people even have their browser automatically input their password upon page visit.  This is where 2-factor authentication comes in. XenForo offers this and we plan on implementing this system into our login protocol on the game.  To be fair though, it would be very rare for your user credentials to be sniffed out via SSL.

If you have any ideas on how to improve, I am all ears. 

Also I hope all of you are ready!



Tonight I have begun breaking down the mechanics needed to create a combat system that gives similar features to ChronoTrigger while also adhering to our client/server spec!

I have a lot I need to do and think about in terms of how it should all work. But I am confident that I can get a system up and running this weekend to get the first pass of real combat done. After we have a single player combat system up and running with a few different types of attacks we will begin to implement player party techs

Cheers!

P.S. I bought an OpenGL ES programming book so I can implement shader programs into our game that would produce effects exactly like Chrono Trigger ones. I need to learn things like vertex shaders, using the depth buffers, and other things to really make the combat look close.
Link: https://www.amazon.com/OpenGL-ES-2-0-Programming-Guide/dp/0321502795

[alfadorredux]

As far as encryption their is no silver bullet. But we do have something close. For instance this website has a SSL cert that defines how you connect to it. You probably don't think much about it when you sign into this forum. Most people even have their browser automatically input their password upon page visit.  This is where 2-factor authentication comes in. XenForo offers this and we plan on implementing this system into our login protocol on the game.  To be fair though, it would be very rare for your user credentials to be sniffed out via SSL.

I do often actually think about how SSL works--you can blame that on the prof who taught my Networks course some twenty years ago, who went over it in detail. In the end, SSL is good for encrypting information in transit but poor at proving identity (because that part relies on the honesty and competence of certificate authorities, and many of them aren't either of those things, really), and trying to make it do both was not smart. We're all stuck with the fallout now, though.

If you have any ideas on how to improve, I am all ears. 

You don't appear to be doing a bad job. Security is always a tightrope walk between user convenience and keeping the bad guys out. I'm not a security analyst, and I'm not familiar with your specific forum software, so I have no business telling you how high off the ground to put your tightrope, or whether the rope itself should be hemp or nylon. 

P.S. I bought an OpenGL ES programming book so I can implement shader programs into our game that would produce effects exactly like Chrono Trigger ones. I need to learn things like vertex shaders, using the depth buffers, and other things to really make the combat look close.
Link: https://www.amazon.com/OpenGL-ES-2-0-Programming-Guide/dp/0321502795

Might also be worth looking at how the original effects were implemented if you haven't already (should be Mode 7 graphics for the more complex ones, and that's simpler than any flavour of OpenGL--you have more patience than I do if you're going to be dealing with that directly).