Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About SotarOraiste

  • Rank

Personal Information

  • Interests


  • Twitter

Recent Profile Visitors

947 profile views
  1. SotarOraiste

    webGL webAssembly roadmap

    Hello there, For a browser based project, I'm interested in having a solution ( probably not me but by someone ) to be developed in C++ to be available via webAssembly as I expect better performance and a better footprint. As you may know webGL 1.0 is based on openGL ES 2.0 and webGL 2.0 is based on openGL ES 3.0 . Therefore which 3D libraries/frameworks (low level and high level) would you recommend as starting point that are, - Mature and maintained, - preferably with small footprint, - supporting openGL ES Thank you
  2. Oh! I had read it here @ https://medium.com/@mwichary/what-i-learned-about-languages-just-by-looking-at-a-turkish-typewriter-fc840aab1b0a but yes apparently QWERTY predates DVORAK
  3. Well, considering that QWERTY layout was actually designed to slow down typing ( as DVORAK layout was locking typewriters ) , AZERTY may not be that bad :)
  4. SotarOraiste

    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.
  5. SotarOraiste

    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.
  6. @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
  7. 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)?
  8. Ok o7 , will evaluate whole structure to come up with a solution not overengineering and overcomplicated without a good reason. Thanks for responses.
  9. @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.
  10. @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
  11. 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.
  12. @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)
  13. @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.
  14. @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?
  15. 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
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!