SotarOraiste

Members
  • Content count

    22
  • Joined

  • Last visited

Community Reputation

3 Neutral

About SotarOraiste

  • Rank
    Member

Personal Information

  • Interests
    Business
    Design
    Programming

Social

  • Twitter
    sotaroraiste

Recent Profile Visitors

366 profile views
  1. Weird fears?

    Not always but time to time I mix dream and reality in a sense that it's always about me trying to avoid dying , something like I woke up during a dream and do something extremely stupid for anyone that might watch ( something like if I don't hold "this rope" with tension and stay in a certain posture, I'll die ) and maybe just maybe I don't do it whole night Beside that, I'll never understand people not having fear of height, isn't it supposed to be a survival instinct? I hate and panic when other people walk near cliff / stairs etc , not to mention myself.
  2. my personal future in game programing

    I see no point in blaming location alone ( hello from Turkey ) I think it would be wiser for you to work on a project of your own that you can monetize somehow, either a web or gaming venture. You theoretically need no more than a computer at the beginning and there are always chances of investment if idea and execution are solid. If assets will be problem both cost and skill wise for a game, you can still consider one with stock and simple graphics. ( A game with style of Crossy Road for example can be done virtually skill free ) . Or once again, you can consider of a web based business not necessarily about gaming. Check market for any niche opportunity that can be monetized with a rather solid business plan and channel your Thu'um / skill into it.
  3. @Kylotan Thanks for response, although I'm not big fan of Postgres (without a solid reason) , will check JSONB how well it fits. By luxury, I hadn't mentioned use cases where transactions are made of such as " player transactions " as you mentioned but common ones such as " Update whatever of Player by some value to player table - Log a log regarding it to logs table " where a transaction isn't fundamentally needed but laziest way to ensure that all data needed for any action is stored. Because otherwise there might be discrepenancies between logs ( which are supposed to reanimate whole game history somehow ) and actual data. As mentioned enough times by everyone , I don't think DB will have difficulty with processing all but still not happy of absence of a more elegant solution
  4. Hello there, Thank you all for insightful responses. I evaluated it as I told and yes I came to the same conclusion that a simple setup of memory and single database is just fine. (Just that moving old logs from main database to a dedicated log database time to time might be needed) And yes, there is no crucial need for a GraphDB for graph related features, it can be handled programmatically. Just that I still couldn't decide between using a document store or a RDBMS one. I agree with ApochPiQ about persistent data can even be file based or memory dump but I prefer that data to be queried A JSON document still makes more sense to me than relational databases because it's a design choice better tailored for gameplay, although it can be handled by a RDBMS using enough number of tables and JOINs , at the end most data will reside in memory ( mostly beside transactions on database site ) so a JSON document might even be easier to "deserialize" as key value pairs. I know that most people aren't that adventrous due to experience, still wondering your opinion on if it is never-ever or a design choice Thanks in advance. PS : Is using transactions all the time an expensive luxury due to laziness or simplest way to ensure that data will be consistent (aka logs and CRUD queries are executed in sync)?
  5. Ok o7 , will evaluate whole structure to come up with a solution not overengineering and overcomplicated without a good reason. Thanks for responses.
  6. @ApochPiQ Glad gentleness is the air. My understanding of serialization was like Wikipedia definition of "Serialization is the process of translating data structures or object state into a format that can be stored (for example, in a file or memory buffer ) or transmitted (for example, across a network connection link) and reconstructed later" . Sorry if term wasn't right but by "SQL serialization" I was mostly meaning structuring tables. From that POV, a pseudo JSON structure such as { "id" : 3289723498, "name" : "whatever", "level" : 216, "weapons" : { "sword" : { "stat" : "blabla" , "stat2" : "blabla2" }, "axe" : ... }, "inventory" : { .... } , .... } looks more manageable to me ( with a trade-off of storing repetitive data ) than a SQL JOIN fest, but as I said I may be wrong. ( I at least tend to believe it's a design choice rather than a "never-ever" but I can be still be very wrong) My primary reason to use a GraphDB is Floyd-Warshall / Dijkstra for "spatial" data. If I decide to use a relational database, I ofc either limit it to such functions or switch to a node module one. My current point is as "if JSON structure fits to my purpose , why not use single solution for both?" And ok, it ofc makes perfect sense for "game server software" (which is Node.JS based as this is a browser game) to handle data in memory. Although I didn't make a thorough search, doubt Node.JS (V8) shines in memory management / garbage collection as much as your beloved ( C ? ) choice. And considering Redis is a " in-memory data structure store " , I see no harm in using this key/value store for storing data in-memory as long as crucial performance hits don't occur in comparison. Still, I got the part that using single database is cure of all evils and it rather becomes a question of how you store data after that. Thanks for your response, it has merit indeed.
  7. @frob Fair enough, will check literature @Kylotan Still didn't get why Redis can't be that in-memory state in form of key/value pairs, tbh. And for GraphDB, it's not a sole GraphDB such as Neo4J but a "multi-model" one which actually means a documentDB where vertices and edges are in different collections when you need graph functions, so it also have document storage uses , otherwise I'd use a solution like you mentioned. Can this data be serialized? Probably to a great extent but I find a documentDB more logical for a game, maybe I'm wrong
  8. In my case, a graphDB is needed for where graph shines most ( shortest path or graph traversals ) so some of data must reside in it and some data which is perfect use case for relational one must be in RDBMS. Pity graph data is unable to be serialized efficiently.
  9. @Kylotan I think what is generally suggested ( that database is authoritative and redis is cache layer ) is contradicting your quote which made more sense to me. But still I evaluated options and came up with a solution of using them "where they shine most" ------ So due to GraphDB limitations, will use memory one as main authoritative database and Redis as cache ( unless there is a use case using Redis makes more sense to prevent unnecessary workload or bottlenecks ) and there will be a database both for logging + some aggregated data. Is this good enough? ------ And when using two different databases is a technical necessity, what would you recommend for consistency? I thought of using a query queue for both databases and a timestamp to track so if there is an inconsistency one of databases might rollback (but actually not sure if it's doable)
  10. @Alberth Thanks for reply. Actually one database might handle issue effectively ( just stumbled upon https://engineering.hipolabs.com/graphdb-to-postgresql/ ) but that's another aspect of issue when model is simplified to two databases ( Redis and X ) My interest for Redis is not about performance but handling issues that doesn't need frequent write ( for a classic MMO, it might be player location or hit point in the middle of battle ) As I said I'm also not happy with too much moving parts (which is more error prone) so trying to find optimal solution.
  11. @Kylotan Thanks for reply. Although I agree mostly with your view, a single database solution isn't necessarily best practice in my opinion. But quoting from you from another thread ( of https://www.gamedev.net/forums/topic/686334-mmo-database/ ) , I think this approach is quite applicable. So, when everything is fine Redis/in-memory one is authoritative and other database acts as an eventually consistent database as save game data ( aka snapshot ) . When there is some sort of reboot or failure, this save game DB is authoritative (as in-memory data is no more obviously) and data is just copied from other db to redis. I'd love that in-memory and persistent databases are same so it's fine but not really sure of handlings issues that might arise otherwise. And for prior schema, actually it can be simplified as only in-memory and persistent databases. What would best practice be in case of you can't have " one single database to rule the universe " ? Would it need something like a monitor checking all databases with timestamps?
  12. First of all, thanks for replies. @frob And I know it doesn't look like but this is simplified model as, 1 - Need Redis for fast paced transactions and some scheduled tasks, 2 - "Snapshot" Database is needed primarily for its graph features 3 - "History" one is probably RDBMS as aggregate functions are common. 4 - Log / Analytics are rather off topic so plain text is ofc on the table I'm not happy of having that much moving parts, that's why trying to reconcile them And "failure of any kind" is a bit overstatement At least when server had somehow managed to crash ( not much to do if server explodes after all ) or so ( common risks ) @Alberth Well, I'm rather newbie in this as well. Actually my concern is when there are several databases from different technologies, their response to a failure would be different. If not configured to take snapshot, Redis data will be gone, some will use wall ahead log etc. Just I need a way to ensure that they all reverted back to same point
  13. Hello there o/ , I've started working on a browser game and trying to figure out database structure but my problem is I somehow managed to get a structure but not sure if makes sense and if it does how to handle consistency across several databases of different types. There is a schema that I hope it makes sense According to current plan, Memory database (Redis) : It will be database where main action takes place due to speed concerns. Snapshot database ( an in-memory persistent database featuring more than key/value pairs ) : This is the database only storing data memory DB will need in case of a rebuild and as name implies snapshot of current data. It's eventually consistent and in case of a failure it's authoritative. History database ( probably a RDBMS ) : This database is for storing history data that's relevant to players ( No point in storing that Player345278 has achieved level 28 ages ago in an in memory database) , for data they might need to see one day ( in fashion of ancient tweets ) Log database : As name implies it's for storing logs of any kind ( Once again no point in storing that Player345278 has killed a chicken ages ago if player won't need such data ) Analytics database: It's a server side tool to mine log data for fraud and behavioral pattern etc issues. In current plan, there are writes to several databases in each action (which is heart breaking) for example, Player finds 100 golds : memory one changes total gold, snapshot one also makes change, log one logs a log, history one is also updated if needed ( such as daily gold finders table ) Question is : 1 - Is there a better alternative in your opinion ? 2 - In case of a failure of any kind , what's the best way to ensure minimal loss of data? Should it be like snapshot is authoritative so memory one copies all from it , then logs before latest timestamp of snapshot is deleted , and have no good idea for history ? Thanks in advance.
  14. Hello there o/ , As I need a viable solution for rendering assets server side for a browser game, I evaluated options. Using client side canvas fallback was unwise due to performance issues for devices with already limited processing power , when checking server side I noticed chromium headless, gecko headless or phantomjs might help but I have concerns of reliability. So I found out that bgfx supports webGL 1.0 and webGL 2.0 rendering ( in the name of openGL ES apparently if I'm not mistaken ) so I wondered if having a C / C++ based service for serving prerendered assets ( hoping that I'm not swimming in Dunning-Kruger ocean ) would be a good idea. So I'd ask if using bgfx is a good idea or would you ( / @hplus0603 ) recommend another library for a service like Imvu Next's akamai hosted renderer for images like ( just googled )
  15. Any hope for Indie developers?

    Although people may earn money from games they throw up while making or selling, I think pleasing crowds no longer works because that market especially casual one is quite saturated. I'm not saying make yet another Europe Universalis but not Frappy Bird either.