Ed Welch

  • Content count

  • Joined

  • Last visited

Community Reputation

1008 Excellent

About Ed Welch

  • Rank

Personal Information

  • Interests
  1. Improving Interrupts

    Any action taken (moving one square, or taking a shot) reduces the counter by one.
  2. Improving Interrupts

    Most squad based games have an interrupt feature that works as follows: During your turn you can arrange it that some of your soldiers don't use up all their action points - leaving enough APs for a "reflex shot" and facing them in the direction of the expected enemy assault. Then during the enemy's turn, if an enemy soldier moves within the range of you soldier it may, or may not trigger an "interrupt". If the interrupt triggers, then the enemy's turn is interrupted and it becomes your turn temporally, you can shoot at the enemy, or do any other action until your APs run out, then the enemy's turn continues. The problem with this is that the interrupt only triggers, based on a random throw of the die (that is for the case of the original X-Com game and Jagged Alliance 2). When you position your soldier for the interrupt, you are putting him in a vulnerable position and if the interrupt doesn't happen (because the random die throw), then your soldier is almost certainly going to get pummelled. For that reason when I was playing X-Com, I almost never tried to get interrupts, because I didn't like the idea of my soldier randomly getting shot to pieces based on a die throw that was completely unpredictable. So, for Merc Tactics I have being working on ways of "solving" this problem. This is how it works: There is no die throw, instead there is a "counter" which starts at number depending on the soldiers interrupt skill. During the enemies turn each time an enemy moves within the soldiers arc of fire the counter goes down by one. When the counter reaches "0" the interrupt is triggered. In the screen shot below, for example, you see an arc of fire drawn on the ground with the number "3". 3 is the number of times that the enemy can move within that arc before the interrupt is triggered. Now the interrupt is triggered: Once the soldier shoots or moves the counter goes back to the original setting, otherwise it holds it's value. So, if the counter didn't hit zero in the first turn, you could keep the soldier where he is and try to get the interrupt in the second turn. This scheme removes the random element and provides feedback to the player, so they always know the likelihood of an interrupt occurring.
  3. This is how you do it: void VertexBuffer::CreateConvexHull() { btConvexHullShape convexHullShape( m_pPositions->GetVertexData(), m_pPositions->GetNumVertices(), m_pPositions->GetStride()*sizeof(float)); //create a hull approximation convexHullShape.setMargin(0); // this is to compensate for a bug in bullet btShapeHull* hull = new btShapeHull(&convexHullShape); hull->buildHull(0); // note: parameter is ignored by buildHull btConvexHullShape* pConvexHullShape = new btConvexHullShape( (const btScalar*)hull->getVertexPointer(), hull->numVertices(), sizeof(btVector3)); m_pDynamicShape = pConvexHullShape; delete hull; } Note: btShapeHull is a class to reduce the polygon count in btConvexHullShape (otherwise btConvexHullShape preforms very poorly) Also note: some extra padding is created around the object, for unknown reasons and that makes them seem to float a bit above the ground when they are dropped. Setting the margin parameter to zero won't work, because that parameter is actually ignored. That's why I call convexHullShape.setMargin(0); before creating the btShapeHull.
  4. I was just looking at a video that explains some of the new features in AMD's Vega GPU (https://www.youtube.com/watch?v=V9yTlRlxSVc). I couldn't quite figure out how the "High Bandwidth Cache Controller" worked. I'm assuming that the game developer has to specifically mark the assets as controlled by HBCC for it to work. From then on the GPU and driver handles loading and allocation on demand. It seems like this is very similar concept to "mega-textures" except that it's controlled by the hardware.  
  5. Ok, thanks for the answer. So that sort of rules kickstarter out of me anyway ;) The Reddit advertising sounds interesting though. If I put the advertising on a forum of a game in the extact same genre as my own then I have the perfect audience. But spending only $100 really gets results? That sounds kind of low.
  6. so, you think it's a good idea to do a kickstarter, even if you don't need the money, just because it creates exposure for your game?
  7. Alright. I guess I'll just have to live with it then ;)
  8. Video headaches

    I had really an awful time trying to put together a decent trailer video for the demo that I just released. Apart from all the trouble I had trying to figure out how to use various video editing tools, the quality of the uploaded video on youtube seemed very bad compared to what it should be, so I did some screen captures and compared the result side by side. What I found is that youtube used SD (i.e. low quality) by default, which is very bad. You have to specifically select HD from the embedded youtube video to play HD quality, which few people actually do. But even youtube HD is pretty poor quality. You notice in the image above the colours look washed out. The soldier in the middle looks like he is in black and white. Vimeo has better quality as you can see, unfortunatly vimeo can't be played in full screen mode in these blogs. Still, I'll take it. After spending so much work getting the graphics just right, the last thing I want is youtube crappifying my game trailer.
  9. I tried embedding a vimeo video in my blog post but it is missing the fullscreen button. The way the blog post seems to work is that is only accepts the link. You can't enter the needed allowfullscreen attribute to get it working. Anyone have a solution?
  10. Merc Tactics Beta 0.5

    Hello All, Today I have prepared a special version of Merc Tactics for game play testing. You can download the installation program here: http://astronautz.com/MercTactics/MercTacticsSetup0.5.exe Recapping, Merc tactics is a turn-based squad tactical combat game, similar to games such as Jagged Alliance, Silent Storm and X-Com. Below is a sample video of the game: https://vimeo.com/205212576 I am inviting people on GameDev to try out the game and give me your feedback. Specifically, I'd like to know if you found the game too hard to play, too easy, or too tedious, or if you have any ideas of things that are missing to improve the game play. You can have some fun playing the game and also participate in the development process! The game has two modes: Quick Battle and Campaign. For this test I am only testing Quick Battle. When you launch the game, you will see the main menu, as shown below: Choose the desired battle and select "Launch" to start the battle. You probably want to select one of the easier ones, until you get the hang of it. Also, selecting "Extra Enemy" will mean there is a three way battle with two enemy militia groups, all fighting each other. Selecting "Allies" will include a friendly militia fighting on your side. Online help is available here: http://astronautz.com/MercTactics/help.html. Requirments: This game requires OpenGL version 2.1 or higher, so it should work on most PCs. Notes: This game is more focused on making use of available cover, and close-in fighting, rather than long range sniping. Each scene requires a different approach, depending on how it's laid out, and as all scenes are generated procedurally, that means there is a huge variety of battles. Although this game is inspired by Jagged Alliance it, it does not try to copy it. Notably, I designed the game rules and mechanics with simplicity in mind, so as to be easy to play on tablets and smart phones. My design criterion was to only include features which made the game genuinely fun to play and eliminate features that just add complexity for complexity's sake. That being said, there still is a lot of features that are missing, because I simply did not have the resources to include them in "version 1.0". You can look at "version 1.0" as just the beginning. Version 2 and 3 will add the missing features and greatly expand on this game. This is a beta version, and you may notice some rough edges. Particularly, the user interface and some of the graphics have yet to be finished. Do not worry about these things, because right now I am only testing the game play. In this demo you can in fact play Campaign mode, if you want to. Although it's not finished yet and there is no help documentation for that. :o Update: I had to change the video, because of youtube quality problems.
  11. Using perlin noise to generate scenery

    Thanks very much. Unfortunately, I never took a screen shot of the first version :(.
  12. Using perlin noise to generate scenery

    All scene's in MercTactics are generated randomly. Previously, I've just "sprinkled" stuff into a scene randomly, but this doesn't look very good. Stuff tends to be clumped together in the natural world. So, I used a Perlin noise map to control the placement of plants and rocks. In fact, for the rocks I use two perlin maps, one to control size and one to control colour, because rocks of the same colour tend to be clumped together as well. I use a less detailed perlin map for tone, so the colour changes more gradually. Finally, I use a third Perlin map to control the placement of grass, weed and trees. This is how the complete scene turned out:
  13. That's a very clever idea. Thanks, Hodgman!
  14. Yeah, what I have implemented seems to be the same as Unity's "dynamic batching". I'm not sure what Unity "static batching" is though. Well, that's good to know anyway. Thanks for the answer.
  15. I've got to the stage of my game where I have hundreds of small meshes in a scene, so I wrote a batching class to reduce the draw calls. For each frame this class takes any mesh below a certain size in the current camera frustum, transforms the vertex data and joins them all together into one big mesh. The algorithm has to run each frame, because the camera frustum is changing each frame and stuff is moving around as well. Reducing draw calls decreases the amount of work that the CPU has to do, increasing frame rate, but on the other hand transforming the vertex data each frame increases CPU load. So, there is an optimal level, which I found to be around 100 vertices fro mesh size. In other words, I only batch meshes that have less than 100 vertices and that gives optimal performance. Is anyone doing something similiar to this? Any tips would be appreciated. Unfortunately I have to use OpenGL ES 2.0. I know there's probably some cool function in 3.1 that makes this a lot easier, but I don't have access to that.