[20:06:27] * Metalcore424 sets mode: +m [20:06:39] everyone except mispunt, and he can /msg me [20:06:54] alright, chirho, take over [20:07:00] Right, I'd say we're in action [20:07:01] eh? [20:07:08] I didn't call this meeting [20:07:14] I did more or less [20:07:24] so shall I take the honours? [20:07:25] well, you're the project leader, chris [20:07:30] if you want [20:07:41] .....you can take the honors, at least ;) [20:07:47] cool :p [20:07:58] * FishyTombe puts guitar down [20:08:06] I'm afraid that the project shows signs of decision-fear [20:08:12] * Metalcore424 puts drumsticks down [20:08:19] ^ Agree [20:08:22] there's been quite some talking about stuff but we need to decide [20:08:23] yup [20:08:30] excuse me - i seem to be lagging again [20:08:35] -> [ohrihc] PING [20:08:40] have anything been decided at all? [20:08:42] so my first point is: what platforms do we want [20:08:47] mac :D [20:08:54] game boy :D [20:08:58] Nothing, Bjarni. [20:09:01] Please be serious [20:09:10] I am serious [20:09:12] Mac, Windows, Linux... [20:09:14] windows, *nix, and mac [20:09:18] [ohrihc PING reply] : 0.562 seconds [20:09:27] while decisions need to be made, I don't think that platform decisions will be helpful [20:09:49] mainly because it will tie us down [20:09:50] is this a competent decission? do you know the differences between mac and win/linux code? do you know that this limits you choice of libs? [20:09:55] it is helpful, ohrihc [20:10:04] I think you guys should think about the internal structures... [20:10:12] if we know what platforms we want to support we can infer a decision of game engine [20:10:17] Let's talk about the music! [20:10:25] >_> [20:10:32] it's all well and good saying "we're going to support platforms X, Y and Z", but it's easier to introduce support for new ones than it is to remove support later [20:10:41] I think the music can wait. Game music without a game is not that cool [20:10:55] can we please stick to the topic that's been discused now (which is platform supprot0 [20:11:05] We should prolly just focus on Windows for now since that's what most people use [20:11:16] remember that if we say we're going to support a platform, we're stuck with it [20:11:19] chirho won't like that :D [20:11:29] ohrihc, you have to make a decision [20:11:30] :P [20:11:53] if you don't stick to things you can't produce anything [20:11:56] well, we're definitely going to support windows and linux [20:12:05] In this particular field, I don't think we need to make a decision [20:12:07] I think we should start by supporting windows and linux [20:12:19] because that is the platforms most developers use [20:12:25] That's probably all we need [20:12:26] we don't need to be bogged down in which platforms to support. We need to be moving forward [20:12:29] Apart from Mac [20:12:39] how do you see the deelopment of a game engine if you let in the middle what platform it will work on, ohrihc [20:13:04] I can port it to mac very quickly if it works on linux [20:13:20] Hyronymus: We need to be thinking logical design at this stage. [20:13:34] Not physical design [20:13:38] mac is unix too, so it might even work with an unmodified makefile [20:13:51] If you seperate the the os calls, no problem in porting [20:13:52] So, say this: you stick to windows only for now... and in a while you want to support linux or anything else too and you find out that you used so much windows-specific code. Then you find out you can't port it that easily to other platforms and that would be a waste I think [20:14:06] considering we have so many people here, we might want to start thinking about actually coding [20:14:07] exactly, HEXerium [20:14:07] * FishyTombe agrees with Hex [20:14:23] HEXerium already made the first mistake [20:14:36] and that is, eis_os [20:14:40] he thinks in using windows calls [20:14:45] HEX seems to have echoed my point about tying yourself down to a platform list [20:14:50] Let me just point something out [20:14:57] go ahead FishyTombe [20:14:57] Currently we're talking about support for Windows, Linux & Mac [20:15:06] yes [20:15:11] What other operating systems do people use apart from those 3? [20:15:20] class os->dosomething [20:15:25] solaris is scarce [20:15:29] Those are the 3 operating systems that nearly everyone uses [20:15:35] So why don't we just do it for those 3? [20:15:52] rob uses os/2 >_> [20:16:09] doesn't matter [20:16:12] os/2 can surely use opengl [20:16:14] let me share with you guys what I fear what will happen if you don't make a platform choice [20:16:19] From what my limited technical knowledge can make of the last 15 minutes, it's quite easy to port between the 3 [20:16:21] eis_os: that is not my mistake. I just suppose that happens when you say: we are going to develop for this platform and maybe we will support others later. [20:16:28] Go ahead [20:16:32] hyr [20:16:37] you start developing a game with no special platform in mind [20:16:51] then you have the engine 'done' and want to port it but oh dear [20:17:01] every platform needs their own mods [20:17:03] HEXerium: thats why I say to stick to specifc platforms is the wrong way... [20:17:08] Hyr: That's not a problem [20:17:20] it will be [20:17:33] I still say go for the big 3 [20:17:36] what is a problem is when you say you're going to support a fixed list of platforms, and suddenly you can't add one [20:17:37] cant you just say that you keep the plattform decission open as long as possible? And make the decission when you have to and know what the alternative to supporting X would be ? [20:17:38] because without a doubt there will be things that don't work on either of the other platforums [20:17:58] *platforms [20:18:19] Believe it or not, you can actually develop without a target platform [20:18:36] I think (fear) it's underestimating the different requirements for platforms if you don't decide on it [20:18:42] Write code that adheres to standards, and you'll be surprised how well it works with minimal changes [20:18:56] Now I'm a complete novice, but surely if we started coding with Windows, Mac & Linux all in mind it would reduce the effort needed to port to different platforms [20:19:20] The point is that, if coded properly, porting shouldn't be an issue in the first place [20:19:21] ohrics, the problem are the librarys... try porting DirectX to Linux mh [20:19:29] and even without, zugspiel hasn't to much changed to start on win32 [20:19:30] any experienced programmers wanna shed their light in the discussion too? [20:19:36] chochmah: then we don't use DirectX, obviously [20:19:47] ohrics, that was an extreme example [20:19:54] I think we should use SDL [20:19:55] I can see [20:20:07] bjarni, why? [20:20:13] works on most (all?) platforms [20:20:25] things like SDL we know to work on lots of different platforms [20:20:35] ehm, the engine should work with 3D right?, so opengl is needed [20:20:36] I think we should stop arguing and just decide what to do [20:21:00] target openGL though SDL and you have openGL [20:21:03] this isn't arguing, this is arriing at a proper decision, FishyTombe [20:21:03] If we have to re-code parts of the game to make it portable, so be it [20:21:03] It's not as if we're working to a deadline [20:21:24] for threads you can use pthreads, works under win32 [20:21:28] but to summarize [20:21:44] sticking to SDL wouldn't need a platform choice to be necessairy now [20:21:44] I still think that we're jumping the gun with platform decisions [20:22:05] we don't even have a logical design to implement [20:22:21] ok, but was the summary I gave correct? [20:22:22] ahh, now to the real main questions [20:22:38] in a way, yes [20:23:00] If SDL isn't platform-specific that's probably the ideal choice, yes? [20:23:08] I notice that the main criticisms about lack of platform choice have come from non-programmers :) [20:23:10] I think so [20:23:19] Because then we can bypass this whole discussion about deciding on a platform to support [20:23:19] ohrihc: true [20:23:35] thanks [20:23:50] Chris - :p [20:24:01] * HEXerium (~HEXerium@vader.xs4all.nl) Quit (Signed off) [20:24:14] the fact that I don't program C++ doesn't mean I'm a total program geek [20:24:14] hmm [20:24:19] * HEXerium (~HEXerium@vader.xs4all.nl) has joined #TEmpire [20:24:20] * L sets mode: +v HEXerium [20:24:24] anyhow, time to decide [20:24:41] shall we choose the SDL approach? [20:24:43] 30 mins for nothing [20:24:47] :/ [20:24:49] Decide what? [20:25:00] I will go for SDL [20:25:18] I think we should, from my limited knowledge that seems to be the route of least fuss [20:25:54] I hear noone is against [20:26:15] next point then (on ohrihc's request): logical desing [20:26:23] ok, people, how it look like for me: [20:26:31] * chochmah is listening [20:26:36] you want to use as most platform indepent [20:26:52] you want 3D, right? [20:27:03] sofar so good [20:27:10] I would suggest: [20:27:26] Create an OS wrapper for easy porting stuff [20:27:45] the OS Wrapper (maybe it uses SDL, maybe not) will setup the screen and stuff [20:28:09] will pass the OpenGL to the main loop. [20:28:44] If you want to port, you will port mostly the OS wrapper, or you have endian problems somewhere in it [20:28:52] * FishyTombe hasn't a clue what's going on [20:29:15] eis_os: apparently sdl can deal with that [20:29:30] endianness, that is [20:29:38] If a programmer thinks he makes endian dependent code make a comment or directly and #if branch.. [20:30:33] I won't try to put the GL Stuff into an wrapper, I think it makes the stuff to slow [20:30:36] if you want [20:30:44] I'm gonna go, I'll leave you guys who understand all this to discuss it [20:30:47] Take care, guys [20:30:51] * FishyTombe (Tombe_The_@modem-1172.cougar.dialup.pol.co.uk) Quit (Read error: EOF from client) [20:31:32] how succesful is that approach for porting, eis_os? [20:31:33] the seperate the display from the logic [20:32:06] Hyro? obviously 100% (if it can be portet at all) [20:32:07] Problem: more overhead... [20:32:40] Irrlicht is a good example of porting, but at bad speed :/ [20:33:32] we want a fast game [20:33:36] Ok, back to the main goal, internal logic [20:33:42] yes [20:33:53] 1. Point. Terrain Style [20:33:58] Hex? Square? [20:34:23] Full 3D (like Trains&Trucks) [20:34:38] I followed the hex discussion in Zugspiel [20:34:44] I feel for hex [20:34:55] hex is possible but not advisable [20:34:57] I vote for hex. While I don't know how hard it would be, i think it would be much smoother and efficient [20:35:06] square would be the easiest to code since it will make the map (x,y) [20:35:06] from a mathematical point of view, squares are more logical [20:35:08] more work, more complicatet, some unsolved graphical issues [20:35:20] * eis_os should try to get a job as game designer :o [20:35:33] (likes plattforms close to each other) [20:35:43] hmm.. why not a 3D terrain :> [20:35:55] what is the good stuff in hexes? [20:36:03] mh guys I tryd hex... so how do you think you could solve the problems I could not solve? [20:36:33] Jpl: main reason I can say it's really unhandy to build on it... [20:36:37] hex is limited to 8 ways [20:36:43] ok, pro's of hex please [20:36:50] more ways [20:36:54] but easy to build a way on it.. [20:36:59] problem: Station Buildings as example [20:37:01] smoother terrain [20:37:12] terrain need alot memory [20:37:28] that's would constitute a con, eis_os [20:37:33] question at first [20:37:35] do you want cliffs? [20:37:51] Answer has to be yes [20:37:52] (that would mean buildonslopes aswell) [20:37:55] .....yes [20:38:03] * Hyronymus wants cliffs [20:38:10] cliffs, cuts, slopes... [20:38:18] the whole assembly [20:38:24] then full 3D or squares... [20:38:36] of course we'll have slopes, this isn't TG [20:38:40] pro's of full 3D [20:38:52] Think of the way that RCT allows you to have immediately adjacent tiles at different levels [20:39:11] a way to accomplish the effect would be very nice :) [20:39:15] what you mean with a full 3D? there is also terrain points.. [20:39:16] * Bjarni have never played RCT :( [20:39:22] thats the goal of WinRT2 :) [20:39:24] pro's of full 3D please [20:39:38] Indeed. Define "ful 3d" [20:39:41] more realistic [20:39:46] more easy landscape [20:39:50] not sticking to squares [20:39:54] you can use a 3d engine [20:40:01] nice landscape [20:40:04] nice curved tracks along splines [20:40:07] and what about con's [20:40:15] er ... [20:40:17] splines instead of predifeines tracks [20:40:17] not very userfriendly [20:40:28] cant place tracks / buildings exact [20:40:32] you have to make auto ?fang) [20:40:33] Define "full 3D" before we go any further [20:40:44] you end up rebuilding entire network because a track does not fit in between the others [20:40:50] we run out of memory ;) [20:40:52] wait a sec: [20:40:57] anyone wanna give an answer to ohrihc? [20:41:07] if you want a game in the TT spirit I dont think you can use full3d besspline landscape [20:41:13] in trains and trucks tycoon, you can end up with two tracks, which you though was connected, but they aren't [20:41:26] ohric, trains and trucks tycoon [20:41:40] Never played it [20:41:45] ouch :( [20:41:45] Define, not relate. [20:41:51] you will not do that in TT, because it's squares [20:41:52] ohric, no tiles in one word [20:41:54] DEFINE :) [20:42:09] "no tiles" is two words [20:42:12] ohric, Berzier Surface [20:42:23] a fluid landscape with 'undefined to tiles' track laying possibilities [20:42:27] I'm heavily against that approach [20:42:48] It would be very nice, but more than likely a pain to write code for [20:42:57] agreed [20:43:00] * Hyronymus agrees with ohrihc [20:43:04] http://3dtt.running-gag.de/modules/Magnish/3DTT%20Alpha%207/TRAIN.JPG [20:43:12] and, to steal Josef's favourite, "a lot of work, for not very much benefit" [20:43:19] I dont think it would be nice [20:43:20] squares are the easiest to code as I said before [20:43:36] Bjarni? ah.. sure? [20:43:40] pro's of squares please [20:43:50] http://3dtt.running-gag.de/modules/Magnish/3DTT%20Bugs/tmcap36.jpg [20:43:58] pro's of squares please [20:44:01] discrete [20:44:05] simplicity [20:44:08] nice overview over everything [20:44:11] easy to plan [20:44:17] easy to implement [20:44:20] (rather) [20:44:33] user-friendly [20:44:36] con's of squares? [20:44:40] lol - "running-gag" :) [20:44:45] simplicity [20:44:52] another pro of squares: they are mathematically sound [20:44:52] everything is in a x,y grid, so it's easy to see if there are room for 3 or 4 tracks [20:44:52] limited directions [20:45:17] how limited? In the ground plane? [20:45:35] TT [20:45:41] line in TT [20:45:42] there are 8 directions in TT [20:45:55] are smooth curves possible for instance? [20:46:00] Hyro yes [20:46:03] grpahically [20:46:04] but more complicatet [20:46:11] graphically* [20:46:29] not realy [20:47:16] and can squares be smoothed somewhat so that the terrain looks less like your first kit of building blocks? [20:47:20] smooth curves along a set of squares should still be possible [20:47:30] Transport Gigant is based on squares [20:47:36] and has smooth curves [20:47:41] (as Example) [20:47:42] but only 90 degrees [20:47:45] but no height level [20:48:01] ok, RCT has squares and smooth curves... [20:48:06] it has projected height, like Age of Empires [20:48:10] but be warned that the representation of a smooth curve and the actual squares it takes up are different [20:48:18] trainz and I believe MTS too uses splines [20:48:20] ohrihc, that's true [20:48:27] on a square based tereain [20:48:30] terain* [20:48:40] broodje: but how user friendly [20:48:41] so squares seem to be the best choice [20:48:44] e.g. look at the footprint of the curves on RCT [20:48:51] ohrihc: I know... [20:49:01] * Hyronymus never played RCT [20:49:03] eis_os realy user friendly, but maybe not for tycoon game? [20:49:07] not sure [20:49:15] broodje: but those squares are massive, and populated with lots of different objects [20:49:21] you just klick and klick again [20:49:26] true [20:49:29] each tile is something like 1km^2 [20:49:33] no! [20:49:34] lol [20:49:37] (at least in MSTS) [20:49:43] 10x10 meter for terain [20:49:47] well, that good for MSTS [20:49:53] broodje: I think the square are actual the same as what I try to do for WinRT2 [20:49:53] and much much smaller for objects [20:49:56] but were not patching that [20:50:05] so who's in favour of squares? [20:50:10] for TE [20:50:13] here [20:50:14] MSTS has tile quads or something.. [20:50:16] * ohrihc raises a hand [20:50:21] yes? [20:50:36] he means he's pro squares [20:50:42] what say you, eis_os? [20:50:46] I'm not sure, but I lean towards squares [20:51:05] squares, (ok I say blocks, because that what I will internal use in WinRT2) [20:51:19] well, I feel safe to summarize that we choose for squares [20:51:27] agreed [20:51:40] yes [20:51:41] (with cliffs) [20:51:51] with cliff(hanger)s [20:51:59] :p [20:51:59] (You know I am not involved in TEmpire you know? ) [20:52:07] YES [20:52:10] ...oops [20:52:12] caps [20:52:29] eis_os, I invited anyone who feels he has something to share [20:52:41] But I have some experience :) [20:52:43] ohrihc, anything next on your logical desgin list? [20:52:43] Metalcore424: there is no reason to start yelling :P [20:52:43] eis_os: This is a GFDL channel, so you can only use the information in free projects :P [20:52:54] GFDL? [20:52:57] So, we know we're doing square terrain [20:53:13] Metalcore424: I was trying (and probably failing) to be funny :) [20:53:25] stay on topic please [20:53:41] Are we going to revisit the class structure that was pulled up previously? [20:53:57] is there any indication that we should? [20:53:59] HMM? [20:54:02] dammit [20:54:13] Well, it is a part of the logical design [20:54:29] what was it/.? [20:54:32] -/. [20:54:38] There's some UML lying around somewhere [20:54:46] lemme look for it [20:54:52] oh yeah, ythe UML [20:54:52] ohh, somewhere is alread bad... [20:55:06] http://ttforums.owenrudge.net/viewtopic.php?t=6692 [20:55:09] look for posts by epistax [20:55:11] wow [20:55:14] twas fast [20:55:20] I'm good :) [20:56:13] Is anyone familiar with the CRC approach? [20:56:25] CRC? [20:56:32] shed a light on it, ohrihc [20:56:49] CRC is Class-Responsibility-Collaboration [20:57:03] I like responsibilites [20:57:04] Usually done with some 6x4 index cards for convenience :) [20:57:10] btw. any need for website? [20:57:20] desperately [20:57:22] can you hang on for a while, Jpl [20:57:28] yeah, but wait [20:57:30] * Jpl is hanging 24/7 [20:57:34] Jpl: Would be useful. I'm arranging hosting already. Back to topic ... [20:57:56] Jpl: I think a website is not needed before the code starts to show anything [20:58:13] back to CRC explanation please [20:58:27] ok [20:58:28] In the traditional, paper model, the index card represents a class, and lists the things it does (its responsibilities), and the other classes it needs ot interact with (collaboration) [20:58:45] that makes sense [20:58:58] I was about to ask what a class is built up off [20:59:35] BAsically, people suggest classes, responsibilities are discussed, a few new classes introduced, some discareded, and you typically come up iwth a useful set of classes at the end of it [21:00:12] so episxtax and hellfire went through that when they made their UML? [21:00:21] *epistax [21:00:22] they might have done, or they might not have done [21:01:04] You'd have to ask them about that [21:01:15] though a CRC session with 2 people is rarely effective [21:01:28] sofar I see only one repsonsibility, correct (in the media class) [21:01:50] ? [21:02:07] Ah, no. Those diagrams are UML class diagrams [21:02:16] oh, ok [21:02:36] but you want us to decide on classes? [21:02:41] class at the top, then methods and parameters though I forget which is in the middle and which is on the bottom [21:02:55] in a way, yes [21:03:25] an OO design should be rather like a model [21:03:38] I assume you have some classes in mind? [21:03:45] TrainClass [21:03:49] for example :) [21:04:01] A couple, but I need to know whether we're going to bounce those around here or not [21:04:15] why not? [21:04:15] CRC workshops can be pretty lengthy in real life, let alone over IRC :) [21:04:51] are there other important things that need discussion? [21:05:03] coding style? [21:05:09] * zuu (~leif@as11-4-1.ld.bonet.se) has joined #TEmpire [21:05:12] maybe we can discuss them before starting a 'CRC workshop' [21:05:16] user interface? [21:05:34] Hyronymus: the whole point of a CRC workshop is to discuss the classes :) [21:06:02] Do we have any other points that we need to deal with before we bury ourselves in virtual index cards? [21:06:20] don't repeat me, ohrihc ;) [21:06:33] coding style, as Metalcore424 suggested [21:06:57] I think we've got some stuff on that already, but sure - go ahead [21:07:09] excuse me for a moment - nature calls ... [21:07:15] what about it Metalcore424? [21:07:23] after all it was your suggestion :) [21:07:52] I don't really have any ideas about it, i just felt it needed discussing [21:08:08] I guess someone is logging? [21:08:32] I can log, if you want, I can have them on net [21:08:35] someone is :) [21:09:04] ok, because I won't spend my time about coding styles, thanks alot [21:09:14] Happy discussing [21:09:20] * ohrihc (~chris@parcelfarce.linux.theplanet.co.uk) Quit (Quit: Hey! Where'd my controlling terminal go?) [21:09:33] ohh, and try to get started soon ... [21:09:41] bye [21:09:42] we try [21:09:48] * eis_os (~user@xdsl-213-196-254-73.netcologne.de) has left #TEmpire [21:09:52] * ohrihc (~chris@parcelfarce.linux.theplanet.co.uk) has joined #TEmpire [21:10:05] need for logs available on internet? [21:10:38] after the meeting [21:10:50]