Messages

61

SFML projects / Re: It Usually Ends In Nuclear War

« on: June 20, 2017, 03:32:23 am »

That looks so cool and nice! Good luck in development! Hope "it will end in enjoyable game" (not a nuclear war ) How do you make this "terra incognita" effect? (unexplored areas are not shown)

Thanks!

I don't know if I have a great answer for you.  I don't think it's doing anything fancy or clever.

The map is currently a giant VertexArray which has its vertices set once immediatley after map generation.  I have a variable representing the unexplored map color (I think its currently at an rgb of 22, 22, 22), which is what the background color of the window is set to, as well as what each vertex color on that array is initially set to.

I keep track of a few vision related things for every nation.  Each tile has a VisionCount associated with it for every nation.  If for instance a unit moves (or is created / destroyed), this VisionCount is updated for every relevant tile.  In that way I know whether or not to draw a given unit or city. 

But yeah, when a tile goes from unexplored to explored I update the VertexArray, changing the relevant vertex colors from the unexplored color to that tiles actual color.       

Originally the vertex array only contained the tiles on screen, and I was reconstructing the array each time the camera panned or a game update happened,  I'm not sure if there's a meaningful difference in terms of performance between the two.  Eventually I'd like to convert it to a vbo so that there's not a ton of data continually getting sent to the video card each frame, but it runs fine on my old laptop at the moment so I haven't bothered.

I also used to do some crazy stuff with the background color and map edge, where I wanted the background color to be this certain shade of blue, but I couldn't set the background color at the start of the game to that, because then the player would be able to easily see where they were on the map by panning the camera around. 

So to solve that problem, when a player explored any map edge, I'd cast a ray along that edge to either the actual end of the map if it was explored, or it'd continually cast to the edge of the screen if not explored.  I'd use the two points on this ray to draw a shape filling out the remaining skybox of the screen. 




So the camera is at the same spot in both of these screens.   The top left edge isn't drawn in the first screen because the player hasn't explored a tile on the top left edge yet.

So in that first screen, the blue in the top right is a shape explicitly drawn.  Like I said, it allowed me to have a separate background color and unexplored terrain color, and it's the type of thing that I personally appreciate and think is cool, but uh, on reflection it's a bit insane to focus on things like that when the actual gameplay needs work.  That code currently isn't even in the game anymore as I commented it out during a refactor one day.

Tangents like that are partly the reason why this game is taking me so long to make.  I've been trying to focus purely on the things that actually matter now.  Which, as an aside, I implemented the above city location code and it looks like it's working well enough.  Pretty happy about that. 

62

SFML projects / Re: It Usually Ends In Nuclear War

« on: June 19, 2017, 04:36:09 pm »

Today I'm going to try to implement an algorithm which picks city locations for the AI. 

If you've ever played civilization, you should have a good idea on what this means, as it's more or less the same problem from that game.  Maps in my game are much larger than in Civilization, and my game ticks along at like 1 turn every 600 milliseconds, so performance is a pretty huge concern. 

I'm still debating the exact city ring size, and I'm going off memory here but I think cities can currently grow to a maximum of 5x5 tiles.  You can see the maximum growth of a city by the black outline around the center city this screen



If anyone has any suggestions on a good way of going about doing this, all I'm ears.  I've come up with something that I think will work (high level code outline below), but I wouldn't be surprised if there's a much better way of going about it.

Code: [Select]

// Only one  object of this class will be instantiated, and each AI will talk to this object in order to get a city location
class AI_City_Location_Mapper
{
private:
    // first dimension is number of continents on the map (where a continent is a group of connected land tiles)
    // second dimension is a vector of tile indexes where cities should be placed
    std::vector<std::vector<int>> CityLocationsByContinent

    // where the magic happens
    void calculateCityLocations(int ContinentIndex);

public:
    // city locations are calculated for each continent on map generation and cached in the above array
    void onMapGeneration()
    {
        CityLocationsByContinent.resize(NUMBER_OF_CONTINENETS);
        for (int i = 0; i < NUMBER_OF_CONTINENETS; i++)
        {
            calculateCityLocations(i);
        }
    }

    // if the human player settles a city, the city locations for that continent might need to be reworked to make more sense.
    void onCityCreation(int ContinentIndex)
    {
        calculateCityLocations(ContinentIndex);
    }

    // basically, the above two functions are the only time when city locations are going to be updated. 

    // when the AI wants a location for a new city, it calls this function, and passes the unit index for the settler in question. 
    // the game iterates through each possible city location for the continent the city is on, and does a simple calculation
    // based on distance and city desirability to determine which city location to settle
    // -1 if no city available
    int requestCityLocation(int UnitIndex);
};


For calculateCityLocations(), I'm thinking that I'm going to divide the map up into a larger grid, with each cell in this larger grid representing let's say a 5x5 group of cells.  Perhaps that size will be determined by the city ring size.  I then think I'm going to assign a city location in the center tile of the actual grid for each cell in this large grid. 

So essentially calculateCityLocations would be iterating over each city in this list and moving the city location over 1 tile for each loop iteration, based on the best location of its neighbors.    If the initial city location happens to be on a water tile, I'll have to do a check to make sure that doesn't happen or fix it when it does.  I already have a function which ranks how good any given city location is, but I'm going to need to expand that function to take into account tiles which are already owned by another city (obviously those tiles would be degraded in importance).

I'm aiming to do all of this today, but we'll see how it goes.  Like I said in the beginning, if anyone has a better idea on how to go about doing this, I'm all ears.  This was the best I could come up with for now.

63

General / Re: SFML Icon - Pin To Taskbar Problem - Bug???

« on: June 17, 2017, 08:35:02 pm »

Not sure if there's a more generic way to do this, but for Windows, you need to create a resource file specifying your icon and add it to visual studio.  Then when you compile next, it'll be added to the exe.  The replies here should help you out

https://stackoverflow.com/questions/320677/how-do-i-set-the-icon-for-my-application-in-visual-studio-2008

64

SFML projects / Re: "Our Dear Paper Fighters" - Top down shooter

« on: June 11, 2017, 06:00:27 am »

I love the custom text you've made.  It really fits the game nicely.  Well done!

65

SFML projects / Re: It Usually Ends In Nuclear War

« on: June 11, 2017, 05:47:48 am »

I'm still working on this and have been making good progress recently.  There's still a lot of work left to do, but I feel like I can see a light at the end of the tunnel now.

I've changed the name of the game from "It Always Ends In Nuclear War" to "It Usually Ends In Nuclear War".  The name was meant to be a commentary on human civilization, but I decided to change it as I was afraid that the old name could have given the wrong impression about the gameplay. 

I've also changed the graphics a bit.  Previously I had a pronounced psuedo-3d height visual effect going on.  I liked the way it looked and I put a fair amount of work into it, but it was purely aesthetic and it prevented me from using tile colors to display information about a given tile. 

For instance, in most if not all other similar 4X games there are a set number of distinct tile types.  In Civilization II for example,  a tile could either be  grassland, swamp, forest, plains, desert, or tundra.  Each tile type had a specific food, production, and science output.  I want the output of a tile to be somewhat dynamic, and I want the player to more or less be able to tell the output of a tile by its color alone. 

So I still have a base set of tile types which have a specific food and production output, but the tiles are blended in with their neighbors, and the outputs are averaged together (as is their color).  On top of this, I'm also further applying a bonus to production or food to select tiles, and I'm using the the shade of a tile color to communicate this to the player.   Darker tiles are better for production, lighter tiles are better for food. 

I can't say how anyone else will receive it, but I really quite like how it turned out.  At least in my head, lighter green tiles look more like grassland tiles and accordingly have great food output, and darker green tiles look to me more like forests and have great production output. 

The reason I'm happy about this is that most maps will have huge swaths of land which are a single tile type.   In the old system these tiles would all have the same output and I honestly don't know how I would go about balancing that.  This new system allows me to have those large swaths of land which are the same tile type, but vary their output depending on the shade, which for example would make some tiles in a huge swath of desert still desirable.

I've done a lot of other stuff since then, but those two are I think the biggest and most obvious changes.

Older look


Screenshot fro a few months ago.  The map is completely flat here


Screenshot from yesterday morning.  I readded height to the map here, but the tile shadows from height are no longer present.  Kind of a compromise between the two

66

SFML projects / Re: Remnants of Naezith is now on Greenlight!

« on: May 27, 2017, 08:40:08 pm »

Do you know a site or something like this were you can sell your games for free?

itch.io

67

General discussions / Re: Artificial Intelligence.

« on: May 16, 2017, 11:31:01 pm »

Programming AI by example is a perfect start.

This is a fantastic book. 

For pathfinding, this was helpful to me in the past. 

On a final note, two years ago I wrote a quick post explaining how I made a Tetris AI here.  Not the most relevant thing for most games, but for Tetris it was surprisingly effective

68

SFML projects / Re: CUIT is now on Steam Greenlight!

« on: March 26, 2017, 03:23:50 am »

Seconding that congratulations.  It looks like a cool game. 

69

SFML projects / Re: Three Prototypes

« on: March 16, 2017, 03:09:32 am »

Thanks! 

Yeah, that was my intended goal in creating a particle system.  I initially thought it'd be cool if energy attacks were similar to a fluid, where they'd react similarly to a ball of liquid when hitting another object.  The idea was to use a library like Liquid Fun for energy attacks, or some other solution for soft body physics. 

I then got the idea to have energy attacks be made up of a few thousand particles.  You can mimic the liquid effect with this system, but more work needs to be done to make it actually happen.  I'm not really sure how it'll actually turn out.  We'll see I suppose, but it's going to be slow going, because I'm only working on this idea for a few hours each month.

70

SFML projects / Re: Three Prototypes

« on: March 13, 2017, 12:31:51 am »

Apologies for not replying sooner, but thank you for the reply!   

I still am thinking about this idea and how to wrap all of these concepts up into one package.  To that end I spent last night creating a particle engine, and ended up creating another weird prototype in which I suppose you control the disembodied spirit of red particles, and are able to recruit white particles to your essence.  WASD moves around, but at the cost of 'killing' some of your red particles.  This was all made last night.

Brief disclaimer -- I had to record this one on my phone.  I had some glitches when I tried recording on my PC.

https://www.youtube.com/watch?v=3msEzzpwJug

71

General discussions / Re: 2.4.2 released!

« on: February 12, 2017, 03:07:05 pm »

Congrats on the release!  I'm happy about the set icon on linux fix.

72

SFML projects / Re: Remnants of Naezith is now on Greenlight!

« on: February 03, 2017, 10:10:28 am »

This legitimately looks awesome.  Congrats on being greenlit!

73

SFML projects / Re: Breaker_IS

« on: December 29, 2016, 06:33:46 pm »

Nice, looks very well polished!  Reminds me of this talk

74

SFML projects / Re: One Room - 37th Ludum Dare Jam

« on: December 21, 2016, 11:20:39 pm »

Woohoo I won!  Cool little game.  Played it on Wine without a problem.

I would agree with the first puzzle being hard.  I wasn't sure if I simply had the combination wrong, or if I had to press enter / do some other action after entering in the combination in order for it to take effect.  I think an easy fix would be to change the order of the puzzles.  The briefcase puzzle is easier in that it's more obvious that you need to change the combination somehow.  So you'd go through that puzzle first where you're forced to distrust the note, and then on the PIN you'd have some reason to distrust what was written there by example of the briefcase note not being 1 to 1 with the combination.

75

SFML projects / 9001

« on: December 08, 2016, 03:08:03 am »

[Latest]

https://youtu.be/4ayTI0Zbku8

There's a discord channel if you want to join -- https://discordapp.com/invite/TV43fRn

It's very WIP right now. 

I'm playing as the guy in red fighting against the purple guy.  There are two ways to damage your opponent

1)  Melee.  When two players collide, a melee collision occurs.  The winner is whoever was moving faster in their opponents direction.  The loser gets damaged and knocked back.  It's hard to tell when this happens in the video and who wins the melee clash because it still needs graphics for it.
2)  Energy Attacks.  These are only half-implemented at the moment

There's a red circle around me which indicates how much energy I have.  The larger the circle the more energy.  When the circle is red energy is being drained, when it's green energy is being gained.  You use energy from moving, teleporting, and charging energy attacks.  You start to regain energy after a brief moment of not using energy.  If you run out of energy, you have to wait a second before it starts to recharge. 

The idea is that you want to outmaneuver your opponent to score a hit. 

I'm working on a meta-game surrounding this giving you something to fight over.  The idea is that what you're looking at would be an individual level, which would be considered an entire world.  You'd have to kill everyone on the world (roughly 4 enemies per world) in order for it to be conquered.  I'm working on a very simple mount-and-blade like galaxy view where various factions are fighting over the planets.

[Original Post]
I've been playing around with the idea of creating a (very simple) 2D action game inspired by dbz.  I've got three small prototypes that I've built to that end

• An energy ball effect
• Malleable terrain (I'm thinking this would occur upon the player impacting the ground at a high speed
• Mockup of player / energy ball flight physics

Admittedly, #1 was made with Love2D, and #3 was something that I made back in 2012.  I'm not sure how much further i'm going to go with this, but I wanted to throw it out there and get a few opinions

https://www.youtube.com/watch?v=V7AMAUB83cQ