• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

184 Neutral

About PSvils

  • Rank

Personal Information

  • Interests
  1. What to do in a pirate game?

    An idea I'm trying to develop for my own game is having campaigns with generated elements. Placing specific characters somewhere in the randomly generated universe, and they each lead to the next, and event triggers etc. In the beginning of the game, you can choose a random starting quest, that is relatively short, but already takes you around the world a bit and through the main actions, like a tutorial quest, and gives the player footing in the world. During this quest you should hint at potential new leads to follow after the quest - this island is in trouble because of resources, a ship went missing, last seen at this port, etc., which also gives the player something to pursue immediately after the quest. So keep it open, you just need to lead the player into the openness, until they feel like the know enough about the world to make their own decisions. It's hard to have the same approach as Minecraft, because that requires meta-game aspects like a community making a wiki, etc., and reputation, for people to be willingly thrown into an unknown world. For typical idle activities you can start with trading. Then trade routes and island resources become objects you can have events / conditions around - pirates are raiding these mines, lowering the output, increasing the cost. That way a player who wants to trade at a good rate could get pulled into a series of tasks to improve their trading throughput. Then typical ship hunts / pirate hunts, simple exploration, mysterious ruins on islands. Lastly, if you build these systems in layers, you can end up with a very complex world emerging. Objects like mines, lumberyards, ruins, treasures are layered with actors acting on those objects, like traders, miners, indigenous populations, and then actors interacting with other actors. Properly define generalized goals for each, and hopefully an evolving world takes off. Putting campaigns in the middle of these circumstances naturally results in the player "discovering" obstacles. The campaigns can be simple enough, but put in a complex world, will have lots of depth.
  2. You could start by creating a system of information as data. If you can generate a list of properties about the location where the treasure is, as well about locations leading up to the treasure, you can just toss this information randomly around people in taverns, captains, in logs, etc., and it would be up to the player to find them, and connect these data points. I plan to work on a similar system for my game. But generalizing it this way, you can plant these data points in any number of ways or locations. Adding a bit of story padding / tying specific characters to specific pieces of data, you could potentially generate robust quests. I don't think it's convoluted, as long as the player understands the mechanics of finding the clues, and how to put them together. Because it's very indirect, the reward feeling could be really great.
  3. Just be sure to have a server handling client <=> database communication, that checks user accounts. You don't want to be shipping your database credentials in every game package ... Beyond that from your clients it'll be typical GET / POST requests or however you want to structure that.
  4. It's the exact same, so you'd have to give more details as to your specific case. If you work with pathfinding, using nodes is always the general case, a grid is a possible optimization / specific case which can improve parts of the algorithm using assumptions about the structure. Try to outline which parts you're having trouble with, all concepts should have a 1 : 1 mapping between grids and nodes.
  5. Especially since you were using Flash, I think Haxe will be above and beyond what you could find anywhere else: http://haxe.org/ http://www.openfl.org/ http://kha.tech/ http://armory3d.org/ The first link is the actual Haxe language website. It can natively target Flash .swf's, otherwise it can target many languages. The next 3 links are development frameworks based on the Haxe tech stack. OpenFL emulates much of the ActionScript 3 API, but important to note, it compiles native applications for desktops, mobiles, consoles, etc. Kha is similar to OpenFL functionality-wise - it's a framework that also allows exporting projects to WebGL, desktops, mobiles, consoles etc., but with its own API, which in my opinion is more intuitive and closer to libraries people coming from C++ gamedev would be used to. Armory3d is a 3d engine based on Kha for rendering. It has full Blender3d integration, so you can build your world and visually script from Blender3d, and immediately export to all the platforms that Kha supports. All in all, I've been using Haxe for years, only recently switching to raw C++, originally for Flash development, but later on for native desktop and mobile apps, and from my experience, for game dev, it really Just Works™. By now many issues have been smoothed out, and the same game can be easily exported to all targets. (Literally by selecting the platform from a dropdown menu - mind you, there is no VM, these are truly native applications)
  6. Boids, a way not to check flock every update?

    I'm simply talking about optimizing array comparison between elements, outside of any context. Think about it, if you have an array with length N, you only need to do !N comparisons, instead of N^N. [1, 2, 3] You have 2 loops, the first goes through each element, and an inner loop, which will compare this element with the other ones. If you start the inner loop at index 0 every time (as you are currently doing), you are comparing every single element twice instead of once. By visiting the first element in the outer loop, you will have compared that element to all other elements, which means when visiting the second element, the inner loop only needs to start with the third element, because comparing elements 1 and 2 already happened when visiting the first element. I just thought I should explain this because either you're not understanding it, or I don't understand the current code / logic you have happening. The example function I wrote WILL visit and compare all elements, except only once instead of many times.
  7. Boids, a way not to check flock every update?

    Not sure what you mean by loop unrolling. You're currently unnecessarily processing boid interactions twice, when you could visit each pair only once: void Seperation (float MaxDistance){ int TempInt = 0; //HiveMind is the parent of all the zombies while (TempInt < HiveMind.transform.childCount) {//So this will run once each child int SubCount = TempInt + 1; while (SubCount < HiveMind.transform.childCount){//The problem is now I need to run every zombie again to check there distance float Distance = GetDistanceOf(HiveMind.transform.getChild(TempInt),HiveMind.transform.getChild(SubCount)); if (Distance < MaxDistance){ AvoidFlockMember(HiveMind.transform.getChild(SubCount));//This moves away from the flock member. AvoidFlockMember(HiveMind.transform.getChild(TempInt));//This moves away from the flock member. } SubCount +=1; } TempInt +=1; } } But maybe I'm assuming incorrectly about how your code works outside of this function (for example how the AvoidFlockMember function works)
  8. Boids, a way not to check flock every update?

    FYI, you're inner while loop is infinite, I assume it should be: while (SubCount < HiveMind.transform.childCount){ And you should be reseting SubCount to 0 every loop. This will get you N^2 loops and distance calculations. An easy optimization is don't reset SubCount to 0, but set it to TempInt + 1, and then process 2 boids at the same time: AvoidFlockMember(HiveMind.transform.getChild(SubCount));//This moves away from the flock member. AvoidFlockMember(HiveMind.transform.getChild(TempInt));//This moves away from the flock member.
  9. BTW - Why is ObstacleManager a pointer in the PlayState? Make it a member variable and you don't have to worry about memory leaking.
  10. I think the main advantage of legs is also obstacle traversal, except with even better results. Flat or rough terrain don't make a difference / no penalties. Also with "gripped" legs you could have full-on climbing capabilities. Otherwise yes, they're fragile. Depends if you're thinking heavy mech type of legs, or more agile spider type of legs. Another possible advantage is that the load it can carry shouldn't affect it too much. Think of a robot with 8 legs, moving 2 at a time, while the load rests on the other 6. Only part of movement that would be affected by the load would be moving the body over to the 2 legs that just advanced, which could probably be less than wheeled vehicles, that constantly need to move under the weight.
  11. I like your last idea, by giving hints or pointers to real world objects instead of a direct path to the treasure. This makes it much more rewarding, and like a real task, otherwise traveling to the treasure and picking it up might just feel like an unnecessary hassle. But I suggest watching this video for a good analysis of a similar topic:
  12. These names do nothing to express the mechanics of each gun, or say anything about the attributes that actually make them awesome. With this question - what kind of feedback are you expecting / looking for? It would be more useful to ask a specific question, outlining more details on what it is you have, and need feedback on.
  13. Here are some real time audio frameworks that might be of interest to you: https://github.com/thestk/rtaudio http://www.portaudio.com/ And a synthesis library I just found: http://maximilian.strangeloop.co.uk/ I've given RTAudio a test run, and they have an example that sets up a audio stream callback, and generates a saw wave. This sounds like something you're looking for, and it's very straight forward to setup. Also is crossplatform.
  14. Game Engine Questions (ECS)

    "The system_manager object gets passed to onInitialize, onActivate, onDeactivate, and onDispose"   :) So yes, systems get references to the system manager.
  15. Game Engine Questions (ECS)

    By what is needed, I meant it passes a list of class references to its super constructor.   The system manager uses this list when you add the system to the manager, and checks to see if all systems in the list already exist in the system manager. If yes, it activates the system, if not, it doesn't. It rescans this every time you add/remove a system to the manager.   The system itself can only access the other systems through the system manager.   Systems being dependent on each other can happen for different reasons. A bad reason (one which I use though) is performance. Sometimes direct access to system specific data is faster, and easier. An example would be a PhysicsSystem and a BulletSystem. The BulletSystem would require the PhysicsSystem, and get a reference to it when activated. That way, it can directly do raycasts on the physics space within the PhysicsSystem, as opposed to somehow raycasting through creating entities and components etc.   It's both faster, and probably more understandable / debuggable.
  • Advertisement