|
Socoder -> Concept/Design -> Sustainable Development |
|
| Fri, 21 Dec 2007, 07:53 | |
HoboBen
|
No, I'm not talking about climate change (though I did go on the recent demo!), I'm talking about software development. Basically my project (written in Cobra) is starting to get quite complex. The program might not do a great deal yet to look at, but under the hood the engine is doing quite a lot to give the project a lot of potential. So I'm compiling a large engine, with several units/includes, and when it launches the first time it reads and parses probably close to fifty scripts now. So it's taking noticeably longer to compile+run. Not excessively, but I can't just write two lines and recompile it like I used to (bad habit!). I'm just wondering how I'll continue sustainably. How did the folks who wrote Half Life 2 cope? That takes like ten minutes to get started on my machine. Surely they couldn't compile it over and over and run it over and over while each time waiting for it to compile and ten minutes for it to run. Did they implement new features by entering code blind to the effects? Did they have a 20-core processor running at 100Ghz per core to work with? How do large projects work from the point of view of the person who has to write parts of it? Any good links, book recommendations, etc. appreciated! -=-=- blog | work | code | more code |
| Fri, 21 Dec 2007, 08:40 | |
Jayenkai
|
I think one thing that might help is using lesser versions of the assets. Most test-bed levels use the plain checkerboard textures, and simple box style areas. For something like HL2, it'd be a case of "First build the engine using simple things, then build the levels" where the levels are loaded in seperately, so you could tweak, reload into the engine, and keep doing it that way... keeping the engine running the entire time. Any future minor engine bugs/feature tweaks would be easier to implement, but you'd have to be sure what you're tweaking.. I guess it's basically how those really freaky bugs turn out every so often. Someone tweaks one little thing, and something seemingly unrelated somewhere else throws a hissy fit! -=-=- ''Load, Next List!'' 
|
| Fri, 21 Dec 2007, 09:21 | |
|
HoboBen
|
Cheers Jay, My only two levels are both quite basic, but I've put the more basic one first now  I suppose HL2 was very intensive on the graphics - I played at 640x480 with all the graphics turned off/minimum and I still MAV'd after ten minutes! But it's a good idea that any tweaks can be done with the engine still running. This is possible in my project already when I'm just tweaking the levels (not that there's much in them!). It's when there's a change in the way things are processed that I have to recompile. I suppose if I just get a little further with the engine, the only changes should just be scripts anyway. Perhaps I'm being to perfectionist anyway. AFAIK there's no bugs with my code at all, cause I do everything to test each new line, basically! Maybe I should leave all this to a dedicated testing period later. -=-=- blog | work | code | more code |
| Fri, 21 Dec 2007, 11:21 | |
power mousey
|
I'm sure they coped really good. en.wikipedia.org/wiki/Half-Life_2 |
| Fri, 21 Dec 2007, 14:25 | |
JL235
|
You don't write a couple of lines and then test. That's not how real projects work. You design and plan the project, then you implement and use automated tests to see how correct your code is. Sometimes this is a key aspect of the implementation or a whole phase of it's own after it has been built. Unit tests help to break down validation considerably because you are testing one component rather then the whole solution. This can then be tested as a whole after it is complete. Analyzing how good or bad the game and levels are however is a completely different ball park. There was an interesting interview on Channel 9 about usability. One practice that was talked about was monitoring how users play through levels in games. The developers can then analyze this to show where they die the most often (is it too hard?), where they take the most time (are they stuck?) and just generally see how they play. Also IDE's like Visual Studio and NetBeans will point out bad practices and errors in your code as you write removing all compile time errors. |
| Fri, 21 Dec 2007, 15:53 | |
Scherererer
|
Also, a lot of the big projects are split into many different assemblies (dll's) so that a team's work is isolated to their dll, and you only need to update that one dll in the project and it will still run. For java its a little different because they can get away with each team having a set of class files and not need to have dll's; but they might use jar's instead.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Fri, 21 Dec 2007, 16:27 | |
|
Nolan |
A lot of major games uses scripts. This gets rid of compile time completely, once the core of the game is done, because you just edit the script and run the .exe, which reads and executes the scripts on the fly.
-=-=- nolandc.com
|
| Fri, 21 Dec 2007, 16:55 | |
|
HoboBen
|
I think, perhaps, I have a lot to learn! I do know some of the theory of unit then system testing, and how projects should be organised. But all my actual programming has been mostly self taught, so I've had no real experience in real-world team development. What's the best way to continue, do you think? Find a software job, go to uni (ugh, that's so expensive now!) or will the skills develop through experimenting with projects like this (and getting the odd helping hand from you guys!)? -=-=- blog | work | code | more code |
| Fri, 21 Dec 2007, 17:37 | |
|
Jayenkai
|
Can you see yourself doing this as a job? Could you see an 18+ month project through to completion without getting bored 2 weeks in? I know I couldn't. So, as much as it's a disappointment to about 99% of my family, sitting here making silly games is what I'm destined to do! And using Trial+Error, Tweak+Compile style coding is working well enough for me |edit| But don't let me put you off! By all means, go for broke, it's just nice know that no matter what happens, you're still going to be making games, whether it be paid or otherwise! |edit| -=-=- ''Load, Next List!''
|
| Fri, 21 Dec 2007, 18:50 | |
|
HoboBen
|
I think I'm too under qualified to do it as a job. I don't think I can feasibly go to university even if I wanted to. But if it'll develop my programming skills, I dunno. Maybe. I'd honestly be happy stacking shelves three days per week if I could continue programming as a hobby, only I even feel a bit under qualified for that (the hobby)! -=-=- blog | work | code | more code |
| Fri, 21 Dec 2007, 19:56 | |
|
Scherererer
|
You're probably more than qualified enough to go to university for programming. There are some people that go without knowing much at all, perhaps never even heard of things like "C++"... You go to university to learn, and that's what this is all about anyway; learning.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Tue, 25 Dec 2007, 09:19 | |
Afr0
|
 You don't write a couple of lines and then test. That's not how real projects work. You design and plan the project, then you implement and use automated tests to see how correct your code is. Sometimes this is a key aspect of the implementation or a whole phase of it's own after it has been built. Unit tests help to break down validation considerably because you are testing one component rather then the whole solution. This can then be tested as a whole after it is complete.Analyzing how good or bad the game and levels are however is a completely different ball park. There was an interesting interview on Channel 9 about usability. One practice that was talked about was monitoring how users play through levels in games. The developers can then analyze this to show where they die the most often (is it too hard?), where they take the most time (are they stuck?) and just generally see how they play. Also IDE's like Visual Studio and NetBeans will point out bad practices and errors in your code as you write removing all compile time errors.  So you're saying they're paying someone to come in and plan the project before the programmers do anything? o.O I always thought the programmers made up a couple classes on a whim, like I always do when I need an extra one or three... -=-=- Afr0 Games Project Dollhouse on Github - Please fork!
|
| Tue, 25 Dec 2007, 17:18 | |
|
Scherererer
|
I think you'd be surprised how much planning goes into a lot of these projects. When its just one person, sure, easy enough to just throw in another class. But, when you have to manage that many people, it makes it a lot easier on the team as a whole to put that extra bit of planning in at the beginning so that they don't suffer by the end.
-=-=- YouTube Twitter Computer Science Series: Logic (pt1) (part 2) (part 3) 2's Complement Mathematics: Basic Differential Calculus
|
| Tue, 25 Dec 2007, 18:38 | |
|
JL235
|
If your building a computer system for a nuclear power plant, airplane or traffic control system then the requirements, specification and design are all usually planned separately from the implementation. These days it is not unusual for a game to have around 100 developers so planning is essential. Even extreme programming requires some level of planning and design, even if it is as the solution is being developed. Making up extra stuff on a whim can be good when prototyping ideas but not so much when your working in a group. Personally the way I try to plan group projects is to model the problem in terms of abstract components describing what it does. Then to start converting those components into descriptions of classes, with this again converted into a more specific interface. People in the team are then assigned those classes to work on with the idea that since we all have the interface of a class with a description of what those methods do, I can then use those classes in my code before they have been implemented. How the classes work internally is no concern of mine as long as externally it works exactly how it has been described. Adding functionality and changing how components of the system work on a whim will then just lead to confusion, disorganization and so problems. As a result I try to think long and hard about what design changes I will be making and try to prototype it first before doing that. It's also important to minimize the changes as much as possible. |
|
|
| |||
|
| ||||