New TGC product: AGK Studio(=AGK3?) + discounts for early adopters..

Started by Rick Nasher, February 04, 2019, 23:10:49

Previous topic - Next topic

Pingus

@Gabor
Quote"It's more complicated to implement" is not a disqualifier but rather a motivator.
Solving these things and coming up with the best solutions is the fun part of game dev. :)

Well, we are all different  ::). The funniest part to me is to think about a gameplay feature, implement it, discover that it does not works as expected (99% of the time) but it brings a new idea which is fun to play etc... I understand the fun about finding tricky solution to technical issues tough but its often very time consuming.

QuoteJust don't say it's because AGK can't do it or is too slow for it, that's not fair. It can do it easily.

I do not see in what it is unfair. AGK is fine, but I find interresting for people to know that it can not work the same way as a compiled language when it comes to solve some cases. The speed difference is not negligeable for some tasks. I'm speaking about ratio like x1000 faster. Saying "it can do it easily" is unfair if you have to find exotic solutions for problems that are usually solved with 'just' 2 intricated loops to parse an array.

@Qube

If I get your idea, it is to create a DLL with BlitzmaxNG and use it inside AGK ? That's indeed a good idea. It would works only for PCs tough.

Derron

@ Pengus
(think you talked to me instead of "@Qube" ;-)).
It does not matter if the compiled language is a bunch of times faster for "array iterations". If you want to use it on a web-platform (html5) or android/java or ios you will end up with playing on either older hardware, limited hardware (intel IGP), ...
You will have to pay attention to: draw calls, texture sizes, ... and for CPU limited things: processing time for a "loop/tick".

So if it is "on the fly compiled" (jit compiled) or not: heavy array processing will sooner or later kill performance. If it does not do at the beginning it will be recognizeable later on - when you add all the bells and whistles. Updating a hundreds of particles, effects ... each "physics tick" is already costing a pile of free cpu cycles.

Means it is a good idea to think _ahead_ on how to properly approach an "x*y" check. Do I really need to check all x*y or can I get rid of some checks to save some time.
Yes, coding will be more complex but we still talk about the "basics" of the game. So all the later on added "advanced stuff" just is placed on top of the basement you built. Later added stuff does not need to know about a "marked dirty" cell or so - you call eg. "SetCell(x,y, item)" or so and the underlaying engine then handles everything for you.

Same is to say for all other games too. Assume you have a level - based on a gridmap. It is no good idea to loop over every tile in the gridmap to check for colliding objects. Only handle stuff there units walk along. Differentiate between "level tiles" (eg. background stuff) and "level items". But hey, even here you will find multiple approaches to it - and HERE I guess some forum users are heavily experienced with jump'n'runs and tilebased games.


bye
Ron

Xerra

Quote from: Pingus on February 09, 2019, 16:20:35
I do not see in what it is unfair. AGK is fine, but I find interresting for people to know that it can not work the same way as a compiled language when it comes to solve some cases. The speed difference is not negligeable for some tasks. I'm speaking about ratio like x1000 faster. Saying "it can do it easily" is unfair if you have to find exotic solutions for problems that are usually solved with 'just' 2 intricated loops to parse an array.

Actually, that's probably a bit of a reactive statement rather than something thought through. The whole point of programming a game is to make it work with the tools you have available. If something doesn't work when you code it but you can see other examples of the same mechanic working just fine then surely it makes sense to look at how you've done it and try to improve upon your work.

What you're kind of saying here, without trying to offend, is that AGK isn't up to task for what you want to do with it because you've tried and not managed it. You're then putting on your blinkers and putting the blame on the system for not being able to create a dedicated executable even though, for the job you need it to do, it's more than up to the task if you follow the advice you're being given.

You think Andrew Braybrook looked at the C64 and thought "It's really hard to write a 50fps shoot-em-up on this machine. I'm going to wait till the Playstation comes out so I can cheese it."

You're basically wanting to throw a bucket of water over a fire in an ashtray.
M2 Pro Mac mini - 16GB 512 SSD
ACER Nitro 5 15.6" Gaming Laptop - Intel® Core™ i7, RTX 3050, 1 TB SSD
Vic 20 - 3.5k 1mhz 6502

Latest game - https://xerra.itch.io/Gridrunner
Blog: http://xerra.co.uk
Itch.IO: https://xerra.itch.io/

Pingus

@Xera,

I apologize if I sounded reactive, this is not my point.

QuoteThe whole point of programming a game is to make it work with the tools you have available.

For a hobbyst, maybe. To me the whole point is to finish a product that work as good as possible in a reasonable amount of time. If I have only one tool available, and if that tool can not do what I want... well, today I would just try to do something else.

A while ago I made a Match3 game with a 3D engine that was using an interpreted language :  biggest fail ever :)
It took a while to do because the nature of the engine was not appropriated for such a game, and cherry on the cake it was a total commercial fail but that was also because of bad design choices so I can not complain only about the engine ;).

When I discovered blitzmax few years later, the things that were a nightmare to handle became so easy with just object lists and fast loops thru arrays without having to think to optimize loops, because it was no more a bottleneck. The speed of devellopment was multiplied by 2 (at least).

QuoteIf something doesn't work when you code it but you can see other examples of the same mechanic working just fine then surely it makes sense to look at how you've done it and try to improve upon your work.

True. So far I saw nothing made in AGK that is close to what I do in blitzmax that's also a reason of concern, but not a major reason in fact. If you know a M3 game with a big board (~20x20 or more) made in AGK, please let me know.
My approach is to avoid 'fanboying' for any engine, and obviously, different engines have strengths and weaknesses.

Quoteis that AGK isn't up to task for what you want to do with it because you've tried and not managed it.

There is a misunderstanding. I did'nt tried to make anything serious with it.
I just started some speed tests which led to see a huge difference of speed when a lot of code is used in a loop. This was a no-go to me because my purpose is to convert (somehow) a blitzmax existing code which was builded for years. Today that framework works fine and gives the result I expect in term of performances.
I want to have a look at the Android/IOS market but I do not want to reinvent the wheel. From my short and quick test with AGK, it became quite clear that it could not allow me to do the job expected, the way I plan to do it.
*Unless* of course rewriting from scratch the core base, hoping that it would not hit a wall when it becomes more advanced and sophisticated.
I learned programming on a ZX81 in assembler, it was in another life, it was great to push and pop :)!
But we are no more in C64 days where every line have to be carefully weighted, hopefully I would say (but this is a subject on itself).

Maybe AGK could do the job, but considering that there are competitors that can compile to machine code, at least one difficulty of the port I plan is solved.
Actually the two engines I consider are Unity and GameMaker (but I really dislike Unity).
I find AGK way closer to blitmax than the engines above, hence my interrest about a new version that could have seen some changes. Well it is not the case, too bad but not the end of the world. I'll continue to check AGK from time to time anyway.

Qube

@Pingus

AGK can easily handle what you need. You just have to avoid multiple parsing of arrays over and over again :)

This was a match-3 game I was working on over a year ago in AGK ( not completed ). I've quickly adapted it to fill the full screen ( so ignore the background text on the left ) for a demo here which ended up at 19x11 ( not your 20x20 ) but you get the idea in it's execution.

Demonstrates full HD 1920x1080 animated + effects + background + multi drop board at 19x11 gems. Quite a busy scene which runs happily at 60fps.

The basic way it was coded was as follows...

An integer dimension of x, y, s

x = board x
y = board y
s = cell state

The cell state covered gem icon, animation frame, drop state, drop y offset, etc etc.

Although there was a lot of logic in the routine, it only had to parse over the board once per cycle. Each cycle after that was just updating what happened in the previous cycle.

You can get the idea from the video below that AGK can easily handle a match-3 game and you don't need to go into crazy optimisation as I'm a pretty old fashioned brute force coder myself :P

( full 1920 x 1080 @ 60fps video )

https://www.youtube.com/watch?v=Wu0Ys5693OI
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

iWasAdam

for a 20x20 grid you should be having about 400 checks (in total) per frame. If it is getting too much, then you can always spread the check out over different frames. E.G. odd frame numbers check odd cells, even frame numbers check even cells - that way you halve your checking...

just a thought :)

Derron

@ iWasAdam
That does only work if you enable "collapsing with already collapsing blocks" - or to delay the "collapse" to "every 2 frames".

If on frame 1 a "horizontal" match3 is found and "collapse" was started, then a potential second vertical match 3 with one of the cells (eg a "+" formation) cannot get catched in frame 2 as the vertical match 3 cells are already collapsing.

In that case you needed to only _mark_ the horizontal match during frame 1, then on frame 2 mark the second one ... and once you are done (you could split up in X frames...) you call "collapse" which handles all the marked cells.


BTW: In my game (TVTower) I had AI "thinking" split into multiple cycles too - they get "ticks" assigned which they can do small things instead of eg. checking hundreds of movies in one "blink". This also allows to have "slow thinking" AI and so on. It is needed as some complex stuff the AI does - cannot get handled "steadily" in the <15ms you have between a 60fps render - not to talk about 144hz displays and vsync ;-).


@ Pingus
As IWasAdam suggested, splitting the checks into "chunks" will help if it lags here and there. If your physical update rate is eg. 200 per second, you will loose 5ms if you alternate checks between 2 frames. You could even split them up in even more blocks.
BUT ... make sure to update the board state not every frame then - but only on "collapse" (eg. every 2 frames - or whatever you decided to) as you else end up with a inconsistent state (during first check you found something which is no longer valid on the second part of the check).

As said by me and others: writing the basement in the right manner is the key to a performance wise success. For prototyping it is ok to do "brute force" but if you plan to do stuff more than once (multiple games) you should consider putting in some efforts to the basics. And as written: your game does not change if you changed the basic engine. There is an "MarkCell(x,y)" and whatever it does is not of interest for the "high level logic" of your game. Also a game object might have an "OnKill()" method - and it is unimportant how it is called it is just important that it was called. So if the logic kills it after 2 frames of a collapse or after 1 frame... result is the same.


bye
Ron

Xerra

@Qube: That demo looks better than a lot of Match3 games that have actually been published. You really should bounce that out as an actual game as it's already mostly there, by the looks of it.

@Pingus: For Qube to put that game at 20*20 squares then he'd probably need to have smaller graphics but looking at how it's running now I'd put money on it having no frame rate issues with that many objects to work with. The code tricks to save CPU load suggested by Adam and Derron also make a lot of sense, though I'm not even sure you'd actually need them unless there's a lot of other stuff that's heavy on the processor going on as well. I really don't think AGK is a bottle-neck to what you're looking at doing. If it was me then I'd rather acknowledge it's just a personal decision rather than pushing the blame onto something about the system that's unrelated. Blame is a harsh word there but I couldn't think of anything else suitable. This isn't a dig, I assure you, I just don't agree with your reasoning for writing the system off. Nothing personal.

Us old-school programmers - the kids who were growing up in the eighties - learned how to do everything the hard way. If you could save a few bytes by reusing a function or rotating/mirroring some graphic characters in code and make your game use that as a feature then you would. Everything had to be tight due to the limited memory you had to do what you wanted. I'm never going to be able to shake that mentality as I'm both too old and stubborn to want to get casual about it. When I'm writing a game now, if I use a bit of code more than once then it goes into a script (function) so I'm not duplicating code.

The world has moved on now and the processing is now far ahead of any need for optimising to really be needed most of the time. I think that the attitude of younger people who are writing games now don't have any thoughts towards making things tighter because they don't need to. They have all the memory and space they require for duplicated files with slight changes or whatever, so they just throw it all together in whatever system they are using and, if it does turn out to not run as well as they would like, then they can just throw it into whatever spankly-new-shiny system that's more recent and can handle it. And there's nothing really wrong with that, as long as it works. Old farts like me can't really tell the difference when they play the game. If it works, then it works. But then we are likely to question why this game is 2.3gb to install when it doesn't appear to be much of an advancement over the same kind of game from a couple of years back that was a 289mb install, for example.

Again, we won't really care that much with our 2TB hard drives, but it just makes me think to myself how wasteful we actually are just because we don't have to worry about it. I'd like to bring an analogy in with how the planet has got itself sincerely in the shit because of our lack of recycling for so many years because we weren't that worried about it but that would be another debate altogether.

Better to go off rant mode here but I hope you can see my point. It's more fun sometimes (and that's why we're all doing this) to actually work at coding to do what someone thinks isn't possible. I'll never get out of my habit of trying to keep things tight and save a bit of memory/cpu/storage but in a few more years I'll bet not many younger programmers will be bothering. This is probably why I think that some of these applications like Pico8 are genius. They impose hard restrictions on what the virtual machine can actually achieve then give you the coding syntax and tell you to try and achieve something amazing with it. Some people do really seem to dig this kind of thing so hopefully they apply that kind of thinking to when they jump back to Unity and plan to use the same image 100 times in different functions and don't just use the same graphic, for example.
M2 Pro Mac mini - 16GB 512 SSD
ACER Nitro 5 15.6" Gaming Laptop - Intel® Core™ i7, RTX 3050, 1 TB SSD
Vic 20 - 3.5k 1mhz 6502

Latest game - https://xerra.itch.io/Gridrunner
Blog: http://xerra.co.uk
Itch.IO: https://xerra.itch.io/

Pingus

@Xerra,

I'm 100% with you about your ranting (memory and file size). All that terabytes are consuming a huge amount of energy, to create the PCs, the cards,  the hardisks, to cool the online servers, well... our love for HD movies and HD youtubes is not good for earth.

@Qube,

Your video is a mind changer to me :). As Xerra said you should continue working on it. Is it running on a PC or MacOS ?
Did you tried it on a smartphone ? That would be the ultimate confirmation.

Qube

Quote@Qube: That demo looks better than a lot of Match3 games that have actually been published. You really should bounce that out as an actual game as it's already mostly there, by the looks of it.
Thanks, it was an abandoned game for the 2017 Halloween comp. If I ever did do another match-3 game I'd just rewrite it from fresh :)

Quote@Qube,

Your video is a mind changer to me :). As Xerra said you should continue working on it. Is it running on a PC or MacOS ?
Did you tried it on a smartphone ? That would be the ultimate confirmation.
It was on MacOS but I did test it on Windows during development and it ran the same.

Just tested on an iPhone 8+ and it runs at 60fps with no wobbles :)
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Xerra

Quote from: Qube on February 10, 2019, 16:02:05
Just tested on an iPhone 8+ and it runs at 60fps with no wobbles :)

Just found my old Nokia 3310 in the cupboard. You reckon your demo would run on that? :-)
M2 Pro Mac mini - 16GB 512 SSD
ACER Nitro 5 15.6" Gaming Laptop - Intel® Core™ i7, RTX 3050, 1 TB SSD
Vic 20 - 3.5k 1mhz 6502

Latest game - https://xerra.itch.io/Gridrunner
Blog: http://xerra.co.uk
Itch.IO: https://xerra.itch.io/

Qube

Quote from: Xerra on February 10, 2019, 23:06:31
Just found my old Nokia 3310 in the cupboard. You reckon your demo would run on that? :-)
I think one of the animated gems would fill up that phones memory :P
Mac Studio M1 Max ( 10 core CPU - 24 core GPU ), 32GB LPDDR5, 512GB SSD,
Beelink SER7 Mini Gaming PC, Ryzen 7 7840HS 8-Core 16-Thread 5.1GHz Processor, 32G DDR5 RAM 1T PCIe 4.0 SSD
MSI MEG 342C 34" QD-OLED Monitor

Until the next time.

Pingus

@Qube,

Thanks for testing.

I need to check on a weak laptop.

Amon