Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Sub

Pages: 1 2 [3] 4 5 ... 10
31
SFML projects / Re: Neural Network + Genetic Algorithm
« on: December 06, 2017, 04:16:14 pm »
I'm a big fan of the game Super Hexagon, but I'm kind of terrible at it.  I've long since wanted to write an AI to beat the game for me because I'm incapable of actually beating it myself.

So yeah.  I got a kick out of this, really cool stuff.

32
SFML projects / Re: Acrobat
« on: November 20, 2017, 06:13:03 am »
Here's a video in which I control a very tiny and nimble square. It can fly / teleport and (not implemented but eventually) shoot energy beams / energy balls / lazers.

I'm the yellow dude. The circle around me is how much energy I have. Flying and teleporting drains energy. Energy automatically regenerates after not using any for a short period of time. Energy regenerates 3 times faster if you're completely stationary.

If you fly into the opponent square, a melee collision happens, and the loser gets damaged and knocked back. The winner is determined by whoever was moving faster in the opponents direction. It's all about momentum.



On the list of things I've done since recording this video
-  Added a somewhat reasonable camera instead of the stationary one shown in the video
-  Improved AI's use of teleports so as to not unproductively zig-zag around

 On the list of things I think would be cool to do
- Improved collision detection / melee resolution. It's a bit janky in the video, but I know what I should do to improve this.
- Add malleable / destructable terrain (basically integrate the code from the second part of the video in the first post)
- Add energy attacks
- Make it look pretty

On the more unreasonable end of things I'd like to do
- World generation. Instead of the level taking place on a flat surface like in the video, it'd be cool if it took place on a rather large circular world populated with enemies. Gravity would point towards the center of this circle.
- Add rpg elements, where your character can level up to learn new attacks / gain more energy / speed.
- Add rogue-lite elements, so that when your character dies, you start over with a new character on a newly generated world.
- Going hand in hand with the above point, it'd be cool if there were a handful (not that i'm trying to stick with the dbz theme but 7 would honestly be a good number) of scattered items for you to collect on each world. After collecting all of them, you'd be able to select from a list of bonuses to choose from. One of these being immortality aka respawn.

----

I've changed the name of the topic to Acrobat, but I'm not really in love with the name.  If anyone has a suggestion for a better one, I'm all ears.

33
SFML projects / Re: It Usually Ends In Nuclear War
« on: November 12, 2017, 05:25:51 pm »
Ah cool.  Looks like a nice clean library.  Very easy to read / understand the code  :)

34
SFML projects / Re: It Usually Ends In Nuclear War
« on: November 10, 2017, 03:54:41 pm »
I don't know if I'll ever get around to this, but what I'd like to do instead is have a generic job queue system in place where the main thread is posting jobs which need to be done, and there's a constant number of threads taking the next job up in the queue and performing the work.  That would utilize all the cpu cores more consistently / evenly.

Easiest way would be to use a thread pool library.

Yeah.  It was bothering me so I went ahead and integrated a thread pool library instead of having dedicated explicitly defined threads for specific tasks. 

Went with CTPL (https://github.com/vit-vit/ctpl) as it seemed reasonable and didn't have any show stopping open issues.  There was another library that I liked the API of, but it had a deadlock in the most recent version that the author didn't seem too keen on fixing anytime soon.  There was also a boost one that looked like it could be good, but I don't want to use boost.

I'm curious if most people roll their own or something.  I expected there to be libraries with thousands of stars on Github, but the most popular one I found was a C library with 450 stars. 

35
SFML projects / Re: Zeran's Folly
« on: October 22, 2017, 10:12:31 pm »
Congrats on the Steam release :D

36
SFML projects / Re: This Grand Life
« on: October 21, 2017, 12:51:32 am »
Fair enough.  Not a huge deal, I just downloaded the demo and it seems to work perfectly on wine. 

It's pretty cool.  Music actually reminds me of the sims, which seems appropriate.  Only suggestion I have is that it'd be awesome if the game were playable through a keyboard or controller.  Like when a new dialogue comes up, it'd be nice if it had focus so you could press enter to close it rather than having to move the mouse over. 

37
SFML projects / Re: It Usually Ends In Nuclear War
« on: October 21, 2017, 12:28:25 am »
Thanks :)

The game is now multithreaded, though I was way too optimistic in that post.  I can relate to the crashes and bugs, it was a nightmare to get it working properly.  I had to rewrite a bunch of code and it wasted a lot of time. 

It fixed the performance issue I was having, but honestly, if I get a chance I want to go back and improve this aspect of the code because it could be a lot more efficient.  I decided the easiest thing to do would be to have separate sections of the code be offloaded to their own thread.  So for example, the units are all being processed on their own thread, the cities on their own thread, etc. 

I don't know if I'll ever get around to this, but what I'd like to do instead is have a generic job queue system in place where the main thread is posting jobs which need to be done, and there's a constant number of threads taking the next job up in the queue and performing the work.  That would utilize all the cpu cores more consistently / evenly. 

At the very least I want to have a system like that for the next project I do.  Game dev is hard and I'm kind of learning as I go here.

38
SFML projects / Re: It Usually Ends In Nuclear War
« on: October 20, 2017, 06:28:14 am »
Not much to look at yet, but I started work the other day on a tech tree GUI.  Each technology is defined in a json file, and the game generates the layout of the tech tree based on the order of the tech unlocks.  This was slightly harder than I thought it would be, but I've now more or less got the positioning down. 

It used to be a simple list


The WIP Tech Tree


The blue box is what's directly unlocked by researching the moused over box.
The red box is what's directly required to unlock researching the moused over box.
The purple box are what is indirectly required to unlock researching the moused over box.

In other words, all of the purple and red boxes need to be researched before you're able to research Astronomy. 

Next on the agenda is drawing lines from each box to their direct unlocks.  I'm thinking that I'm going to define a small (invisible) grid (with each cell being 10x10) and adapting the pathfinding system to make this happen.  The width/height of each technology box is going to be a multiple of 10 and the boxes in the grid which overlap with the tech boxes will be defined as obstacles.  Then it'll just be pathfinding between relevant tech boxes.  I suspect that with each line I add I'm going to need to update the grid to mark those boxes as obstacles to prevent lines overlapping. 

I'm not really looking forward to this, and I'm not 100% sure that it'll actually work and look nice, but we'll see.  I'm going to try to make that happen either Friday or Saturday.

Then I'll need to add icons / progress bars and try to make it look pretty.

39
SFML projects / Re: Mad Maze Attack
« on: October 20, 2017, 12:21:54 am »
Visuals took a minute for me to process but it does have a certain charm to it.  I'm not an artist, but for what it's worth, I think the characters / animations are well done.  I think you guys would benefit from having a better ground texture though.  I feel like the green / yellow patches in particular don't match the quality of everything else.

I'd also echo what Mario said.  I think you guys would benefit if you came up with a single sentence that describes the game and how it plays. 

40
SFML projects / Re: This Grand Life
« on: October 20, 2017, 12:11:58 am »
Don't really have much to say other than that this looks great.  It reminds me a bit of the game Drug Wars which I had a ton of fun with when I was younger.  Keep it up :)

edit:  Any chance this will also come out for Linux when it's done?

41
SFML projects / Re: Screenshot Thread
« on: October 15, 2017, 06:32:52 am »
Civ-like game I've been making.  Every day a little closer to completion.  I think I'm finally happy enough with the aesthetics.


42
General discussions / Re: SFML 3 - What is your vision?
« on: August 13, 2017, 11:59:46 pm »
This is a nice thread.

The only thing I want is better multi-monitor support, as I've run into a few issues with this on both Linux and Windows.   Sounds like this is already on the agenda though. 

43
SFML projects / Re: It Usually Ends In Nuclear War
« on: July 15, 2017, 12:02:21 am »
I've been refactoring the codebase lately with the goal of increasing performance, mostly from multithreading it. 

Prior to now everything was a single thread.  I had no proper experience with multithreading, but I knew that it added a lot of complexity and I honestly thought that I could get away with the entire game being one thread. 

I think if this game was strictly turn based then it'd have been fine, but it's not.  You press one of the speed buttons up top, and then turns start happening automatically on a set interval depending on the speed chosen. 

As I've started to add in more complex AI behavior and the number of units and cities grew, it became clear that I'd need to make the game multithreaded.  On the fastest speed, turns happen about once every 600 milliseconds, so when the game was a single thread those 600 milliseconds were essentially wasted, as the game was waiting until the 600 milliseconds were up in order to calculate the next state of the game world.  It led to a noticable pause every time a new turn occurred.

So that's how I've been spending my time lately.  Truthfully it's not as bad as I thought it'd be, though I do wish I did this sooner. 

Since I'm refactoring the codebase to allow for that, I've also taken this opportunity to improve other aspects of the code.  The grid for instance is something that I wrote in 2012 when I was much worse at programming than I am now, and it could really be better.  Notably I had entangled it too much with code specific for this project.  What I want is something independent which can be reused in other projects.  It'd also be nice if it supported multiple grid types (square, isometric, hex).

So I spent some time working on that and it's been a pleasant success.  It's now faster, more flexible, and you can set the grid type at initialization.  Currently supports square, isometric, and I spent about an hour last night adding in hex support.  The game is mostly agnostic to what type of grid it takes place on, so I can now generate a world using any of those grid types, which is pretty cool.  I'd have to do some work to make it truly playable on a hex grid (for instance, some AI code would need to account for the different grid type), but curiosity of how this would look as a hexmap got the better of me. 

I'm hoping to get back to actually implementing more gameplay soon.










44
General discussions / Re: The Steam Direct fee is $100
« on: June 25, 2017, 04:59:49 pm »
Damn.  Figures.  There was a lot of greenlight submissions for asset flips.  I guess it makes sense that all of that stuff is now just going to go directly to Steam. 

45
Looking good  :)

Pages: 1 2 [3] 4 5 ... 10
anything