Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

163 Neutral

About FFA702

  • Rank

Personal Information

  • Role
    Business Development
  • Interests

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I understand that. I don't know what the market value of your game is. You will have to research this yourself, probably mainly by looking at similar games and seeing how they're doing. Also, and I know this is hard, but you're not selling a game engine. You're selling a game to people who probably don't know what an "advanced custom engine" means. It needs to be reflected in advanced custom gameplay, and advertising your game as a game like minecraft but with smaller cubes and quests is a far cry from doing so. You need to detach yourself from the game and think about the person who you'll sell the game to, or you'll be stuck with an uncomercializable love project forever.
  2. On the subject of price, two advice (since I'm hearing stuff that is "academically" wrong). First, you definitely can price your product too low and lose sell over it. Second, don't ever price something based on the amount of work you put into it. Price something based on it's market value. I'll probably get a lot of shit for this, but people generally do not care about the work you put into something. The best way to go about this is to find who your client is and what he's willing to pay for the game (and this applies to anything, but first you need to know who you want to market your game to). At this point you're so far off the mark marketing wise it's probably useless to give you industry specific advices. Taking a day to do a video probably won't help much. Your next step probably consists of trying to explain your game to your target segments (if you don't have, just use random people, and start from there ). Then watch them play and take notes. Have a conversation with them. If that sounds awful and scary, it's because it is. But you must do this if you care about your project. Source: I'm 6 months away from having my B.B.A.
  3. Hi, I'm looking for advice/best practices/success stories to setup the simplest spritesheet animation and 2d art possible. I basically just want it to look decent without producing an incredibly high number of art. Currently my placeholder assets have no animations and are really ugly. Ideally I mainly want the player to be able to tell what the actors are doing (mainly if not exclusively walking and attacking, with no possibilities of doing both at the same time). Here are some requirements : Walk / Attack animation Not necessarily pixel art Must accommodate a basic wearable system (one item held in hand, wearable : pants, armor, helmet) Must be distinguishable from afar, and look engaging from up close (provided picture is the typical distance from which the game is played) Need to accommodate animals and creatures (minus the wearable) This is what I'm thinking about doing style wise right now (sketched this in about 15 mins) : Basically need advice to animate it on a simple spritesheet. For item I thought about simply layering them on top of this sprite (perhaps having a special sheet full of faces to further personalize the npcs). Anyhow, I am far from being an artist (hobbyist programmer, professional BA) and I'm at the point in development where I need to produce content.
  4. Though I might be mistaken, I thought Finite State Machine had the formal attributes of : Containing the code to change state within the states themselves Be strictly able to change state through pre programmed 'transition' Lack any kind of flexibility regarding on the fly behavioral changes When I hear FSM, I think about the following : (image from https://gamedevelopment.tutsplus.com/tutorials/finite-state-machines-theory-and-implementation--gamedev-11867 ) Wouldn't this be hellish to implement in OP's context, where he wants "to be able to as easily as possible add and remove these action for enemies and just as easily add new actions to the pool of available actions." My attempt to implement a finite state machine was a monumental failure. To be honest, anything more than 5 states becomes very hard to manage in my experience, and you will likely have to produce documentation in parallel to your code to keep track of everything. Just thinking about sitting down and drawing op's fsm is giving me a headache. Take my advice with a grain of salt, more so because Unity is bound to have tools to easily create and manage fsm, but from a C# coding perspective, I advice you to reconsider your options.
  5. I don't know of any tools that can get help you a 3d total war clone without touching code. Currently there are a number of free and open source 3D rts engine that you could use as a template to get going rapidly. The first one that comes to mind is Spring RTS. Developing a total war clone on Spring would feel more like modding a game than actually making a game, and making new units / buildings is fairly easy. Given your past experience, in 7 weeks of part time dev, you should be able to setup the correct workflow to start designing units, map and gameplay rapidly without worrying too much about the technical aspects. Note that you will have to code, but with the provided template, it should feel more like editing parameters than developing something. I think this kind of workflow is the closest thing you will get to a drag and drop experience. https://springrts.com/wiki/Gamedev:Main Every tool used in the the workflow provided in the tutorial is free and as bare bone as it gets.
  6. I have a similar problem for my game. Don't go with an FSM, unless you are ready to sink alot of time into writing or learning a dedicated FSM library. Your behaviors are way to complex and numerous to be implemented in a simple had hoc FSM, the code will end up harder to manage than a bunch of inline and nested if statements. I came up with an elegant and very workable solution, sort of my own interpretation of a utility style AI. First thing I did was to separate the AI actions from the AI behaviors (in this context behavior = decision making entity). Basically each AI units have a set of behaviors, which each have an evaluate method and a run method. At every N update, the AI unit will run the evaluate method for each of it's behavior, and will run the one with the highest score. The run method contains the rules to modify the action list of the unit. The action list is a queue of actions ranked by the order in which they get executed. An action might take any number of turns to complete or fail, and it contains the actual code that acts on the unit (move, attack, etc). Of course, the behavior can get instantiated for a particular unit with a multiplicator, which multiply the score of the evaluate method, which allows for fine tuning of behavior to make some units more aggressive than others. Also, just be clear, the evaluate method takes the environment and the state of the unit into account. For example, to evaluate the "heal self" behavior, the code would probably look like this: ( (unit.health.current - unit.health.max) * -1 ) + (distance(unit.position, player.position)) Of course you can get crazy and make all kind of weird functions to get the desired effect. This method allows you to write every behaviors only once and use composition to quickly make new mobs type. It also separate the actions from the decision, so a decision may result in a queue of actions. Multiple behaviors might share multiple actions. I don't know if this is the *best* way to do this, but it works pretty damn well and even I am impressed by how great it is.
  7. @unbird Thanks a bunch this was indeed the problem.
  8. FFA702

    Simple RayTracing Shader

    Simplest way to get into raytracing is with spheres and software rendering. I can't help you with compute shaders, but I wrote a software raytracer (sphere only) in C# with most of the features you'd expect (multiple light sources, reflection, transparent items) in about a day; takes a few minutes to get an HD image with 5 spheres in it. Anything more than drawing an handful of spheres will be a nontrivial challenge. Start here: https://www.scratchapixel.com/lessons/3d-basic-rendering/introduction-to-ray-tracing You need to know linear algebra (line/sphere intersection for sphere and line/plane intersection for anything else), that's pretty much it. If you're looking to write an actual realtime renderer, I can't help you and there are few who can.
  9. I've added a Gif of me zooming in and out to illustrate the problem. The memes are placeholder assets.To clarify the working of the draw loop, the 'adjusted zoom level' is the final size (h and w) of a tile. All objects are stored in a 2d array which represents their position. As such, dividing the length of the screen in pixel by the length of a tile gives the number of tiles to be drawn on the screen. This is the value (vP) I used to iterate trough my array. The viewPort is the position of the camera (an actual point in the array, right now stuck to the player) minus the size of the screen divided by two times the size of the tiles; this gives the top left tile to draw. The loop then simply iterates trough each tiles to draw. All variable labelled 'last' (such as lastViewPort and lastCamera) are just used in the lerp function to give the illusion of smooth transition between tiles. As of now, the program performs really well and fits every performance and stability requirement I have. It's just buggy on the zoom functionality. @arnero I think you might think I'm using cpp or some unmanaged language. Also the gametime is a feature of MonoGame, not my own code. @DerTroll It's done in C#, hence the style. I'm really sorry I didn't mention it, given the length of your reply dedicated to language specific features. About the problem being the engine's coordinate system; the point(0,0) is indeed the top left corned of the screen. This might have something to do with it, but I can't quite wrap my head around it given my current draw method. @Zakwayda I'll refractor and comment the code, then I'll post back. The single reason it's written that way is because I can quickly comment and edit chunk in and out. I realize I should have done that before asking help. Alright guys I've refractored and commented the code; this should be much much clearer : protected override void Draw(GameTime gameTime) { //The base ZoomLevel is 60 //The ZoomLevel is the lenght and widht of a tile int adjustedZoomLevel = 60 + ZoomLevel; Point tileSize = new Point(adjustedZoomLevel, adjustedZoomLevel); // DRAW THE DYNAMIC OBJECTS: //If the UI is focused, we draw the game grey Color spriteColor; if (UI.DisplayUI.isFocused == false) { spriteColor = Color.White; } else { spriteColor = Color.Gray; } GraphicsDevice.Clear(Color.Green); //We calculate the number of tiles to draw (screensize/ tilesize) point vP = new point((graphics.PreferredBackBufferWidth/ adjustedZoomLevel), ((graphics.PreferredBackBufferHeight / adjustedZoomLevel))); //We calculate the actual top left tile, which gives us the first tile to iterate trough point lastViewPort = GameZod.GameZod.Game.lastCamera - vP/2; point viewPort = GameZod.GameZod.Game.Camera - vP/2; spriteBatch.Begin(samplerState: SamplerState.PointClamp); for (int x = 0; x < vP.x; x++) { for (int y = 0; y < vP.y; y++) { //We iterate trought everytile present in the screen point pos = new point((x + viewPort.x), (y + viewPort.y)); if (pos.x < GameZod.GameZod.Game.map.size & pos.y < GameZod.GameZod.Game.map.size & pos.x > 0 & pos.y > 0) if (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y] != null) { //If the tile is whitin the map and exists //We calculate the position of the tile on the screen (top left) //The lerp function lineraly interpolates betwen t and t-1 to give smooth mouvements int tilePosX = (int)lerp((GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].position.x) * adjustedZoomLevel, (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].lastPosition.x) *adjustedZoomLevel, gameTimeElapsed / 500f); int tilePosY = (int)lerp((GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].position.y) * adjustedZoomLevel, (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].lastPosition.y) * adjustedZoomLevel, gameTimeElapsed / 500f); Point tilePos = new Point(tilePosX, tilePosY); //We linearly interpolate the viewPort mouvement between t and t-1 to give smooth camera movement //as the camera moves trough tiles in a discrete manner int camDifX = (int)lerp( viewPort.x * adjustedZoomLevel, lastViewPort.x * adjustedZoomLevel, gameTimeElapsed / 500f); int camDifY = (int)lerp( viewPort.y * adjustedZoomLevel, lastViewPort.y * adjustedZoomLevel, gameTimeElapsed / 500f); Point camDif = new Point(camDifX, camDifY); //we add the sprite to the spritebatch spriteBatch.Draw(GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].texture, new Rectangle(tilePos - camDif, tileSize), spriteColor); } } } //END DYNAMIC OBJECTS //INTERFACE BEGIN for (int i = UI.DisplayUI.UIDisplayList.Count - 1; i >= 0; i--) { if (UI.DisplayUI.isFocused == true & i == 0) { UI.DisplayUI.UIDisplayList[i].draw(spriteBatch, Color.White); } else { UI.DisplayUI.UIDisplayList[i].draw(spriteBatch, Color.Gray); } } spriteBatch.Draw(UI.DisplayUI.MouseTexture, new Rectangle(mouseState.X, mouseState.Y, 20, 20), new Rectangle(0, 0, 30, 30), Color.White); spriteBatch.End(); lastAdjustedZoomLevel = adjustedZoomLevel; base.Draw(gameTime); } float lerp(float p1, float po, float t) { return (1 - t) * po + t * p1; }
  10. FFA702

    Large Tilemap Storage

    I currently have a 100x100 tilemap with 2 layers (one for the tiles and one for the characters) I can draw at once with absolutely 0 performance issues. I think I can push 1000x1000 no issues (at this point they become individual pixels so wtv), modern rendering pipelines are really hard to bottleneck and a 60x30 array is trivial.
  11. Hi, I have a small annoying problem with my draw loop where the zoom function results in very noticeable jerking motion of all the rendered sprites. Here is the whole method and the lerp function : protected override void Draw(GameTime gameTime) { int adjustedZoomLevel = 60 + ZoomLevel; // DRAW THE DYNAMIC OBJECTS Color spriteColor; if (UI.DisplayUI.isFocused == false) { spriteColor = Color.White; } else { spriteColor = Color.Gray; } GraphicsDevice.Clear(Color.Green); point vP = new point((graphics.PreferredBackBufferWidth/ adjustedZoomLevel), ((graphics.PreferredBackBufferHeight / adjustedZoomLevel))); point vPo2 = new point(((graphics.PreferredBackBufferWidth) / ((adjustedZoomLevel) * 2) ) , (((graphics.PreferredBackBufferHeight) / ((adjustedZoomLevel) * 2)) )); point lastViewPort = GameZod.GameZod.Game.lastCamera - vPo2; point viewPort = GameZod.GameZod.Game.Camera - vPo2; spriteBatch.Begin(samplerState: SamplerState.PointClamp); for (int x = 0; x < vP.x; x++) { for (int y = 0; y < vP.y; y++) { point pos = new point((x + viewPort.x), (y + viewPort.y)); if (pos.x < GameZod.GameZod.Game.map.size & pos.y < GameZod.GameZod.Game.map.size & pos.x > 0 & pos.y > 0) if (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y] != null) { spriteBatch.Draw( GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].texture, new Rectangle( ((int)( lerp( (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].position.x) * adjustedZoomLevel, (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].lastPosition.x) * adjustedZoomLevel, gameTimeElapsed / 500f) - lerp( viewPort.x * adjustedZoomLevel, lastViewPort.x * adjustedZoomLevel, gameTimeElapsed / 500f) ) ) , ((int)( lerp( (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].position.y) * adjustedZoomLevel, (GameZod.GameZod.Game.map.Dobjects[pos.x, pos.y].lastPosition.y) * adjustedZoomLevel, gameTimeElapsed / 500f) - lerp( viewPort.y * adjustedZoomLevel, lastViewPort.y * adjustedZoomLevel, gameTimeElapsed / 500f) ) ), (int)adjustedZoomLevel, (int)adjustedZoomLevel), new Rectangle(0, 0, 30, 30), spriteColor); } } } //END DYNAMIC OBJECTS //INTERFACE BEGIN for (int i = UI.DisplayUI.UIDisplayList.Count - 1; i >= 0; i--) { if (UI.DisplayUI.isFocused == true & i == 0) { UI.DisplayUI.UIDisplayList[i].draw(spriteBatch, Color.White); } else { UI.DisplayUI.UIDisplayList[i].draw(spriteBatch, Color.Gray); } } spriteBatch.Draw(UI.DisplayUI.MouseTexture, new Rectangle(mouseState.X, mouseState.Y, 20, 20), new Rectangle(0, 0, 30, 30), Color.White); spriteBatch.End(); base.Draw(gameTime); } float lerp(float p1, float po, float t) { return (1 - t) * po + t * p1; } and the arguments for the Draw function is : (Texture, Destination rectangle, Origin Rectangle, Color); this is done with MonoGame (XNA) The zoomlevel is changed in increment of +-1. I really think the problem is contained in this method, everything is perfectly fine, but zooming shifts the position of the screen to the upper right and then clamps back to the lower right, ever shifting up until it clamp back down again. What I've done : Ruled out the fact that it's tile based and may shift everytime new tiles enter the frame Tried to calculate the delta between the last zoom and the current zoom in terms of the rectangle's position, then subtracting it from the position Isolate the problem to a particular function 'center' the coordinate system more accurately to the center of the screen; this has no effect on the issue I really hope it's just something really obvious I missed, spent 6h on this and made 0 progress.
  12. FFA702

    Pathfinding (I'm lost)

    It seems I fixed the weird behavior by subtracting the distance between the evaluated tile and the start tile to the tile cost function: consideredAttachedPointWeigh[i] = (evaluatedPoint).ManhattanDistance(goal) * 2 - (evaluatedPoint).ManhattanDistance(start) ; If anyone knows what algorithm this is, please tell me (I wrote it from scratch by intuition, but I'm sure it's already named). So far it works very well for every use case that randomly came up, haven't tested edge cases yet. I'll keep the thread updated if anyone is interested. It's really fast and it works.
  13. FFA702

    Pathfinding (I'm lost)

    Yeah I thought about it, but I want the game area to be as dynamic as possible. On another note, I just tried to write my own pathfinding algorithm and I think I failed spectacularly. The failure comes from the fact the algorithm thinks it's sometime cheaper to go away from the target in one direction even if it's hugging a wall to advance (it might in the case the wall is L shaped and will block it's path). I think I'll ultimately have to try A*, hope it's not *that* slow. Here's the failed code if anyone is interested (I think I'll call it 'Naive Search') public List<point> gridSearch(point start, point goal) { bool[,] visitedNavGrid = new bool[Game.map.size, Game.map.size]; point currentPoint = start; List<point> chosenPath = new List<point>(); int[] consideredAttachedPointWeigh = new int[8]; point[] attachedPointPlan = new point[8] {new point(-1,-1), new point(0,-1), new point(1, -1), new point(-1, 0), new point(1, 0), new point(-1, 1), new point(0, 1), new point(1, 1) }; //Array represents the 8 possible movement option vector from the point c //0 1 2 //3 C 4 //5 6 7 //int lastDirection = 0; chosenPath.Add(start); //The actual algorythm while (chosenPath.Last() != goal) // Until a path is found or no solution is found { for (int i = 0; i <= 7; i++) { int stuckTreshold = 0; point evaluatedPoint = chosenPath.Last() + attachedPointPlan[i]; //check for obstacle, or if the grid has been visited if (Game.map.Dobjects[evaluatedPoint.x, evaluatedPoint.y] == null & visitedNavGrid[evaluatedPoint.x, evaluatedPoint.y] == false) { consideredAttachedPointWeigh[i] = (evaluatedPoint).ManhattanDistance(goal); //The larger the worst } else { consideredAttachedPointWeigh[i] = 1000000000; stuckTreshold++; } if (stuckTreshold > 7) { //The agent is stuck; a contingency should be planned (rn it goes back to it's original pos) List<point> reversedPath = chosenPath; reversedPath.Reverse(); chosenPath.AddRange(reversedPath); return (chosenPath); } } int direction = Array.IndexOf(consideredAttachedPointWeigh, consideredAttachedPointWeigh.Min()); chosenPath.Add(chosenPath.Last() + attachedPointPlan[direction]); visitedNavGrid[chosenPath.Last().x, chosenPath.Last().y] = true; } chosenPath.Remove(chosenPath.First()); return chosenPath; } } } What's interesting is the solution to fix this would be to store each visited tile in a tile structure and then find the shortest path within the structure, which would be remarkably similar to A*.
  14. FFA702

    Pathfinding (I'm lost)

    I haven't tried anything yet, I don't want to lose time on a lost cause. I have no idea what I'm doing regarding path finding. Everything should be done in a single tick to ensure the 1000 archer method will work for future network implementation. Also the map changes every tick, but only because mobs may change position every ticks. The map is technically updated anytime something changes, since it's the container of these things. And I don't update the game at max speed, so it doesn't update 100 times a second, right now it is rigged as a turn based thing so it's updating every time the player has finishes his actions. Later I plan to make it real time, but not with a 100 times a seconds update rate. The end goal would be to port the game, which is now contained in a C# library, plugged on a console for output, to a proper game engine to take care of graphics, inputs, sounds, etc (ofc the update loop will run async to the draw loop and the input system). I've found multiple article on the method, it looks promising. Can you point me in the direction of an implementation directed to game implementation. Also, I need to avoid multi threading and floating point operation as much as possible to keep each game tick completely deterministic.
  15. I'll jump straight into the context: I have a 2D grid map stored into a simple 2D object array. Every object and agent exists on this 2D array (so their positions are discrete and binded to their location on the array). I'm expecting agents to move quite a bit, so the grid is dynamic in nature. The game itself is fully deterministic and discrete operations based, the goal being to make it multiplayer portable (with the lockstep method). I'd like to populate the map with large impassable structure, concave and convex, such as buildings and lakes. These agents are rigged with an FSM for decision making. I wish them to be able to act on these decision in believable way, and one of these challenges is to allow them A > B navigation that works and looks believable. I'd like to have as much active npc in the world as possible, and right now the biggest hurdle is finding the right path finding algorithm. I'm not sure about my update tick budget, but right now I'm thinking anything reliably less than ~500ms would be acceptable (I'm making the game "turn based" for testing purposes, and wish to later make it real time using a good amount of linear interpolation on the display layer). At this time I have a 100x100 map for testing, with hundreds of agents (with almost fully implemented AI, lacking path finding and collision detection), and a tick time of 10ms. What pathfinding algorithm and implementation would suit this situation ? I know A* would be okay-ish, but since the grid changes every ticks, and the number of agents is quite large, I'm not sure it would be the best (short of computing the path once and evaluating if a collision occurred each travelling steps, then recomputing it). I'm trying to keep everything simple, and I am willing to reduce the scope of the simulation regarding the number of active agents to do so. Any idea or advice ? FYI, I'm not sure if I'm doing this right, but every agent has a command list, which contains a list of "todos" populated by the fsm and ran each ticks (the first command in line). The pathfinding algorithm would be contained in the command object, so the flexibility is quite large (it could be broken down into smaller steps).
  • 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!