View Full Version : PGD - Some thoughts about the future
AthenaOfDelphi
22-04-2014, 09:56 PM
Hi all,
Well, I have to say sitting in the management chair for the site brings on a huge mix of emotions for me. The site (or more specifically, the people) has helped me in the past when I've come unstuck with issues so I have a strong desire to keep that going. At the same time I'm acutely aware that the number of active users has declined steadily, pretty much in-line with the decline in popularity of our favourite tool. With the increasing popularity (this is based on job postings and the number of questions and Delphi related posts I'm seeing) I'm hoping that the decline will turn into an increase.
But, I'm not content with sitting back and just letting it happen around me. I want to try and help the rise and start showing all those nay sayers who believe you can't use Pascal to make games that they are quite frankly wrong :)
As a slight aside, if you are in touch with any one who was once an active member and they still use Pascal and they still develop games with it, I'd be interested to hear from them, in particular I'm interested in why they stopped visiting the site. On the flipside if they don't use Pascal for games development, I'd be interested in knowing what they now use and why. And what we could potentially offer as a community to encourage more use of Pascal.
Since taking over, I've had one or two chats with the active staff and well, there are a couple of things we really like the idea of.
The first, depending on how long you've been visiting, you may be familiar with... our competitions. So I'd like to ask a few questions about them (I'm happy for private messages if you don't want to air your opinions in public), mainly the questions relate to format.
Long or short (months vs. weeks)
Prizes (are prizes an important factor or is just getting community kudos enough?)
Themed or freestyle
Judged by a judging panel or by the other competitors
I guess really what I'd like to hear is everyone's views on this. I want to run a competition but I want to try and make sure we get plenty of viable entries.
The other big idea I floated to the staff was this...
There are some actively developed engines/frameworks at the moment, but nothing like it used to be. Lots of us want to write our own engines, but that can take a lot of time and if you look around there are guys here that have spent a long time writing engines and never seemingly used them in anger to make games with them. I know this is what some people like to do, but doing it solo can be a real drag, and well, at least one of these guys has said they wanted to get involved with a project with other people.
So the question I have for the community is this... do you think there is any mileage in building a community engine? Just to be clear, it would be open source, built by us for us (and of course anyone else who wants to use it, but primarily it's feature set would be driven by the members of this community). I would aim to support Windows, OSX, iOS and Android (courtesy of Delphi) and of course pretty much anything that can use OpenGL that Free Pascal can build a binary for. If you've got an engine or components already that you'd be willing to throw into the pot, please let me know, also feature requests... I'd like to try and get some sort of list together or the main features the community would want.
Comments and thoughts on that idea too... again, if you don't want to share your views publicly, please feel free to drop me a PM.
And finally content...
One of the biggest issues any community site has is it's content. WILL struggled with it, Traveler and I struggled with it. I'm sure you guys want regular fresh content. Well, you can all create content. You can post news items, write articles and request that they be published, you can blog. Thats a lot of different possibilities right there. If you've got an idea for a tutorial or a series of articles on some tech that's close to your heart but you're not sure whether it's relevant to the site... PM me and we can have a chat about it.
In fact, I'm happy to take a PM from anyone who wants to discuss pretty much anything about the site.
And on that note, I'm quite looking forward to what you guys have to say.
Mirage
23-04-2014, 08:15 AM
It's a really great idea about a community driven game engine!
We need 3-4 motivated people for this I think.
This obviously can help to solve the issues with user activity and content.
Concerning competitions, at the moment I'd prefer a themed and short one.
Prizes can be something like a permanent rank in the community, E.g. "winner of 120-th annual competition".
Probably judging by other competitors is simplier to organize.
de_jean_7777
23-04-2014, 08:15 AM
I do believe you can create anything with Pascal, not just games :) And that's after using several languages/frameworks at work for creating "games". Always want to get more involved with PGD, but somehow am always out of it, including my own pascal projects which I rarely get around to.
As for competitions, I really like them, but not sure I have time for any. Tried to participate twice so far and failed :( So can't say I have any preferences for them. I like themed ones as they make me try new things.
As for the engine, I'm developing my own, and it's nothing to brag about (or good or even far from complete) but I don't think I'll quit on it. Starting an open source community one could have success, and I could contribute too with some of the experience I've picked up writing my own. Could possibly even give out the code I have with a very permissive license (bsd) so parts of it my engine can be used, but not sure how much sense that'd make as parts of it are not quality code (I'm in the process of rewriting/adapting a lot of it). There are people here who surely could contribute too, so I do think it's a worthwhile idea.
Have written one article so far on the site, but I think I should write more.
User137
23-04-2014, 08:49 AM
I'll start with the competition question
Short. Rather have them more often, than one big one once a year. Also the longer the time is the bigger the quality difference per entrees can become, depending on how much they dedicate time on it.
Kudos. Even potential idea of claiming such prices sounds like trouble to me ::)
Themed or freestyle, i guess we can have all kinds of. Mainly themed i think, some might even come with ready code and art base to start from. I guess we are just looking for ways to spend time in a fun way, not here to make a selling game title in each competition.
Many ways to go about this. How about community can give each entry 1 or 2 thumbs up, but no down?
Engine is always interesting topic, i likely would want to participate in community engine if we decided to do so. I have to admit i haven't tried all the previous engines even though started nxPascal. I started programming with DelphiX at young age and it got me far. As time went by i felt limited by it though, as the needs for more GPU power came up and DelphiX was slow at that. At that time i tried what i could to look into DirectX and even made a small 3D tetris with DelphiX of that time. But it was still giving me various restrictions, and so i stumbled upon OpenGL.
That's where i first got the graphical engine freedom i was looking for, and so GLEngine was born. It is the predecessor of nxPascal, a bit like DelphiX. Had a Delphi IDE components similar to DXScene and DXTimer, and i got some nice demos done with it. But it had to end aswell... I learned alot of Pascal doing all that, and the whole structure of GLEngine seemed lacking and bad. I felt that IDE components for game engine are actually not needed. Especially with Lazarus it brings all kinds of complications to it, such as needs to rebuild the whole Lazarus.exe when adding components. Also if i wanted to support both Delphi and Lazarus, there could definitely be differences in that code, even if just between many different Delphi versions. So i completely dropped the idea of IDE integration and i have not regretted that. It actually gives me much more detailed control of the program flow too, and still being quite simple at it. In some level nxPascal was supposed to be kind of community engine, it just never got any other interested developers to make it grow. The potential is still there, and being very modular it is not restricted by anything. But i don't mind if you want to start a new one from scratch.
SilverWarior
23-04-2014, 01:44 PM
When thinking about competition I think there are two sorts of pepole.
Those who prefer short competitions, as it alows them to quickly output an idea without the need to worry to much about details.
And there are those who would like to have bigger time frame either due the fact that their knowledge might not be good enough to quickly turn some idea into code or due the fact that many pepole are quite limited with their time.
So after giving it some thought next thing came to me:
Where does it say that we need to have only one competition running at one time?
Why not runn more than one competition? Why not have anual competition with longer timeframe and a series of mini competitions?
And if we chose theme for mini competitions right finishing them might help pepole finish anual competition aswel. This might be a win-win solution for most of the pepole.
code_glitch
23-04-2014, 05:27 PM
I think what user137 said about using given assets sounds like a good idea. Something like "heres a resource pack - go make" or "heres some code/script/thing - integrate/implement" could be quite fun as we'd get a lot of very similar but very different entries. As far as a community engine, I wouldn't be a main contributor (due to lack of skill and experience more than time) but would definitely be willing to help out.
As for my experience in pascal - I learnt in pascal and sort of stuck with it and its derivatives ever since unless a project almost explicity required some other language (and I couldn't just write a .dll loader for a pascal program :D).
AthenaOfDelphi
23-04-2014, 05:48 PM
due to lack of skill and experience more than time
I think this sentiment may be felt many many of us (myself included). I look at some of the engines that people have produced (the one that springs to mind immediately is Phibermon's - sorry, I can't remember the name) and I feel like I'm some insignificant programming peon. Some of the stuff that has come out of some of the members here has been truly amazing.
But... they started somewhere... and if they are willing to chip in, provide guidance, and just generally help, then well... we will all benefit and if you feel that you lack the skill at the start, being involved seems like a good way to change that.
Improving my skills would be one thing I would definitely want out of participating in something like a community engine.
Super Vegeta
23-04-2014, 06:02 PM
As for competitions - I think it would actually do more good, instead of launching our own, to encourage people to take part in other events. For example, there's yet another Ludum Dare this weekend - go and join! Maybe if your game is awesome enough, some people will actually grow curious as to how were you able to implement it in Pascal.
Unfortunately I can't participate this time, since I have classes at my weekend uni. :(
Either way, if organising game competitions, I think one week is best - longer than a single weekend, so you don't have to rush, yet short enough not to discourage with a vision of having to write a lot of code because people will expect a large game.
I also think it could be interesting to have a non-gamedev contest - say, implement an algorithm, or maybe create some kind of game AI in .dll/.so which will then compete against each other. code_glitches ideas also seem interesting.
As for a community project, I don't know how my experience will look compared to others, but it's sure worth a try. Could be a good opportunity to learn something new.
SilverWarior
23-04-2014, 07:15 PM
I also think it could be interesting to have a non-gamedev contest - say, implement an algorithm, or maybe create some kind of game AI in .dll/.so which will then compete against each other. code_glitches ideas also seem interesting.
I was thinking about something similar but maybe not even in form of a competition.
My idea is something like this:
A comunity member creates a game related programming problem. For instance implementing some algorithm like you sad.
Also this same comunity member provides a posible solution to that problem.
The goal of the rest of the comunity is to go and try to provide as many different ways to solve the given problem.
In the end we can compare the solution, discuss and find benefits/weakneses of each of the provided solutions and maybe even ways of how to improve them in the end.
So what we would get from this is lots of different solutions (code snipects) which other pepole could use in their projects when needed. And since certain solution may not necessary the best solution for someone, pepole could go and chose that one solution which would be most suitable for them since they would have many ones to chose.
At the same time this would provide some kind of a joint knowledge of the whole comunity in one place.
Maybe some members might go even to the point of using that gathered knowledge and making a full blown tutorials out of it which would provide other members to gain that knowledge even more easily.
Rodrigo Robles
23-04-2014, 07:27 PM
Instead of make our own competitions, should be good if we compete more seriously in competitions like Ludum Dare and even Global Game Jam. This way we put more Pascal games in this compos that are dominated by new tools like unity, construct and javascript.
We can compete to see who gets the better position for a Pascal game in the Ludum Dare. :)
OBS - I'm still hard working in my pascal unfinishable game - almost finishing :D
SilverWarior
23-04-2014, 07:48 PM
This way we put more Pascal games in this compos that are dominated by new tools like unity, construct and javascript.
I think that the main problem is that we pascal developers have to do much more work to finish any of our entries into these competitions. That is mostly becouse there isn't any Unity like game engine for pascal.
You see there is a big difference when creating a game with Unity worshop becouse unity has integrated resource managing, most comon algorithms etc. or when you have to go and implement all teese by yourself and thus write many thousands of lines of code.
If I only check my code that I have written for ingame Supply and Demmand economic system I was working I see that it has over 100K lines of code and it is still not finished entirely.
EDIT: Don't get me wrong I'm not discouraging anyone from participating in those compos. If I find out the theme of one of them to be interesting enough I also might go and try. But I do realize that I have much harder task at hand.
AthenaOfDelphi
23-04-2014, 07:52 PM
I think that the main problem is that we pascal developers have to do much more work to finish any of our entries into these competitions. That is mostly becouse there isn't any Unity like game engine for pascal.
You see there is a big difference when creating a game with Unity worshop becouse unity has integrated resource managing, most comon algorithms etc. or when you have to go and implement all teese by yourself and thus write many thousands of lines of code.
If I only check my code that I have written for ingame Supply and Demmand economic system I was working I see that it has over 100K lines of code and it is still not finished entirely.
This is one of the factors that kind of puts me off... you use Unity or some other engine of a similar ilk and you have a massive head start... but the rules do allow for the use of publicly available engines and libraries, so theoretically you could use any of the engines we currently have available... or if we create a community engine... that would be open source and from what I read of the rules, acceptable :)
Get to that stage and we could get everyone who worked on the engine to crash the compy :)
SilverWarior
23-04-2014, 07:57 PM
Get to that stage and we could get everyone who worked on the engine to crash the compy :)
You mean each of us go and creates its own entry so that even if our entries are not the best we still win becouse if being in great numbers. ???
Dream come true! :D
AthenaOfDelphi
23-04-2014, 07:58 PM
Well it would certainly be a nice amount of exposure :-)
Andru
23-04-2014, 08:33 PM
Funny coincidence, just few days ago I thought about returning to development "just for fun", and here we are - topic on PGD about something like resurrecting community, hmmm... :)
SilverWarior
23-04-2014, 08:50 PM
Funny coincidence, just few days ago I thought about returning to development "just for fun"
Does that maybe mean that you are concidering to resume working on ZenGL?
code_glitch
23-04-2014, 11:17 PM
Can I just say that when the thought of a community engine dropped - ZenGL was darn high on my list of things to look at for making it. That work you did on ZenGL was pretty darn good IMHO :D
That said, I see a recurring theme here when looking at pascal and competition entries - pascal seeming less suitable for rapid competition game development than some of the other alternatives. Thus, would it not make sens to build a "system" (and by that I mean tools/framework/snippets/methodology/engine/thing) that would help make pascal more competitive in this space?
For instance, it could be an early compo of the kind Super Vegeta mentioned (with implementing things AI/algorithms/whatnot) to get the base code set. Or one could establish the base code and then launcch a compo to make use of it - which would provide a good data to develop a game engine on.
In short, what I'm saying is that 1. we have a problem in the game-sphere. Fragmentation of the codebase (how many of us have our own personal frameworks/engines/so on?), a high barrier of entry (pascal is currently seemingly unsuited to the compo game development environment) and that 2. we have a LOT of components and people. I realize how hard making an engine/API is - more so for a robust and stable system. (Hey - my prometheus engine is well known at LD. For all the wrong reasons). and finally: were pascal programmers. Our problems are not boredom, lack of projects and the like. Its lack of time. And as pascal programmers we're practical people who seem to be known for being practical people who are good at making things that work and fixing things so they work.
Just some food for thougt. After all, I tend to get kind of excited when community projects are possibly going to happen because its one of the few instances where I can work on something I couldn't do on my own with my limited abilities and the PGD community has a lot of talent that I sure wouldnt mind to see at work on something that could make everyones lives easier and help cement pascal as something that isnt THAT obsolete teaching toy people seem to think it is when reading about what it once was.
pitfiend
24-04-2014, 08:28 AM
Very interesting topic. Something I think about, is that I spend a lot of time building comercial apps. I have skills building database and GUI stuff. But when it comes to games, I feel to be 10 steps behind anyone in this community. Of course learning is The Option, it takes time and worth it absolutely. Time is a Villain.
The propose to create our own game engine, is something I look with hope, but we must think that we can also create wrappers for popular game engines. Is there an obligation to do everything in Pascal? Why? Of course pride feels good, but we are reinventing the wheel. It's round and it works fine, use it, period.
About the engines build by members, some are amazing, but have one thing in common: they are not truly game engines, most of them are more graphic engines with extra features. Please don't take me wrong, and don't be blinded by your own proud, you deserve more recognition for what you have done. On the other hand, these amazing frameworks have a big lack of documentation. To be honest, having an HTML/RTF/DOC/whatever file describing one or more class structures is far away from documentation, neither "self documented" is an option.
We are a bunch of experts programmers with deep knowledge on many development areas, we don't have a clear goal... unless we take on that proposed community project as a whole team, not just as talented programmers contributing on spare time. Maybe I'm asking to much, I suppose that all of you have daytime jobs, just as myself.
So, to compete, we need to invest (not money, but knowledge, skills, time, responsability), to cooperate, to define objectives, and then we will be ready to take on any competition!
AthenaOfDelphi
24-04-2014, 09:18 AM
Everyone who has replied... thank you for your comments. In (I think) the last 60 days, there have been 71 active people on the boards... if you're one of them and you've not posted... please do.
I want to get as many peoples views on the subject of competitions and a community project as possible.
I think I've already said this, but if you're in contact with a member of the site and they don't visit, poke them... get them to pop along if they still actively use Pascal. I'd like to try and find out why they don't visit so often, what would make them regular visitors again and all that kind of stuff. Was it the lack of a community project that put them off? Why do so few people compete in competitions?
Competitions is interesting... for the same reason (lack of time) I get the feeling prefer short or long competitions depending on who you are :) As for entering competitions that are shorter... I think SilverWarior has summed it up best... at the moment we have a big overhead to even get on a level with Unity out of the box. I'd like that to change and I'd like for more of us to enter more competitions... not just our own, but others too. Either using our engine or as a team where the rules permit ;)
It's also quite clear from this thread and from a number of chats I've had that there are those who want to learn, want to improve and a community project that includes some good quality talent (that we have here) is an excellent vehicle for doing that.
Anyhow, I want to leave this thread open a while longer to capture more comments etc. from those who don't visit regularly.
Andru
24-04-2014, 05:24 PM
Does that maybe mean that you are concidering to resume working on ZenGL?
Yep. Over the past time I upgraded my PC, so now I have support of new versions of MacOS X(with AMD it was hell developing for this OS and iOS using virtual machines...), got some experience with Direct3D 11 at work(but using C++), thought a lot about architecture and other things, new people start to use ZenGL and others continue... Also there are some improvements going on with FreePascal in trunk. So, all this something like a base for "new start", or just new episode after "to be continued..." :) But still understanding bad situation with FPC/Delphi performance, some moments in syntax which I hate(e.g. case insensitive), some language limits(e.g. my hack with PByteArray, which is bad for debugging... Lazarus just stops debugging because GDB can't allocate memory), and very bad support of mobile platforms are holding me. By "bad support of mobile platforms" I mean Xcode mess for FPC and no debugging for Android, what about Delphi - too expensive and I don't believe it at all as stable solution, but maybe I'm wrong, because I didn't try it and only read some info in internet.
Rodrigo Robles
24-04-2014, 11:11 PM
I have participated in some recent Global Game Jam and Ludum Dare. In GGJ I tried Construct and in the Ludum Dare I used Javascript. I wanted to test some new tools and my Object Pascal tools are not sharpened enough to rapid development (I thought...).
I made the games, but I think I could make it better if I did have used Object Pascal:
GGJ Construct game: http://www.cek.com.br/ggj/drink_or_die03/
Ludum Dare javascript game: http://www.futurosistemas.net/gettheseconds/
After testing another tools, my conclusions are: Object Pascal can compete and overrun the other tools. The best games I saw in this competitions were made by skilled developers in several kinds of development platforms.
So, be not afraid to use Object Pascal in this competition. To make a good game you need a good programmer, not a level editor. If you doubt you can ask about it to Jordan Mechner or John Carmack.
Super Vegeta
25-04-2014, 06:34 AM
Having made a game for LD in ObjPas, I'd say that the main problem in game jams is pre-existing codebase. Although the goal is to create a game "from scratch", it's obvious that reinventing the wheel is not the point - people are allowed to use existing libraries, and many competitions (including Ludum Dare) also allow for some personal, pre-existing codebase, as long as it's publicly available. Putting it otherwise: if you want to create a game completely "from scratch", jumping on bare SDL / Allegro, then yeah, fitting in the 48h limit can be tough. But if you have some rendering tools, data structures et cetera ready to get plugged in and put to work, a rapid start becomes much easier.
Ñuño Martínez
25-04-2014, 10:16 AM
I didn't read every messages here, but as I see I agree with most of you.
I'm not active lately. My Allegro.pas port and KOFFE engine stand still, and I don't have a lot of time. So sad. :(
Anyway, I have some stuff that may be you (we) can use in the game engine.
I'm working in a VM to be used in my current job. The "ASM" language used is FORTH-like but the idea is to build "compilers" from different languages (C-like, BASIC-like...). The VM will be too simple, but will be open-sourced, extensible and written in Object Pascal (we were wondering if a C port would be necessary, but we decided to wait until complete the Object Pascal implementation and then decide).
Also I have a fully functional state machine, inspired by "Writting Game AI by Example".
dj_sharp
25-04-2014, 01:45 PM
On competitions:
I personally don't like competitions. Always seems like a waste of time to me. Like I'm trying to prove something that I don't have to prove
About game engine:
1.
I want to try and help the rise and start showing all those nay sayers who believe you can't use Pascal to make games that they are quite frankly wrong
One can use Pascal to make games. Do you really want to prove it? What for? I personally don't feel like proving anything. There are games written in Pascal. What other proof one could possibly want.
The reason why Pascal is not widely used is not because one can't create games with Pascal.
2.
There are fewer and fewer developers who use Pascal. This is a problem. Not only this, but the development as we know it might soon cease to exist due to ever increasing pace of technological progress.
I am an experienced game developer, I probably could develop a game engine.... given infinite time.
What if most people stop using PC soon?
What if most people stop using Windows soon?
What if programming skills will be no longer needed soon?
3.
Like the author of the first post said, there are already game engines. So why create another one?
Commercial game developers can use commercial game engines like Unreal Engine. Hobbyists can use hobbyists game engines including existing game engines for Pascal.
Well, I am starting to feel that I produced too much text by now and I should stop this soon......
ACTUALLY I think that it's great idea but.... but..... at the same time it's difficult and pointless. Well, I don't know. Who is going to develop it? Who is going to test it? Who is going to use it? Too many questions
---
@Andru (http://www.pascalgamedevelopment.com/member.php?673-Andru): what if I told you that you're doing it wrong? Don't use [0..0] arrays. Don't use debugger. Make ur engine more object-oriented; right now it looks much like it's written in C.
AthenaOfDelphi
25-04-2014, 02:46 PM
Sometimes competing in a competition can provide the impetus to actually start something and more importantly, complete it. They aren't for everyone, but certainly based on the success of events such as Ludum Dare, and even some of our competitions, they are very popular. Plus, they can serve as a proving ground for game ideas and concepts.
As for the engine...
1/ You are right, there are engines out there, but they are normally one persons solo project. This means they are normally not as well documented as they could be, have a fit for a particular purpose, and people generally seem very reluctant to (a) let go of it and let other people in or (b) offer to help out because normally when people get to hear about it they are well under development. The idea (and this is based on comments and chats with various members here) is to start from the bottom, with many people involved. That way everyone can learn something (this is a key reason to do it) and the pressure isn't on one person to do everything (this can be a big factor and has probably resulted in a number of promising projects ending prematurely). And the proving it can be done comments... well, I'm just passionate about this place. I want to try and demonstrate to the nay sayers that Pascal is a viable choice for developing games and hopefully grow the community. The popularity of Pascal is an issue granted, but I've encountered people who have been ever so surprised when I told them I developed games in Pascal 'Oh, you can do that can you??? I would have thought you'd use C++ or something like that'. If new developers are coming through and they get hit with that kind of attitude, they may never give Pascal a try out.
2/ There were fewer developers using Pascal. Activity in the job market and on Delphi related sites (Stack Overflows Delphi section for example) suggest that actually the number of people using it is increasing again. With the advent of the cross platform capabilities in XE2, the language is becoming a far more viable choice again. Development as we know it is not going to stop anytime soon, people aren't going to stop using PCs anytime soon and programming skills will always be needed (someone has to write the stuff that allows non-programmers to make things). The most likely scenario you've highlighted is that the popularity of Windows will decline... I hate to say it, but whilst consumers need machines to do things like surf, watch movies, read their email, play games... there are only two real alternatives at the moment... Windows and Mac OSX. Linux, despite massive progress towards being more usable (IMHO at least) still cannot compete with the big two in terms of ease of use.
3/ The author was me and I completely stand by what I've said for the reasons I've highlighted above. Starting one as a community is a great chance for everyone who has ever wanted to do it, or has done it previously but has stopped because of the pressures of being a solo dev on the project etc., to actually do it and say 'I did that', 'I made this game with the engine I helped build'. I don't know about you, but I like that idea... I like it alot and so do alot of other people. They want to do it to be part of a bigger project (one that they probably couldn't fully complete on their own), to have the satisfaction of doing something, and because they'll hopefully get the chance to learn some stuff along the way.
Who's going to develop it? We are. Who's going to test it? Us and anyone who's using it. Who's going to use it? Us and anyone who wants to.
Andru
25-04-2014, 04:28 PM
@dj_sharp
what if I told you that you're doing it wrong? Don't use [0..0] arrays. Don't use debugger. Make ur engine more object-oriented; right now it looks much like it's written in C.
This is just a hack, and I know this. Currently I don't use [0..0] arrays for PByteArray type because of "Range Check Error". And because of this I got problem with debugger(I didn't know about this till I switched to 32-bit version of Lazarus and Windows). Why I use PByteArray? Because dynamic arrays suck. Performance is low and so on. About object oriented - I like plain-style, not because I can't use OOP(at work all my code use classes and so on), just it was more fun for me :)
SilverWarior
25-04-2014, 04:51 PM
I personally don't like competitions. Always seems like a waste of time to me. Like I'm trying to prove something that I don't have to prove
Competitions are not a waste of time! Main benefits of competitions are:
1. By participating in competitions your are actually advertizing yourself. You are showing your knowledge level to others. This can be especialy benefitial if your are trying to get a job in computer industry.
2. Competitions offer you great opurtunity to test some of your ideas.
3. By participating in competition your would probably be doing something different than you are usually doing. This could provide you with a new perspective. And that new perspective may even help you get better with your primary work.
One can use Pascal to make games. Do you really want to prove it? What for? I personally don't feel like proving anything. There are games written in Pascal. What other proof one could possibly want.
It is not question wheter if it is posible to make games in pascal. It is question of it is posible to make games in pascal which are of todays standards? And we all know that game standards have changed greatly in the past few years.
There are fewer and fewer developers who use Pascal. This is a problem.
That is true. But answer me this. Is there more buisniess application developers or game developers in computer industry?
Answer is that there are more game developers in computer industry than buisniess developers. Game developers are those who drive the whole computer industry.
But if you look at pascal comunity you will realize that the above fact is not true. There are actually more buisniess pascal developers than pascal game developers. And that is sending out the message that pascal is more suited for buisniess application development which then draws away lots of potentional developers due the fact that game development is most popular.
So the main purpose of PGD is to show that pascal is as suitable for game development as it is for buisniess application development as this would atract more pepole into using pascal.
I am an experienced game developer, I probably could develop a game engine.... given infinite time.
I'm not an expirienced game develoer but given infinite time I could develop a game engine on my own. Heck given an infinite time I could develop a whole OS ;)
What if most people stop using PC soon?
What if most people stop using Windows soon?
Haven't you noticed? Objective Pascal is no longer limited to Windows and PC platforms :D
What if programming skills will be no longer needed soon?
I can figure out only two posible scenarios for this to happen:
1. We somehow develop an AI which is capable of reprogramming itself. We are doomed when this happens.
2. A catastrofic event causes all electical devices to stop functioning. We are also doomed in such scenario.
Like the author of the first post said, there are already game engines. So why create another one?
Commercial game developers can use commercial game engines like Unreal Engine. Hobbyists can use hobbyists game engines including existing game engines for Pascal.
Why do big game development studios develop their own game engines and not use the existing ones?
Becouse no matter which game engine you are using there is a large posibility that sooner or later you will hit the limitation of that game engine. So if you are using some third party game engine you need to contact the original developers and ask them to help you get rid of that limitation or you have to live with that limitation.
But if you are developing the game engine on your own then you can get rid of that limitation on your own.
ACTUALLY I think that it's great idea but.... but..... at the same time it's difficult and pointless.
Being hard it doesent mean it is pointless.
As for those of you suggesting that we simply go and make headers to use most popular game engines like Unity:
While this might seem better solution in the short run it is not necessarily better solution in the log run.
As I have sad above you are limited by the functionality of that game engine. Even worse due to language differences you might be even more limited due to these language differences.
As it is with most third party libraries/components debugging can be a nightmare. You coučld encounter a bug and not know if it is cause by your code or by third party game engine. Now if you have game engine written in Objective Pascal you might convince the author to share the code with you so you can literally debug both your and engine code and thus find the bug wherever it is. But if the game engine is written in another laguage you can forget about this.
So far I haven't heard of any utility that might alow symuntaniosuly debuggin one application whose components are designed with multiple programming languages.
SilverWarior
25-04-2014, 05:02 PM
@Andru
I totally agree with you about dynamic arrays. I mean which idiot though about idea that best solution to increase the size of dynamic array is to double it's size?
Imagine this: You have a byte array with 1024 items in it (using 1 KB of memory) and then you add just one item to it and it's size is doubled. Imagine that you have 1GB sized array and you add one new item. Utter stupidity.
Have you ever sonsidered using TMemoryStream?
You would probably want to override the Read/Write mothods so that you won't need to specify current position using before calling them but include the position as aditional parameter. I belive it could be done and it should provide quite good performance.
Andru
25-04-2014, 05:06 PM
@SilverWarior
Answer is that there are more game developers in computer industry than buisniess developers.
Can you give any proof? Because I doubt :) Game industry is big, but I know how big companies(I mean how many developers) are involved in developing software and other "business" things. Probably you think like this only because you see a lot of games around, but there is huge amount of software not available for average people.
AthenaOfDelphi
25-04-2014, 05:10 PM
@SilverWarior
Can you give any proof? Because I doubt :) Game industry is big, but I know how big companies(I mean how many developers) are involved in developing software and other "business" things. Probably you think like this only because you see a lot of games around, but there is huge amount of software not available for average people.
I think the point that Silver is making is relating to the relative proportion of developers using a particular language. If you consider C++ there are alot of people using full stop and a certain proportion of them will be using it for developing games. If you then consider Pascal... the proportion using it for games is significantly smaller. I agree with that assessment.
User137
25-04-2014, 06:43 PM
@Andru
I totally agree with you about dynamic arrays. I mean which idiot though about idea that best solution to increase the size of dynamic array is to double it's size?
Imagine this: You have a byte array with 1024 items in it (using 1 KB of memory) and then you add just one item to it and it's size is doubled. Imagine that you have 1GB sized array and you add one new item. Utter stupidity..
Idiot you say... Now, i don't know how the arrays actually work, but lets assume like you say that dynamic array doubles it on power of 2 margins.
Imagine that you have [0..0] pointer array of size 1024 and you increase the size by 1 for 10 times in a row. Dynamic array makes only 1 memory allocation of 2kb, but pointer array makes reservation total over 10kb (1025, 1026...1034)! In addition to that, it's like a puzzle game in the memory - having odd sized memory blocks of random 1023, 1050 etc are harder to organize than if the blocks are evenly sized.
(Oh, what also happens on array resizing, is existing memory copied to new array. Again Setlength() would win by big margin.)
I haven't noticed much of a performance difference at all if you use dynamic arrays vs pointer arrays for texture memory. For most arrays you don't ever need to resize it, and when you do, dynamic arrays might win in performance. Previously i have known that TList follows the memory doubling method, but i am not sure about setlength(). And there are likely some limitations in higher amounts of memory, smaller reservations.
code_glitch
25-04-2014, 09:21 PM
Imagine that you have [0..0] pointer array of size 1024 and you increase the size by 1 for 10 times in a row. Dynamic array makes only 1 memory allocation of 2kb, but pointer array makes reservation total over 10kb (1025, 1026...1034)! In addition to that, it's like a puzzle game in the memory - having odd sized memory blocks of random 1023, 1050 etc are harder to organize than if the blocks are evenly sized.
(Oh, what also happens on array resizing, is existing memory copied to new array. Again Setlength() would win by big margin.)
As an aside on this note, I'd be very interested in any tests/information anyone has on this. I use a lot of dynamic arrays that seem to behave themselves. My assumption is that its written that way to avoid causing memory fragmentation for memory sizes that scale linearly across all orders of magnitude (ie. there are x allocations done to get from 1KiB to 1MiB and another x allocations to get from 1MiB to 1GiB). I agree it could be better done. The question is what does it understand by 'allocate'? Is it allocating virtual, private or some other 'kind' of memory so that it has the memory needed/mapped/allocated but the OS can use it for other things until the array grows to that size?
SilverWarior
25-04-2014, 09:21 PM
Ups. I must admit that I have mixed arrays with Lists :-[
SilverWarior
25-04-2014, 09:25 PM
As an aside on this note, I'd be very interested in any tests/information anyone has on this.
Iztok Kacin is trying to create better dynamical array by slicing it into smaller pieces. You can read some info on this on his blog here: http://www.cromis.net/blog/2013/03/is-it-possible-to-build-a-better-dynamic-array-presenting-sliced-array/
He also offers several comparion tests between his and regular dynamic arrays.
de_jean_7777
25-04-2014, 09:27 PM
Afaik dynamic arrays will only double in size only if you try to resize them. And it's existing size + new size. Resize will allocate new memory, copy over data and free the previous memory. In case the new size is smaller it is possible no reallocation will occur. Does not take up double memory, just the difference between new and old size, with a temporary need for additional memory while the array is reallocated. It does lead to memory fragmentation more easily. Also, the same will happen if you use a pointer to an array, and re-allocate the memory yourself. The same process happens, and dynamic arrays should not be that much slower than manual memory management. With dynamic arrays the compiler manages the memory and there is a small overhead (reference counting and what not). In any case, best to do as little resizing as possible. An idea for a benchmark.
Andru
26-04-2014, 10:40 AM
Memory management is not a problem. There was something else... but now I can see only speed down when Range Check error is enabled(and this is normal). So, there is one more reason to update my engine ) And I changed my mind a bit about Pascal compilers :) But I didn't test 64-bit version yet, e.g. FPC generates more instructions when there is a code using dynamic arrays, maybe there was something not optimal for 64-bit.
update: Oh, now I remember, there were problems with throwing data via arrays between dll and application, and supporting C/C++. With time everything can be forgotten :)
dj_sharp
28-04-2014, 11:46 AM
Speaking of contests;
I now suddenly remember why I don't like contests. Because I participated in a contest once and I got disqualified because I broke the rules. Sort of. I don't think that I should describe in detail what exactly happened; the point is:
If one wants to find a reason to disqualify other person, he|she will undoubtedly find one.
On the other hand, for me following rules always seems unbelievably hard. It is difficult to pay attention to all those rules. Especially when there are two sets of rules: some general rules and rules specific to the ongoing contest. I always miss some points. And when I try to follow contest rules I just can't help but think "hey, I don't even get paid for this".
And one more thing: I believe most contest organizers allow participants to use so called game creators. But I'm a programmer, I can't draw art for gaems, I can't write music; I am only good at writing code. So I really feel like I can't compete with ppl using game creator software who's also good at drawing and such; it just seems so pointless
SilverWarior
28-04-2014, 01:14 PM
And one more thing: I believe most contest organizers allow participants to use so called game creators.
Those programs are usually refered as Game Worskhops.
But I'm a programmer, I can't draw art for gaems, I can't write music; I am only good at writing code. So I really feel like I can't compete with ppl using game creator software who's also good at drawing and such; it just seems so pointless
Well I'm much like you more or less a programmer (average one).
I'm not good at grawing hraphics,
I haven't even tried composing music. Well did once and couldn't do it. End result was complete crap.
But none of the above discouraged me in participating or trying to participate. So far I trieed twice but both time ended up with nothing to show as all I managed to did is some code without any GUI. So I never submited my entries.
Infact failing to finish any of my entries actually gave me motivation to go and start making myself tools which might help me in the future:
- texturing program where I could create ingame graphics in a way that I think would suite me
- I developed an idea for a GUI library which should make GUI development much easier. Goal is to make library work with basically any graphical engine provided that you make suitable eader interface between my library and graphical engine.
On the other note PGD competitions doesn't alow the use of readily made Game Workshops. You can use existing game engine provided that it is written in Objective Pascal. And that is the main reasony why I hapily try participating in them as I know that I athleast have some chance in being good.
I suggest you check the previous competitions and their rules to get better idea on them.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.