Jump to content

Syntax

Programmer
  • Posts

    127
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Syntax

  1. Hello all! I'm seeking several artists to create artwork for a project I'm working on. Looking for artwork in some of the following categories: Item artwork (weapons, potions, trinkets, artifacts, etc.) Creature artwork (sketches, full designs, poses, etc.) Scenes (nature, caverns, towns, etc.) This would be fully paid work, and not full time but definitely a consistent gig. If you are interested please DM me here or hit up Syntax on discord with the following What categories you're interested in doing Your portfolio Your desired price range/structure What inspires you?
  2. Like what @judda said, a 500 error indicates a code issue, and changing the htaccess probably isn't going to get that fixed. Can you access the logs on the server? nginx logs for example would dump a more explicit error than 500 which could help. failing to open stream sounds like a fopen or file issue, which doesn't make sense on a registration page unless maybe there are files on your server with incorrect permissions.
  3. Super happy to see this. I know I've been out of the loop the last couple years but would love to get involved in some projects and see some revival in this community.
  4. You can try pulling elements from other genres of games. Many MMO's have a storyline or campaign that's considered essentially a really long introduction, with the endgame being the looting, collecting, events, etc. Try to make new content unlockable in some way. Don't just throw it in a store and call it a day, set up a system of either randomly generated rewards or requiring some effort to get the new stuff. Provide methods of 'secondary' goals. Typically most games have a standard endgame goal. Be the strongest possible, defeat the elite four, beat the big bad boss, etc. But having secondary goals such as completing a pokedex or finding that one special armor piece to complete a look or breeding the perfect IV Charmander keep people playing long after they've 'finished' the game.
  5. I have a quick update for everyone! We are still on track for launching the BETA soon, we're just doing some final testing of a bug reporting feature we built for BETA testers, tweaking some economy changes and testing an overhaul to the creation UI. I'm really excited about these things though, so I'm sharing some info and screen shots for everyone Bug Reporting! We built a Bug Report tab available on every page of the site to make it super easy to report issues found. It sends a report directly to all the devs so we can review and fix any issues. This will be available during the entire beta period, and we may keep the feature around even after launch if it seems to be working well. Economy Tweaks! Part of the inception of this project was a sort of self-rewarding points system. During beta and at launch there will be a currency, points which can be earned through various activities on the site such as interacting in the forums and having your creations adopted. The points are then used to add additional features to creations such as additional stages. We have a TON of ideas and potentials for this system, although for launch we are trying to keep things to a minimum so we can make sure we're not the only ones who like these ideas! Overhauled UI for Creating Adoptables! As far as forms go, creating an adoptable isn't the simplest. But we've nixed the multi-page creation idea in favor of tabs that can be filled out in any order at any time. We've included drag-n-drop to reorder stages and the number of stages is only limited by how many points you have. When you're done and happy with what you've created, you can publish your creation so it can be adopted! Again, we're keeping things simple for launch but have a list of ideas we'd like to implement in this area as well! Thoughts, ideas and questions are always appreciated! Thanks for reading
  6. Yes, but the access code for the beta will be through the emails only. We're not anticipating an incredibly long beta period before final launch though, probably a few weeks at the longest.
  7. Thank you guys! I'm really looking forward to the beta :)
  8. In just a few weeks, a project much like squiby.net once was will be launching a closed beta. We are looking for interested testers to help us find bugs in the system but also to give us feedback about UI, features, community policies and the like. Anyone who is interested in joining the beta or just wants updates on the project going forward can get involved here: https://mailchi.mp/753694387517/join-the-beta We are fully expecting the BETA to launch before March, and also want to provide BETA testers with some extra perks when we are fully launched but we're hoping they will help us figure out what they want. Thanks for reading!
  9. Yes, I love Stripe. Currently working on a project that utilizes their Stripe Connect and Recurring Payments functionality and I was very, very impressed with their documentation and support. If you have any questions I seriously recommend reaching out to them because not only will they answer your questions and provide as much documentation and helpful resources as they can they've also continued to follow up with me over the last few weeks just to see if there was anything else they could help with and ask how development was going.
  10. Only the former. Information shared publicly of oneself does not need to be encrypted. The only thing with forums/chats/etc you may want to think about is dealing with the removal of info if the original poster would like it removed or removing info one user posted that was personally identifying another user. Either way encryption isn't necessary unless you're specifically collecting or compiling this info. Many social media sites collect this info either directly or indirectly to help target ads to you or use it for large data analysis to predict trends and behavior. If the messages in your forums, chats, etc. are simply being stored for historical/public reference that should be fine.
  11. Pulling from MMORPG games, many of them use time as a way to sort of break up potentially repetitive things. Time to re spawn targets, time to restock stores, time before you can do xyz again, or you have to do xyz before this time for this reward. In addition to physical rewards for completing daily tasks, you can layer rewards. Meaning if they complete 1 task they get 1 reward, but if they complete all three daily tasks, bonus reward. Providing minor variation can always be helpful as well. Shop keepers having a dozen potential different lines to say, different amounts/items to collect for a quest, etc. Even if the variation is mostly cosmetic/shallow that variation can keep things interesting for much longer.
  12. The GDPR is very vague, but maybe some food for thought can clear it up a bit. As a general rule, the GDPR is considered to cover the following areas: Basic identity information such as name, address and ID numbers Web data such as location, IP address, cookie data and RFID tags Health and genetic data Biometric data Racial or ethnic data Political opinions Sexual orientation Obviously that does seem like a lot but especially for games it's not a huge impact. First look at what information you're collecting. And by that I don't mean what are users willingly posting publicly on your forums but are you REQUESTING users fill our their political opinion, sexual orientation, etc. Second look at what information you're using. Are you selling information or compiling information for a specific use? Are you collecting metadata that would imply certain things(like political opinion based on article 'likes' or something)? Most virtual pet sites will need very few changes for this if any. If you're collecting users names and addresses... consider reworking the system to use usernames. I can't think of a reason to collect an address unless you're using an e-commerce system in which case you can use other services who will collect and store that information for you. If you're collecting IP addresses... It may be necessary to encrypt this to stay compliant. If you're using cookies... Sessions? Encrypt anything you save in cookies For additional covering of bases, provide a 'privacy policy' that explains what you do with the information you collect, and who has what access to what information that might be thought to be private (such as mods being able to see your private messages or personal notes). Finally, always consider having some sort of contract with anyone who may potentially access your users data intentionally that could essentially put any leak or security blame on them if it properly their fault. This means vendors, subcontractors, employees, etc. If they need access to the data(for example to optimize a database) make sure you have an NDA or some other sort of contract that will put them in a legal bind if they were to choose to misuse the data. Properly encrypted data will somewhat mitigate this risk however.
  13. Using SSH in place of normal terminal logins would mostly resolve this. You can also use firewalls to block access of database and ssh ports from all IP addresses except your own. I wouldn't go into production with a server you're unfamiliar with but personally I'd actually prefer to experiment with a host like Digital Ocean over using or exposing my local computer. It was a little intimidating at first, I started playing with Digital Ocean with pretty much no sys admin experience out of need for my company but DO provides a lot of support and they have an incredible library of tutorials and there's options to spin up servers with most of the software you need installed already. I don't know what you're budget is but if it allows I'd recommend looking at Forge(forge.laravel.com) too. They provide a really nice interface for managing server sites, ssh logins, ssls, databases, etc. It can be pricy but if you're just dealing with one server it's not bad.
  14. Hey everyone! So my life has -finally- settled down and most of my major projects have wrapped up so I'm looking for a new one to jump into! For those who don't know me or my background I'm a developer with over 10 years of coding experience. I prefer primarily to work with PHP and Laravel. My current job is in web application development where I'm the lead developer. I'm looking for either an established project(close to or already launched) that I could join long term or to partner up with someone who would do or fund the artwork for a project. Just shoot me a message if you're interested but please don't be offended if I'm not interested in a project, I'm really looking for something I can dedicate years of my life towards.
  15. TGL has only been around for a year, are you maybe thinking of Virtual Pet List?
  16. I did not actually even try to negotiate it. I was way too unsure of myself at the time and it was one of my first jobs but I knew it would never fly in court if they tried to push it. It was also a tiny company that barely had the resources to hire me much less push anything legally. Im NOT recommending anyone do that ever, you can still screw yourself over it was just a calculated risk for me I suppose. But I've learned a lot since then and I wouldn't do it again. But yeah, even if you don't know all the law you should be able to navigate the stuff that applies to your business at least! Knowing these contracts is just as important as knowing how copyright works.
  17. Well done, contracts are usually murky territories for anyone not in the legal world. If you don't mind I have two additional bits that might be useful Just some bits form personal experience! When someone is in violation of your copyrighted work, code or art, typically you can reach out to the website host or publisher with a copy of the contract. Most of the time publishers or hosts will simply pull the content as long as they believe you have a reasonable claim and you don't need to get a lawyer involved unless you're looking for damages or compensation. Do not make your contracts too burdensome! Even perfectly legal and agreed upon contracts can be thrown out for a single line being determined to be too burdensome. What does that mean? It means you're asking for too much from the other individual(millions of dollars for cancelling a five hundred dollar project, demanding their first born or 7 years of servitude). This kind of thing is done to prevent people from accidentally signing themselves into slavery. But if the contract is reasonable most small claims courts will happily hold both parties to them. I once had an employer include a non-compete clause that basically said I wasn't allowed to work anywhere else in the country in my industry for 2 years if I left because any company in the country could be a potential client. There's no way they'd be able to get that to hold up in court because while you can prevent someone from stealing your trade secrets and acting as a corporate spy, you can't completely deny them from working in their field of expertise.
  18. In the past I have typically designed inventory systems to be two-part. The first being the item itself, and the second being a function category. The item data like it's image and name is held with the item, while the function category determines if the item can do anything, like act as food for a pet or be used to paint, in a specific feature, etc. It can be a little tricky depending on how you want to vary these up but because I've never needed to search by the field I usually just store some kind of array or JSON in an extra field with any additional data needed for the item. Like a food item may fill up a pet's belly by 10pts or 50pts, etc. It makes it easy to grab items from a user's inventory then that only apply to that function category(s) when say feeding a pet.
  19. Frameworks tend to have a little bit of a learning curve to start but for the most part provide waaaaay more additional functionality that is a huge help that makes up for the curve. I personally like Laravel as well, but I've use CodeIgnitor and Slim before as well. Frameworks usually help tackle the things that wrap your website and assist in supplementary functionality like securely handling form submissions, routing, authentication, template rendering and database interaction. If you start from scratch you can do things the way you want them, but to be honest unless you are a VERY savvy developer I wouldn't recommend it. Frameworks will also introduce you to higher level concepts that you may not come across by just building your app the way you want. As far as languages go... every programmer and developer has an opinion and bias. I've listened to dozens of industry leaders in web development who were in Ruby, .NET, JS, PHP and the basic consensus among them all is that language really comes down to your values as a developer and what you want in a development community. No language is perfect, and each one has trade offs. Building your website in whatever language you choose is unlikely to have any real consequence until it becomes a very large site anyway. However that's all typically server side code. For front end you want to be looking at HTML/CSS and Javascript fundamentals. CSS Grid is kind of the big thing right now in that realm. As you get more advanced you'll also want to learn about tools for asset management, and post/pre processor's for CSS like SASS/LESS.
  20. I'm also a huge fan of Digital Ocean. I run about 20 or so droplets with various projects and architecture. They have a lot of pretty good documentation and there is a basic LAMP setup that works for most default php applications. We use the servers in combination with forge.laravel.com to help manage the servers. Might be a little pricy for just one server but it is a pretty big help when it comes to managing firewalls, ssls, databases etc. I've never had any issues with DO, any maintenance or downtown I've been alerted to ahead of time and it's been minimal, they've improved their pricing since I became a customer, they're support is super helpful and if you reach out to them and they even offered us a $500 credit to help cover the costs for us to transfer our entire architecture over to them. They've also rolled out a half a dozen new features in the year we've been with them. Heroku is another option in the same realm, but I've used them significantly less and can't say much.
  21. what is seo? SEO stands for Search Engine Optimizaiton, and it is basically optimizing your website to fit the rules that Google and other search engines use to rank sites. Good SEO means better ranking when users submit related searches. Click here if you want a more in depth look at SEO as well as some other resources for SEO. what is this? There are tons of tips, guides, advice and bad advice out there for SEO. Some of it is technical, some of it isn't and a lot of it is unnecessary or doesn't make much impact for the amount of work it takes. Through experience both with browser games and building websites designed for SEO strategies, I've handpicked some of the most basic and important ways browser games could improve their SEO overall and things you should take into consideration when building a new browser game. 1. no tricks Google designs their algorithms to encourage websites to follow certain kinds of behaviors and standards. There are a lot of ways to get around those rules or abuse them but Google is usually pretty good at recognizing when you're doing that and will actually penalize your website if they discover you're using shady methods. There's no such thing as an SEO 'quick fix' and while you can be creative with your SEO you want to avoid doing things that are obviously trying to subvert Google's rules. 2. make your content public It is the tendency of browser games to hide all their content behind a login. For some stuff this makes sense, but wherever possible you should make content visible publicly. News posts and comments, forums, guides & lore are all content that doesn't necessarily have to be hidden by a login. Of course it's not a requirement but it is super helpful for your SEO if your content is public especially content that updates frequently or generated by your users. 3. don't neglect your marketing site So when we build a website that has a lot behind a login, what isn't behind the login we call the 'marketing site' or the 'marketing side'. This let's us split the expected user group into two groups, those who we're targeting to get them to join, and those who are already registered. It's very common to see pet sites with a bunch of links and if you start clicking through any of them they ask you to login. Replacing your menu for someone who isn't logged in is usually a trivial change, and then providing content to them to explain the game or showcase the best parts of it is now a way to draw in new users and provide Google with some content that's not hidden! Win-win! 4. links and embeds Links are another big factor in SEO. More specifically, link backs. That's when another website has a link to YOUR site on it. There are a lot of ways to build link backs, but it's important to remember quality of quantity. Getting a link back from an extremely reputable website is worth a whole lot more than tons of links on small unknown and obscure sites. Do interviews, offer to write blog posts and just ask to include a link to your site on the page. You can also offer your users ways to show off their pets or avatars on other websites with a link back to your browser game. If you can get a link onto a big gaming blog you'll see a bigger impact of traffic both from the link and organic from Google. 5. google analytics You don't have to learn what the terms mean, how to read them or anything. Just create an account and install the code in your browser game. When you're ready for bigger marketing campaigns and honing your SEO strategies you'll thank yourself (and me) for having had Google Analytics installed beforehand so you have lots of 'before' data to compare your 'after' campaign data. Even if you think you'll never do any sort of SEO or marketing campaigns, just install the code. I don't care what your excuse is, there is no excuse for not having Google Analytics on any live site. View full guide
  22. what is this? So I see a lot of projects fail or go miserably wrong because not enough attention was paid during the planning stages to really nail down a plan of action surrounding the features and functionality of the project. This is a guide to help remedy those problems, and can really be applied anytime during the project however the sooner the better in most cases. This is not strictly a programming/development guide either, you can apply the concepts elsewhere but for the purpose of not being super vague I'm orienting this guide to feature development. Also forgive me if you are not familiar with Pokemon, I use a lot of Pokemon related examples to illustrate the concepts I cover. minimum viable product So it's really tempting when starting a project to sit and brainstorm and daydream for hours about all of the fantastic features your project will have and all the people who love it. I do it too, and while there's nothing wrong with that when you get down to seriously planning a project you intend to see through it's just impossible to start there. Write your ideas down, make a list of all the features of your dream and then toss that document aside for later. Pick one feature. Now when I say one, I don't mean the login/logout or anything that would more or less be considered the framework of your project. What you need to do is identify your minimum viable product. That means you need to figure out how to make your project the smallest it can be, and still be at it's core a fun game. It doesn't sound intuitive but it is important. So you should identify the base feature of your game. What is the ultimate goal? Why are people logging on to play? Is that feature fun or rewarding, without any other embellishments? Not everyone would but I consider Pokemon to essentially be a virtual-pet game, it's just on a different platform. If you think about all the features Pokemon offers in their games it can be mind boggling, but at it's core the main feature and main draw for the game is surprisingly simple and even in their slogan. gotta catch 'em all. Pokemon is a game based on collecting, all the other features are more or less secondary to this main feature. You want to complete your Pokedex, or at least catch your favorites and that's what they rely on to be the main thing that's fun in the game. That's what I mean when I say identify your main feature. It does not need to be unique, and it does not need to be revolutionary, it just needs to be a solid draw. Whether that feature is community based, collectable based, creation based(breeding or building sites), etc. it just needs to be identified what that feature is. If you think you can make a successful game or project revolving around that main feature then fantastic, hit the ground running and save the dreams for later down the road. Most people will not want to stop there however, and that's okay. Once you have that solid main feature you are going to want to select one or two other features that compliment that main feature very well. That does not mean battling and breeding should be those two features. If you're doing a collection based site maybe create multiple ways to collect pets(different types of pokeballs?) or make certain pets only collectable through certain methods(only obtainable if you trade with another player). If your site is heavily community based and your main feature is the forum, a live chat would be a good compliment. These other features should maintain the same goal as your main feature, and should seek to improve that main feature in some way. Be careful whenever you add a new feature that you are making that feature as small as it could be to start with. As you go through this process create a new list of your MVP feature list, and at the end compare it your original dream feature list. If even 50% of those dream features are on your MVP list then you are probably still being too ambitious. I can't stress enough how important it is to really cut out as much as you can and start small. Creating a game or website is a very large and daunting process and it is so much better to get something successfully out there in a few months than it is to spend 3 years on a gargantuan project and still not have a launch date. It's also a lot easier to learn from the mistakes you make the first time around when the project is smaller, and it's more rewarding because you're more likely to cross the finish line. understanding scope In the project brainstorming phase of projects I see a lot of people being extremely vague about features that they want but haven't really thought through. However it's crucial when you're brainstorming features to be very specific about what that feature is and is not. Think of a feature scope as a list of rules to make the feature work or not work as intended. Imagine explaining how to collect Pokemon to someone who knows nothing about the game, but being specific enough that they could recreate the game. A vague statement will produce a vague or incorrect result. Bad Statement: "You throw a pokeball at the pokemon to catch it." Bad Result: A game where every time the pokeball is thrown, the pokemon is caught. Better Statement: "You throw a pokeball at the pokemon to catch it. The higher the level of the pokemon, the lower the chance to catch it." Better Result: A game where the level of the pokemon determines whether or not throwing a pokeball results in a successful catch. The idea is to then become more and more specific, so if you were to explain this to someone they would understand that if they knock the pokemon out then they can't catch it, or different pokeball types work better or worse for different pokemon, or that status effects also effect the success rate of a pokeball. Define all the rules of your feature, and then try to imagine someone attempting to cheat. Pokeballs don't work when you throw them at a pokemon owned by another trainer. If you can define all the rules of your features, that will go a long way to help whoever will have to program the functionality, but also keep communication clear about how something is expected to work and whether or not a change fits within the current scope or not. If you are changing or adding to the scope during project development, that's something called scope creep. It is not good, not fun, and usually leads to both angry project managers and angry developers. Once development starts, you shouldn't mess with the scope except where development needs clarification. Additionally, if you have changes you want to make then run it by the developer first to make sure they are comfortable with changing the scope or to find out what kind of impact that change will have on cost and deadlines. Finally, make sure the feature scope with all the rules fleshed out still fits the goal of the feature. If the rules of pokeball throwing made it extremely difficult to catch any pokemon, maybe there's a rule that shouldn't be there because it shouldn't become difficult to play the game. Stating the goal of the features(be more specific than 'be fun') can also help a developer or even yourself 6 months from when you wrote the scope have a clear understanding of where you intend to go with it and what you were thinking when you developed the scope. feature value Did you know features have value? There are ways to calculate hard and monetary values for features, but that could be a guide all by itself so I'm not going to get into that. But when you are generating feature ideas to add to a project or to an already launched game you should always be considering the value that features bring to the site. If it's a small feature but it's going to take a lot of programming work and your users could more or less live without then it may not be worth it to bring that feature in. A mantra of mine with browser based games is that your features for the most part need to be harder to consume than create. That means if it takes you 10 hours to create a quest line that will occupy users for 10 minutes, that would be a bad consume to create ratio. You want to flip that ratio as much as you can so that your users remain entertained by your content and features, giving you time to develop new ones without people getting bored or frustrated. Many people turn to random generation to get the ratio in their favor and if you're clever enough that can be a fantastic way to generate fresh content but there are other ways as well. If you can make small changes to a feature to make it last longer without becoming frustrating for the users, you'll find yourself with a lot more room to develop and come up with ideas. For example if the questline you created required users wait until nighttime to do a certain task, or require that they do some investigation to figure out the answer to a lore riddle then you can expand that questline time from 10 minutes to potentially 12 hours without overburdening your users with meaningless and boring tasks. If a feature you create can do any of the following, it's bringing in value. Monetization Bring in new users Keep users occupied for longer than it took to create Generates excitement or community organization If a feature does any of the following, you're actually losing value. Drives away current users Conflicts with the general mission Causes other features to become useless or undesirable On rare occasions it's okay to create a feature that hits a point on that second list as long as it's being made up for in a clear way on the first list. Also, do not feel bad about removing or heavily modifying a feature you realize is having a negative impact on your site or does not fit your goals. conclusion If you can make your project small, focussed and have a fantastic understanding of your features you'll be a lot better off when you hit the development level and more likely to avoid some common pitfalls. Especially if you're working on your first browser game site I highly recommend making it as small as possible so you'll see more progress, be less likely to give up and you'll learn a lot along the way to make your next project even better. If anyone has any recommendations, comments or feedback please share. I'd love to expand and update where necessary so it's truly helpful to people. View full guide
  23. I don't believe any medical services should be supported by governments or required to be supported by employers especially if those medical services are a result of lifestyle choices. Regardless of whether or not abortion is right or wrong the fact is that abortion does go against religious laws/conviction for a lot of people and religions. Thus mandated support of abortion and freedom of religion/expression are mutually exclusive. If your 'right' to a free medical service hinders another individuals rights, then freedom is lost.
×
×
  • Create New...