Don't have an account yet? Then register once and completely free of charge and use our wide range of topics, features and great options. As a registered member on our site, you can use all functions to actively participate in community life. Write posts, open topics, upload your pictures, put your videos online, talk to other members and help us to constantly improve our project and grow together! So, what are you waiting for? Become a part of us today!
To get support for a technical issue such as installing the software, to query a purchase that you've made/would like to make, or anything other than using our software, please visit our Customer Service Desk:
Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.
A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.
Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!
Nice work, congrats! REALLY curious how you managed the extension-less pathfinding for so many objects - I'm thinking some sort of staggering system?
Hey SolarB, thanks! You know, it's been like 7 years since I made the pathfinding but I think I actually used one of your old TD examples as a starting point!
So I use a combination of techniques. Enemies defaults to using a shared general weightmap and only get's individual paths when aggroed, which not only limits the amount of calculations needed but also leads to relatively short paths. And yes, for goblins and longer distances I basically que it up so the paths gets calculated for only 10 units at a time, next frame a new batch of 10 and so on. This queuing does introduce some delay (1 frame to be exact) but won't really be noticeable until 500+ units gets queued up which, thanks to the first step (and some other limitations), won't ever even happen in the game.
I use a similar limit for world creation. I remember having issues with slowdowns when creating large chunks of the world so now it will only check max 500 steps each frame.
Honestly there's probably room for much improvements but it works well and beyond for my purposes in this game.
Here are some screenshots of the demo from my ultrawide. It's 3440x1440 @144hz and ran at solid 60fps, but I am using an RTX 4090 so I'd be worried if it didn't.
It seems to respect the aspect ratio so that's good but ideally there should be full support for ultra-wide and it's on my to-do list. Hopefully it will be as simple as changing the window frame-size and maybe some code related to the scrolling and zooming. Thank you for the screens!
contra How did you deal with scaling? Given it has pixel art, what did you do to prevent it looking weird at various aspect ratios? I made an integer scaling method using sub apps for my project, but just curious as to what you did
And for pathfinding, did you use A* ?
Game looks incredible BTW
Yes, aspect ratios has been an issue (nothing worse than stretched or filtered pixels!). For now it simply uses 1920x1080 window with "DPI aware" option ticked which seems to have resolved things for most modern resolutions. I haven't tested it fully on ultra-wide and such setups though (if anyone can test on more uncommon resolutions I'd be happy to hear the result.)
Pathfinding uses A* for the most part. Using arrays to store and look up the path for each goblin using an ID variable corresponding to an arrays dimension number (X, Y, = cordinates, Z = ID).
Oh btw, the trailer is actually made entirely in CTF 2.5! So basicly everything in the trailer actually happened in realtime and I just screen recorded it.
For the past couple of years I've been hard at work on my first commercial title made in Clickteam fusion 2.5. I'm very happy to announce Goblin Colony!
Please login to see this link.
Please login to see this media element.
Please login to see this attachment.
It's an RTS in the vein of Dungeon Keeper with features from village-builders/colony-sims. It should be fairly unique especially for a klik-title. While there is still work left I'm very proud with what I've achieved so far and hope it might serve as an inspiration to other klikkers and the community.
Some inside info/features that might interest you guys: -Advanced pathfinding (supports hundreds of actors each with different start/goal) -1 frame engine (everything exept for a few exeptions like title screens etc is maintained in a single frame) -Gridbased movement -Fog of war -Auto-tiling (8 directions) -Positional sounds -Positional lights -Zoom in (with mouse correction) -Randomized levels ("smart" ie avoids making unplayable levels) -Map editor -Minimap* (updates in realtime)
Naturally it features other basic stuff like saving and loading etc. but that's not really worth noting. I know I'm not the first to do any of these things nor do I claim to have the best way of doing anything but the point is that the game has features and gameplay mechanics considered "advanced" in klik engine. All of this is done without the use of any extensions (* exeption, minimap uses "surface object") while running in fullHD at 60fps. I hope that this makes it a good showcase of what Clickteam Fusion 2.5 can do.
I hope you guys check out the game and that it maybe can serve as an inspiration for both old and new klickers! Please consider supporting the game by wishlisting on steam. Happy to answer any questions. Thank you!
The offset bug is there for about 8 years I guess, so I suppose it can wait a bit. Didn't want to run the risk to add more issues by trying to fix this.
Really? :o Surprising I did'nt notice it before but now it's killing me.
You say that loading this graphic is the first thing the engine frame does, but have you tried making it the only thing it does? For the very first fps I mean. Like maybe you could delay/deactivate the loading of the level etc. and for the first fps only have it create the loading graphic and see if that makes any difference. Just spitballing ideas here.
All the engine does is create copies of each object (with "0" qualifier) then set their position accordingly. All the code is in the "shadow engine v1.0" objects behavior. It's set up in a way to manipulate shadows for dynamic lights. For your purposes I think it would be better to use purpose specific shadow objects and for any moving object just pair them using the same method as with the turrets.
Though imho, judging from your shadowed version tanks, the quickest easiest way would be to just prebake the shadows in the tank sprite using alpha channel. I don't think overlaps would be that noticable. For the other movable objects such as the crates you'd need separate shadow objects for each (else break collisons).
I can't reproduce this, do you have an example? (perhaps it depends on the size of the object?)
I've done some more testing and can now reproduce it consistently. It happens on all sprites (both actives and backdrops) of all sizes. It happens both in maximed and small picture editor window. However, I believe it only happens when you are zoomed in and scroll down. You can see it in this video that when you scroll down, the top of the sprite get's "cut off" and this seems to cause the offset behavior. If you zoom out or scroll up it becomes normal again.
The cursor in picture editor is acting strange, sometimes the mouse cursor seems offset. It's doesnt happen on every pixel but it was introduced in the latest update (maybe because of the new zoom?)
Better explanation in picture: Please login to see this attachment.
NaitorStudios Look I've already posted pictures and explained what I meant in this very thread, but ok here it is again: Please login to see this attachment. This background now shares it's color with "Main UI - Control background color" There is currently no way to have this background be darker while having a "light" mode skin.
Here's a video of one example (but there's more) of the UI flickering/graphical glitching for anyone interested... Please login to see this attachment.
It is included. Look: Though it shares a lot of its colors with other global elements, so you probably can't skin it to be entirely different to the rest of the interface, if that's what you wanted
Yes I know you can change it globally (just like with dark skin) but I would still call that being omitted since there's like a gazillion settings for the storyboard/frame/event editor but none for the picture editor. Which is again especially strange since that one even had a unique background (the diamond pattern). Atleast this should be customizable.
Don't forget that the UI is now highly skinnable, so you can edit it until it's very similar to how it was before. I wasn't a big fan of the UI changes either, especially since the main benefits - dark mode and DPI scaling - are things that don't concern me. But I could skin it very close to how it was before without much difficulty. Other than a few of my own tweaks, my 294 now looks pretty much the same as 293 did. I agree it'd be nice to be able to edit the Properties Toolbar icons though; their sizes are weirdly irregular and the least prominent one ("Values") - is the one I happen to use the most.
Yeah I know and I have. Currently I'm using the Default (old) skin with some tweaks of my own. However there is a huge omission regarding the picture editor which for some reason does not seem to be included in the skin customization options at all. Since the first point of the update states "Fully customizable UI" it's very strange that one big part of the program (the picture editor) is just excluded from this. The icons I can learn to live with but the picture editor needs the same color customization as in the rest of the program applied. Being forced to use dark mode is not an adequate solutions and the performance issues and graphical glitches I feel is just simply unacceptable.
I absolutely love the new UI, users who complain just didn’t get used to it yet
Glad you're happy but don't go dismissing other peoples divergent opinions especially when it's on topic regarding the key point of an update. I'm sure you could get used to a lot of things but that really says nothing about the quality and it should be obvious that appearance is highly subjective.
I've been using clickteams products since '94 (actually even earlier if you count AMOS) and the UX has been largely the same ever since. Thats almost 30 (!) years. I've spent countless hours kliking and know this program inside and out. Despite there being other (arguably) more powerful options these days my number one reason for using clickfusion is familiarity. This is especially true for the picture/animation editor which I don't think anyone would claim is a perticulary "good" graphics editor, but I love using it since it's so easy and second nature to me at this point. It's part of both my dayjob and something I enjoy in my freetime so all this makes me very passionate and caring about the look of clickfusion.
Now, Yves has stated that the issues I have (my main one not even concerning looks but performance which everyone should care about) could be fixeable so I'm trying to being patient to wait and see but I refuse to have my opinions dismissed and belittled like this.
Do you mean the grey and white checkerboard in the picture editor? if so you can actually change the color from the editor it self via options (the one with the wrench icon) That's have been there for a long time, maybe even since release, but i'm not 100% sure
No, that's obviously not what I meant...It's this: Please login to see this attachment.
Didn't want to run the risk to add more issues by trying to fix this.
