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
SFML development / Re: Window state
« on: February 02, 2018, 01:56:00 am »
Out of pure curiosity, what's the use case in having a hidden window?

edit:  Also, thank you Foaly.  This is something I've long wanted in SFML.

SFML projects / Re: It Usually Ends In Nuclear War
« on: January 21, 2018, 04:49:45 am »
Getting closer to where I want it to be. 

General discussions / Re: Why is SFML split with 1 dll file per module?
« on: January 19, 2018, 10:56:18 pm »
Splitting it has benefits which have already been mentioned in this thread.  For me personally, it's never been the source of difficulty or inconvenience, and I didn't exactly have a lot of experience in programming when I first started using SFML.

SFML projects / Re: Remnants of Naezith
« on: January 19, 2018, 10:47:54 pm »
It does look great.

How much is it going to cost? 

Were you working on this alone or did you have others?

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.

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.

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  :)

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. 

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

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. 

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.

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.

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. 

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?

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.

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