• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

779 Good

About evillive2

  • Rank
    Advanced Member

Personal Information

  • Location
    Austin, TX
  • Interests
  1. Deploy your server to a hosted solution such as AWS EC2, Azure or Digital Ocean. Avoid port forwarding and all that silliness on your home network potentially exposing you and your family to intrusion. A $5/month server is usually more than sufficient for proof of concept and you can even pay by the hour if that seems overly expensive.   That being said definitely read up on some networking like hplus said. At worst you will understand why your solution may not be working and you will be able to share your perspectives here on gamedev.
  2. A little late to the conversation but a metric in general is just a data point. How important it is to you depends on the context in which you look at it. That being said, much of your generic networking specific metrics from the server side perspective can come from outside of your application from existing network tools such as SNMP, ntop, snort and more. While the learning curve of these runs the gambit from small to zomg! they exist specifically for the reasons I believe you asked - though even more generic since they don't care if your application is a game or not. You can get packets per second, bandwidth utilization to/from specific clients, jitter, packet loss and so much more. I work at an ITSP and these tools are essential for us as we can quickly identify if a new application was introduced on our network or if an application or even specific client is acting up or having issues. There are older tools like rrdtool with C and many other language bindings that you basically send key value pairs at timed intervals to for things you would like to keep track of and also offers a way to visualize that data. Things like grafana and influxdb have taken this concept to another level of scale being used by highly distributed web services today where network and database transaction metrics help them prioritize optimizations and user experience.  As for what metrics look like - they are generally just key value pairs you export at timed intervals and some other tool helps you visualize it in the manner appropriate to you. What is interesting to you? If your application can export metrics to a message/event queue and let something else do the imports to whatever tools you want, the tools you use can change independent of your application.
  3. I purchase, deploy and manage network and server equipment for VoIP services out of many different tier 3 and tier 4 data centers across the US, UK and Australia.   The smart answer is don't buy hardware until you have to. Ramp up using IaaS hosts so you can run on OpEx vs CapEx. This will give you time to raise the capital necessary to get into the data center space. Onlyput stuff into your data center if you can make it reliable. Define what reliable means to you and your end users before even thinking about data center space.   First - data center space is very expensive. It will vary immensely based on contract but it all boils down to power and cooling. The more dense you get per rack, the more cooling your equipment needs. Depending on your architecture and layout of the facilities they will most likely equate a power usage to cooling ratio/sf you must abide by. For example, if you start running redundant 3-phase 60-amp 208v circuits per rack to run a bunch of blade chassis you can easily start to run into requiring thousands of sf of floor space to accommodate the cooling. I will use the term "space" to include power and cooling moving forward. This is your biggest cost.   Second - do you need a carrier hotel or are you okay with 1 or 2 major carriers? This translates into cost for cross connects and DIA circuits and most of all reachability. In most cases with that many concurrent players you will want to peer with multiple carriers like Level3, Verizon, Comcast (and other residential cable/broadband providers) so you can reduce the number of hops it takes for the majority of your players to reach you as well as provide contingency against major fiber cuts that cause providers to route over long distances drastically increasing latency (Ohio I am looking in your direction...). This is your second biggest cost.   The monthly recurring costs of a data center even with only 2 racks can easily be over $100k depending on hardware choices, network requirements and space (remember power and cooling have a defined ratio with square footage) requirements.  If you want to help bring in a more accurate number it really comes down to specifying hardware ( such as blade chassis and blades or stand alone servers etc.) and how many you intend to put in a rack. You also need to figure out if you will deploy racks as kind of a stand alone entity with top of the rack switching or if you will deploy centralized networking with patch panels. It is usually a combination of both but this will play a major role in your ability to automate and orchestrate via smart hands which either way will result in further overhead costs.   Again, I cannot stress this enough - don't get into the data center game unless you absolutely have to. It is rare these days to have an application that cannot work within the offerings/confines of an IaaS provider. There is a tipping point at which IaaS is more costly (operating margins) than running your own data center but by that time your recurring revenue should pay for that transition or you have done something very, very wrong.
  4. As hplus0603 and ProfBeeman have suggested the send/recv calls don't always align especially when network traffic picks up as you have suggested it does.   Some middleware libraries like 0MQ (ZeroMQ) wrap this for you and provide messaging patterns like you are looking for.
  5. I always applaud the idea of using well known, highly used authentication and authorization methods. The only other response I have at this time is the group will probably be more help if you begin implementing your system and ask specific questions. The architecture side of things will always be debatable and to be honest nothing you are suggesting is standout wrong per say. That being said I would imagine your troubles here won't be with your architecture so much as the network jitter and delay interpolation etc on a space shmup.   One suggestion when writing apps on AWS: I have been using redis a lot for a bunch of work projects as a lightweight message bus (as opposed to the bulky more feature rich and complex enterprise ready RabbitMQ) that supports pubsub and message queuing and it has worked out really well for being that general abstraction layer between applications. Instead of applications working with databases or filesystems for data stores for example they work with a very thin request/response API over redis and then I have connectors for the various databases/data stores on the back end for various APIs. It takes a bit of extra work up front but has saved me a bunch on the back side when various design decisions and features suddenly change requirements and scope. It has also really made scaling very easy (multiple instances of single threaded apps).
  6. +1 for SQLite   Having worked on many text based MUDs in the past the one thing that holds true is that the easier it is to manage the data the better because the content is your game.   A few reasons I like SQLite: - the callbacks for executing queries map nicely to constructing objects (1 row - 1 object) - ACID compliant - you would be surprised how often this can be an issue - in a text based world, SQL is just plain useful. - SQLite has a lot of external editors that - to me anyway - are much more suited for structured text / game data - If you outgrow SQLite you can very easily move data to nearly any larger SQL database
  7. There are countless codebases (not many good for tutorial purposes) for text based MUDs on the interwebs. They were super popular in the early 90s and some had rebuilds in the 2000s in languages like perl and python that are probably much more relevant to what you are looking for. The point is many are still actually active and I would recommend playing a few to get ideas on what you want to accomplish in terms of differentiating you game from existing ones. For the most part one can get away with renaming things in the area files as a start and fiddling with existing code to see how it affects the rest of the game.
  8. I know this is an older thread but I just saw it and had some insight I would like to share.   I would also look at using simple middleware like redis. Redis in particular has bindings to most languages including C/C++/C#, python, ruby, javascript etc. which means you have interoperability across programs and platforms out of the box and it is dead simple to use. I use it extensively for voip applications as part of a hosted UCaaS environment for work (nearly 200k connected clients) and unless you are trying to do an MMO first person shooter, performance isn't an issue for thousands of endpoints. Yes it is single threaded but I consider this a bonus as I can deploy as many or as few instances as I want and take advantage of replication and/or clustering for horizontal scaling.   Middleware like redis has saved me ton of time over the past year and has a much smaller learning curve than say RabbitMQ. In my case, application interoperability and rapid prototyping are invaluable to me. Are there gotchas in using middleware? Absolutely but everything has pros and cons. If TCP is your protocol of choice and you want multiple applications to speak to each other, I would be hard pressed to find a simpler solution to at least start with than redis. It wraps common underlying networking paradigms nicely and you can use whatever custom protocol you want for messaging - json or your own binary format - whatever is convenient for you.   One thing - and I feel compelled to say this because I have seen web developers do this with RabbitMQ a bunch - don't expose your middleware directly to the internet. It is a security concern (especially with redis!) and frankly violates the cardinal rule regarding implicitly trusting client communications. My post was mostly about providing "trusted" inter application communication over a trusted network - preferably a LAN. A thin layer providing an API in front of the middleware is always recommended to do basic sanity checks and authentication validation.
  9.     By nature, in an MMO there will be a point in which state must be shared between players in some manner. I help design, build and maintain massively multi-user telco services for work on the magnitude of 100k+ users per cluster. Oddly enough this is far less complex than an MMO :)   As was mentioned, it is always preferable to push out anything not "shared" to a series of load balanced services - i.e. find the smallest thing you can do on a large scale that is not visually time sensitive and do it well, then put it behind load balancers - authentication, chat, UI responses (menus etc.). State always becomes an issue here but many times state isn't as necessary as it seems. Perception is the key concept here and it will be different based on the mechanics of every game but there are some general assumptions that will be made.   Physics and collision detection tend to be things that must be housed in an instance of a specific maximum number of players for example. Proper game design and level/area/zone distribution can do more good than innovative code in these areas many times. Distributing wealth, items, quests across a more vast landscape will allow things to spread out much more than if things are concentrated in certain places. An example of this is "the best x in the game" where "x" is something only found in one spot. If there can be only 1 then the goal of many players will be to acquire this item. If on the other hand, there are many balanced items etc. in the game, players will naturally be divided on which ones they care to quest for the most.   As a service provider, our company has many issues to overcome however uptime/availability and load distribution tend to be the biggest daily engineering feats we manage on a daily basis. I can only imagine that an MMO has similar requirements as they too are ultimately a service provider.
  10. First - good luck. I truly mean that and not in a sarcastic manner.   Any input I would have at this point in time would be pure speculation because despite the effort to be detailed about what you are doing, it is difficult to really grok what is going on.   I will suggest on a much more basic and probably unrelated level however that TCP is the way to go until you find it is not - and then check that again. I work in telecom where some people still believe everything must be UDP because "it is faster" when really there are only a few pieces that actually need UDP (RTP for example) where others are actually much less complicated and more scalable over TCP (SIP for example). Of course I am probably getting ahead of myself because I have to build massively scalable and redundant systems with load balancers etc. where none of this will matter to you but if I can help someone avoid the pain I feel every day because of myths and half truths it will be worth it.
  11. SQLite is a great tool to use as you migrate data from flat files. In fact I have been using SQLite for years for everything from config files to storing large data maps. There are so many tools for it and it is so light weight it is nearly as accessible as a human readable file but with a bit more kick.   That being said, and this is from my own experience - others may vary, just get your flat file data into SQLite however you find most intuitive to you (or your team) at first. In most cases the size of the data will be very small (relatively speaking in terms of DB performance) and the overhead of trying to learn SQL, Entity Relationships and all of the nuances of how to improve your DB performance are useless until you identify your database as being a performance issue. In many ways this is premature optimization. What you are doing is fine as long as you get the results you are looking for or at the very least get the same information you got out of the flat files.   Normalization of your database with foreign keys and foreign key constraints is tedious and time consuming to do correctly (once available the tendency is to lean on them which causes issues on it's own). Learning how to design, manage and run a database can ultimately lead you down a path to not completing your game. That is not to say time spent on learning the intricacies of database design, management and optimization would ever be a waste of time (I spend a lot of time doing this for work) however it will be a distraction from getting your game completed. Also in my experience, rarely has a database design been a bottle neck for any projects I work on until down the road when there are 1-3k+ users all adding and reading data at the same time. Granted the DB is almost always a bottle neck when we reach certain user thresholds or data sizes however at this point the applications are usually working well and the time spent on the database has more focus since the application has had time to mature and we know what kind of performance we are looking for.   I will repeat myself and say that overall I would do what is most intuitive for you and your game - especially if you are the sole developer. Database management has many religions and like any religion there are zealots who believe their word is Dogma and we all know how that turned out for Cardinal Glick. Once it is working for you the worst that can happen is you improve it.
  12. It may help to use something like collectd to throw various metrics you think are important at while your game is running at specific intervals while doing load tests. This results in some nice trends that let you make SWAGs about how your server should operate given a certain amount of hardware resources under certain amounts of load. Once you have some theories, establish ways to validate or invalidate them.   Every game server will have different requirements and different metrics it finds important but in most cases, being able to trend what is happening is required for any kind of trouble shooting or bench marking.
  13. Programming is a task. The language is a tool you use to accomplish that task.   Just like any task, there are many ways and many tools you could use to accomplish that task both correctly and in a timely manner.   For example - Should you learn to use a hammer or a nail gun first? It really depends on what the job calls for but you are probably encouraged to continue to learn about any tools that can get the desired result.   In our company we generally hire people who have demonstrated the ability to learn multiple disciplines even if the one we are looking for isn't their strongest one (so long as they are proficient in it). Learning something is never a waste of time. You know what you can do and what is comfortable for you. Some people can pick up complex languages with relative ease, others need to wade in. The thread has given many opinions from people who work in your targeted industry (or claim to at least). The choice remains yours in the end however and your success will ultimately depend on how much you are willing to change and adapt to the employment environment you are seeking out.  
  14. Media streaming in general is a relationship between sample size and playback rate so sending fixed sized packets at timed intervals is indeed the way to go but you have many more options when streaming music vs. streaming real time communications since music files are known in their entirety before transmitting.   Is streaming really what you want to do? There are plenty of streaming media servers out there to take examples from but for gaming I can't imagine why you would do this versus having the media pre-loaded or downloaded on demand unless you were mixing audio in real time.
  15.   Agreed.   Even a thin API wrapper between your internal applications and your database can be a positive thing. For the most part the main issues here are shielding yourself from malformed, incomplete and/or intentional malicious things - most notably the unintentional especially where quotes and special character escaping like $@!* are concerned. It is relatively simple to do since in most cases queries only require on a very small portion of information from the actual client side such as a function name and a date range or other criteria found in the 'WHERE' clause.   In most cases the only information a client should send is (authentication to your app server should be separate from the database login credentials and already complete at this point!) a few variables set to determine what function to call and the parameters it needs to reliably build the query server side. It is important to note that this forces you to an extent to validate the client requests and validity of their request before sending anything to your database and not rely solely on the somewhat lacking security features on various database engines.   This is not only ideal for security reasons but for maintainability. You can usually update/improve your query server side without having to update the clients in any way.