Kylotan

Moderators
  • Content count

    13644
  • Joined

  • Last visited

  • Days Won

    3

Kylotan last won the day on June 23

Kylotan had the most liked content!

Community Reputation

9599 Excellent

About Kylotan

  • Rank
    Moderator - Scripting Languages and Game Mods

Personal Information

  1. until

    This event is actually not going ahead this year.
  2. You're going to need to be more specific about what you're doing and why. If you just want to start something after a period of time, you don't usually need a thread or a timer; just take the current time, add on the period, save that somewhere, then keep checking regularly whether the current time has reached that saved time.
  3. First, doing a complex query is not a problem providing you understand how to perform that query and it's not being performed super-often. Whatever DB structure you can come up with for your game, there are 100s of businesses that do more complex queries 10x as often as you would, and it works fine. Second, you don't need to be doing most database queries during gameplay anyway. You can do them at load time. The chance of you having too many skills and abilities to fit in memory is zero.
  4. People are welcome to use the forum to seek help, but posting multiple threads at the same time on overlapping topics is the wrong way to do things. It means that anyone who wants to help has to try and follow each of those threads to understand what is being attempted. I appreciate that it can be frustrating when you're keen to make progress on your program and you have a lot of things that you want answers for, but the best approach is to post one clear thread, wait for the responses, act on them, and repeat.
  5. You need to be more clear with the problem you're facing. What does the code you posted do? How does the output differ from what you expect?
  6. The state machine needs to contain the conditional transitions as part of each state in which they're relevant. For the current state - whatever it is - there are probably only 2 or 3 possible transitions out of it. Either the animation finishes normally, or a button is pressed and it transitions to one of the other states. A brief analysis of your situation suggests you have these states, each corresponding to 1 animation: Idle (loops, can transition to Run Right or Run Left) Run Right (loops, can transition to Idle or Turn Right to Left) Run Left (loops, can transition to Idle or Turn Left to Right) Turn Right To Left (one shot, can transition to Run Left or Turn Left to Right (maybe starting partway through)) Turn Left To Right (one shot, can transition to Run Right or Turn Right to Left (maybe starting partway through)) Each state only has 2 transitions, so the conditions aren't that complex. The only awkwardness is being able to bail out of a turn half-way through, but if your turn anims are closely matched, you can ask to transition to a specific frame of the next animation in order to perform the change smoothly.
  7. Usually with an online game, you don't need to "download" the game data, because the actual game which uses that data is running on the server. Each player just has a client application which provides a view of the running game. It's just like this website - all the data for the threads and the users is stored on the gamedev.net server, and you just use your browser to see pages that the site sends you. How to update a game that is running is a complex process and there's no simple right or wrong answer there. If you structure the data and code well, then you might not need any patches at all, again just like you don't need to update your browser if a website changes its articles or layout. It's certainly possible to send data to a client when it's needed instead of up-front in a big patch; but if the data is large, you can't send it only at the moment the player needs it, because it would take too long and hold up the game during play. So these are considerations you would need to weigh up.
  8. The cloud is just someone else's computer. So when you say "keep gameplay data in the cloud" what you're really referring to is what we mean when we say "store data on the server". Almost all MMO data is stored on the server - the player's computer usually just holds data needed for display and audio purposes, such as graphics, animations, sound effects, music, etc. The main gameplay data such as weapon and skill info has to exist on the server anyway, because the server has to run the game rules and decide who wins and loses (etc). And often it's not desirable to send it to each player because then a cunning player can examine their game data files to discover weapons and skills that they haven't yet uncovered in the game. However, it is often still necessary to send patches to clients when server side data changes, for several reasons: maybe the code needed to change to accommodate new data maybe the client-side data references server-side data in some way and those references need updating maybe the data needs caching on the client for performance reasons
  9. Daryn, your 2nd question probably needs a new and separate thread as it's not really related to the first. Bear in mind that it's rarely practical to open a "studio" unless you already have money to pay people, which means you'll have already had a job, which in turn usually means you have to solve the initial problem first, i.e. "what should I do or study in order to get the job I want".
  10. SDL is just a library - if you want it working on different platforms, you have to set up the toolchain and the library on each platform. .io style games are neither particularly complex to create nor particularly lucrative to run so it's not surprising that there isn't a big software ecosystem there. People have made open source versions, such as https://github.com/huytd/agar.io-clone and https://github.com/OgarProject/Ogar , and they just use fairly standard event-driven networking tech because there's not much else to implement, to be honest. Implementing the client-side is another matter entirely - because the game is so simple you have a lot of latitude to use whatever technology you want, and there's no point it being tied to the server-side technology. The question of how to avoid needing to write Javascript in order to write game code for a browser is really a separate one - various engines and technologies compile to HTML5 these days, including Unreal, Unity, Haxe, anything that works with Emscripten, etc.
  11. Game developers use licensed engines for the same reason I use a web browser made by someone else. It's faster and easier if someone else has already done the work. In theory I could code up a functional web browser and it might even work better for me in some ways but why waste that time?
  12. Luke, you're going to have to word that question more clearly - and ideally, start a new topic for it, unless it's directly related to the original post here.
  13. Other general comments: don't do `delete this`. That is just asking for trouble. Objects should be destroyed by their owners. Your test.set_animation call is completely dangerous because you pass a pointer to a local variable. That means the pointer is completely worthless once the KeyUpEventHandler function returns, meaning you are likely to see a crash. Exactly the same applies to the AddObject call below that. you don't really need the x, y, w, h AND the rect - they're both the same data, right? your _destroyed variable currently serves no purpose - if you've already deleted an object, then it is completely destroyed - there is no point trying to read it to see whether the object is dead or not. That value may not be correct, and it may not even be in memory you are allowed to access any more. This is why you need to have an object's owner destroy the object.
  14. No, I think it's quite clear that Avalander's description fits pretty much every common source control usage. In fact, it could be argued that a true distributed source control model might not actually have a 'master' source copy, since each copy is essentially equal. Don't get confused by the Git references and the fact that Git is a distributed source control system - if the main shared copy of the code lives on Github.com, that's practically no different to having a CVS or Subversion server somewhere. Coders connect to the server, pull down the files they work on, edit them, and push them back to the server. Git (like Mercurial, etc) just offers more flexibility in that every repository can act as a server if necessary.
  15. So, don't do that. The real game state is what you need to save, so don't change that. Change the visual state, which you don't need to save. These should be 2 separate pieces of data. You don't need to have a single "coordinates" variable which you use for everything. I'd say that this is a problem with the way you are handling the logic. If you know that moving from field 1 to field 8 is a single operation, then you can determine right at the start that you will pass through field 4 and that the character is going to fall in. You don't need to animate them over that position to determine that. Your game rules should know that, at the end of the turn, that character has gone, and that the animation is just for effect. But, if you truly can't handle this without animating the character and seeing exactly where they appear in pixel-space, then maybe your tiles aren't really the true game space. It would be wise to think deeply on this before you proceed because it will have serious implications for the rest of the game. If you do need this finer level of control then your game state may well be at the visual/pixel/world position instead; in which case, you go down the RTS route, storing the command alongside the unit until the unit finishes moving. But I suspect that is not actually what you need. Exactly, but you're thinking about it the wrong way. The data isn't divided up by "what is serialised" vs "what is not serialised", the data is divided up by "what is an essential part of the game state" vs "what is just changing temporarily to make the game look pretty". You always save the first set of data when you're saving the game state, because it's essential for recreating that state when you resume/load the game. You don't need to save the second set of data because its current state has no effect on play.