#19386 - mr_schmoe - Sun Apr 18, 2004 9:13 pm
When I search for game development or game design I get one of two things. Either I get information about hardware programming. Stuff like how to get sprites on the screen and 3d graphics, or I get stuff about game design. The kind of stuff that has nothing to do with actual coding. Level design, rules, storyline, etc. What I need is one step up from hardware coding. Like how to orginize data such as player and enemy position and the atcual data for the levels. Also collision detection. I mean I can write the fuction that can detect the collision, but that's only if all the data is global and I just stuff the function call in the main game loop. But that's bad coding pratice. Anyways, I think you get my confusion. Anyone have any ideas?
#19397 - sajiimori - Mon Apr 19, 2004 3:50 am
I totally feel your pain. I've never seen anything that offers good, complete advice on high-level game code structure. There's the usual garbage about specific methodologies like OOP and metaprogramming, but nothing that goes beyond that to look at the big picture.
You can browse the Quake source or something, but what I'd really like is a broad case study of a real, working game, in a guided tour format.
#19398 - zazery - Mon Apr 19, 2004 3:55 am
I'm actually faced with the same problem. I've come up with a game design document well over 100 pages, a great story, gameplay and some sketches. However when I'm programming my game engine I just don't know what to do so I try to figure out everything first.
I realized that when trying to figure it out, I could be actually programming it and solving problems along the way. I read something about creating games that made me think, hey instead of researching how to make a game, I should just do it and if it doesn't work out keep fixing it till it does.
There are many ways to program a good game engine. Eventually you will work through your design to find the perfect solutions to your problems. That's the way I'm currently doing and it's working out so far.
I'm sure there are articles on gamedev.net about setting up a scripting engine (I read it but I forget where it is, sorry) and then you can also read some articles on Gamasutra. I hope someone will write an article or tutorial on this issue since it appears to be not talked about enough.
If I have the time I might write something about organizing different aspects of an engine once I implement them in my game.
#19399 - poslundc - Mon Apr 19, 2004 4:06 am
People have heard me say this a million times, but it merits repetition: it's all about finite state machines.
Once you understand the principles behind FSMs the task of assembling a game from its various components will seem a lot less daunting.
Dan.
#19424 - Miked0801 - Mon Apr 19, 2004 7:59 pm
Ok, this looks like a fun topic.
There are 2 places you can begin and both need to be in place before any real game development can occur.
1. You need to create/buy/borrow a base system engine before anything else is possible. All the fancy documents, techniques, and code samples in the world won't do you any good if you can't malloc some RAM, play some music (this can come a bit later), get input, create a sprite, or create a background and place it on screen.
2. Once you have a good functional base engine, then you need a thourugh idea of what you want to create. It sounds like you guys already have this part so I'll talk a bit more about the first topic.
What exactly is a base system engine? It's your starting line for creation of any game. The core components that will allow you to quickly prototype an idea on target and follow through till your game in complete. It will follow you from prjoect to project saving you development time and energy. A good base engine is worth its weight in gold. It at a minimum needs to have the following functionality:
A Memory manager (GCC malloc may be good enough, though we use our own.)
An input management system - something that collects all input an makes it available to the rest of the engine. If you ever want to do multi-player stuff, you'll need to keep that in mind when creating input so that each potential player input can be read by all players.
A base state handling system - something that allows you to switch from screen to screen while allowing a simple way of passing information from state to state. This is your base Finite State Machine that controls your entire game. Once created, it becomes very simple to add various menus, splash screens, dialogs, etc. via only table entry to your game. Just set it up so that each state has entry/exit code and a tic function that allows the game to move between states. I can't stress how important it is to get this system right. You will spend a lot of time creating functionality for each state. If you code this right, none of your time should go towards working around this system. This probably should be the first thing created after memory management and input routines are created.
A way to handle BG/OBJ VRAM. Ideally, this system allows graphics to be loaded and unloaded dynamically, but at first, it can statically load graphics and keep track of where everything is so that things are not overwritten and ASSERTs can be thrown if you run out of space. It will of course also need a clear routine to start over again on a new level.
A system for displaying BG graphics. Ideally it allows, with 1 or 2 function calls, a way to display any BG on screen and give the VRAM parameters to the VRAM manager.
An Assert system. Get this running as early as possible and it will save your butt over and over.
An Actor system. This is a bit vague so here's what a basic actor system should be able to do: Create and destroy objects that may or may not have a graphic (BG or OBJ) associated with it. It should have methods for moving them autonomously around the game world (set velocity, position, accel, etc.) and have the ability for each actor to dynamically run different code depending on what is needed of them at the time (either through a large switch statement or function pointers.)
This is enough to get things up and moving, but to make a game, you also need the following: They must be able to collide with other actors (needing a collision system which I'll elaborate on in a bit.) They also need an animation system so that any animations they need to run can be self or globally controlled. These 2 additions I believe give all that is needed for a base actor system. Other system will evolve with time as the need(s) arise.
A collision sub-system: A sub-system of the actor system that allows actors to report to each other and to the system when they detect a collision with each other. Some real thought needs to be in here as this pontentially is one of your big CPU eaters if you aren't careful.
An animation sub-system: A set of functions that allows an actor to autonomously switch between various frames of animations from an animation table, have embedded commands for at least looping and later SFX calls, kill commands, and visibility/invisibility commands.
A simple sound/music system. Nothing simple about this I know, but there are a number of solutions in GBA land for this already to choose from. At first it just needs to be able to play a song and an SFX at the same time.
With the above, you can get most basic single-screen games up and running with little trouble. After these system are in place, here's a few other systems that will need to be created for more complex games:
A scroll system. This allows you to move around a world that is larger than your current screen. Almost all games will need one of these and these also can eat a lot of CPU if you aren't careful.
A random number system: Keep it simple and you'll be amazed at what it can do. There are a number of good system already out there for this so you shouldn't need to spend too mcuh time here.
A text display system: You can get by without this with sprite letters, but its gives you much more flexibility to be able to dynamically create text on the fly and load it in BG or OBJ space.
An intelligent interrupt exchanger/handler. Something that makes it real easy to change interrupt vectors on the fly for various effects.
A centralized math module for basic vector functions and fixed point arithmetic amongst other things.
Of course as you get further into things, other systems will become aparent. With the secondary tier of systems mentioned, you'll be able to create any 2D or isometric game needed. To add 3D, you need to extend your actor system an extra dimension and add a rendering module.
Hopefully, this is the level of detail you guys were looking for. I can go into more detail or less is you want on various topics.
Mike
#19431 - zazery - Tue Apr 20, 2004 12:21 am
Wow this is exactly what I've been searching for. It gives me the exact summary of what I need to do in order to make a game engine for the GBA. I've got a few questions and some of the topics explained futher but you did a great job explaining it already.
| Quote: |
| 1. You need to create/buy/borrow a base system engine before anything else is possible. All the fancy documents, techniques, and code samples in the world won't do you any good if you can't malloc some RAM, play some music (this can come a bit later), get input, create a sprite, or create a background and place it on screen. |
Do you suggest this for GBA development as well? I'm personally going to write my own engine because I feel that you will really understand how the GBA works and will be able to implement new effects as well. I think it's a good idea to start with a simple engine to learn how they did it. Are there any recommendations for a simple engine (GBA or not) to look at?
I agree with your point about the engine should be a quick prototyping system. I remember reading about Zelda: OoT and how they used the Mario 64 engine to prototype it.
| Quote: |
| A way to handle BG/OBJ VRAM. Ideally, this system allows graphics to be loaded and unloaded dynamically, but at first, it can statically load graphics and keep track of where everything is so that things are not overwritten and ASSERTs can be thrown if you run out of space. It will of course also need a clear routine to start over again on a new level. |
I would really appreciate it if you talked about this in more depth. I'm trying to figure out what the best way to manage your BG/OBJ VRAM. Including the pallete switching. How does a sprite know what pallete entries it can use and what it can't? Organization of the pallete would naturally come under this. If possible some pseudo code or some theories would be nice.
Is there any place I can read up on Assert systems? I've found very little even after using google. From my understanding an Assert system is when you give priorities to tasks or objects and if there is no time or space then it is ignored. If I'm wrong please correct me. What aspects of the GBA would you check to see if there is room, pallets, OAM, tiles etc?
My second last question is about the actors system. How would you determine the priorites of movement? I know visually it all looks like it's working at the same time but eventually some actors will be dead before other actors. Ex. 4 people in a small room, one player lights a bomb, all players blow up, and player 4 wins because of lower priority. Would that be a factor in an actor system?
Now my last question is short one. Do you recommend having the current map a global variable?
Thanks for taking the time to make that long post.
Eric
#19770 - sgeos - Sun Apr 25, 2004 2:16 pm
| zazery wrote: |
| Is there any place I can read up on Assert systems? I've found very little even after using google. From my understanding an Assert system is when you give priorities to tasks or objects and if there is no time or space then it is ignored. If I'm wrong please correct me. What aspects of the GBA would you check to see if there is room, pallets, OAM, tiles etc? |
| http://dictionary.reference.com wrote: |
as?sert
tr.v. as?sert?ed, as?sert?ing, as?serts
1. To state or express positively; affirm: asserted his innocence.
2. To defend or maintain (one's rights, for example).
|
That is an assert. Applied to programming, you want to make sure something is true.
If we say ASSERT(sprite_count < SPRITE_MAX), we want to make sure that sprite_count is indeed less than SPRITE_MAX. It always *should* be below SPRITE_MAX, but I suspect that you have been around long enough to know that people mess up and things are not always the way they should be. Here is a basic assert system:
| Code: |
#include <stdio.h>
#define STRING(a) #a
#define ASSERT(a) \
do { \
if (!(a)) \
assert_fail(__FILE__, \
__LINE__, STRING(a)); \
} while (0)
void assert_fail(char *file, int line, char *cond)
{
printf("%s:%d: ASSERT(%s) failed\n", file, line, cond);
}
int main(void)
{
int x = 22;
ASSERT(x < 10);
ASSERT(x < 20);
ASSERT(x < 30);
return 0;
} |
When run from the command line, we get:
| Code: |
$ ./test
test.c:20: ASSERT(x < 10) failed
test.c:21: ASSERT(x < 20) failed |
Gee, x was not less than ten. x was not less than twenty either. I wonder how that happened. =) The __LINE__ and __FILE__ constants are just the slightest bit useful for things like this.
A page on the __LINE__ "Manifest Constant"
Page on the stringizing preprocessor operator #
You'll want to replace printf() with some sort of print_text_to_gba_screen() routine.
| zazery wrote: |
| Now my last question is short one. Do you recommend having the current map a global variable? |
I recommend wrapping it up in a module and making it a module level variable. That brings me to my question- what generic module breakdown do you recommend for the base system engine?
-Brendan
#20728 - sgeos - Sun May 16, 2004 4:52 am
| zazery wrote: |
| Is there any place I can read up on Assert systems? I've found very little even after using google. |
I just ran across this article on asserts.
-Brendan
#20732 - zazery - Sun May 16, 2004 6:08 am
Wow what a great read. I never knew the power of using asserts in my code. I'll definitely create an assert modual in my engine. I now understand what was the point of your macro assert function.
I've been desiging my engine on paper and in my head. I'll hopefully have some to work on it. Thanks for explaining asserts. It came in handy for my CS AP exam.
#20865 - keldon - Tue May 18, 2004 9:23 pm
go here http://www.dkauk.com/klogic and go to projects --> RPG game (darksoul)
now download the source
since this is barey even a game you will get a good enough idea of a game engine and how to store data
forget structures and OOP .. think end result and work your way top down and bottom up. Yes that sounds confusing but it means think of your problems from the top down, IE the higher level aspects that are simple, and program bottom up, IE code from the lower levels building up
do this also:
> practice game engines (like my demo RPG one)
> then practice displaying larger maps with more than one room
> then you've got a game engine - almost
now following them steps you will realise that all that is required to make the game complete is a complete engine to make it easy to build a game without having to write new code for every room
For a game engine - click on concepts and go down to the bottom. It speaks about animation briefly - that is the basis of a game engine, an event happens, do the code for it. In fact by working a basic sequencer - also for download, but unfortunately in ASM - you will have the glue to creating a game engine
does that answer it for you?!??
#21479 - mr_schmoe - Sat May 29, 2004 9:16 pm
In response to the long post by Miked0801. I like what you had to say. It gave some really good points about game development and I really learned a lot from it. However, what I need now are idea's on how to design the engine. The core of the game. The part where the action takes place. The part I believe should but near the top just before the game states section (titlescreen, menues, splash screen, etc.) I don't care about graphics, sound or the title screen right now. I don't even have a title for the game yet.
What I'm struggling with is how to structure the elements of the game such as the player character, the monsters and the environment such as tree and the ground, etc; and also how they interact with each other. I'm not taking about collision detection. I can do collision detection. I'm taking about the level between the hardware coding like graphics and sound and the title menu. I now that's a big area, but I think that's the area that's talk about the least.
Anyways, as I was writing this post, the wheels in my head started turning. I'm going to start another post about my phylosophy on game development. I'll put a link here after I'm done.
_________________
How many boards could the Mongols hoard, if the Mongol Hored got bored
#21485 - sajiimori - Sat May 29, 2004 11:16 pm
| Quote: |
What I'm struggling with is how to structure the elements of the game such as the player character, the monsters and the environment such as tree and the ground, etc; and also how they interact with each other.
|
So you're asking how to design data structures for your game elements. Some of what I say here will seem obvious, but I'm just trying to expose the sorts of things we often take for granted.
First, list all the types of objects, as you started to do above (player, monster, tree, ground).
For each object type (or "class" if you like), list the things that distinguish each instance from the others.
Let's say the things that distinguish one tree from another tree are its species and its position in the world. You'd make a data structure that holds representations of those qualities (such as numeric coordinates and an enumerated value), and that's the Tree structure.
What about a unit of ground? It's qualities might be position and surface type. If you designed the structure in the same manner as the tree structure, each piece of ground would carry a pair of coordinates and an enumerated value representing the surface type.
A terrain map of an area would then be an arbitrarily arranged list of ground pieces, where each carries its position. If all the pieces fit together in a grid, there's a lot of redundancy with this solution, so you can make their position implicit by sorting them into a 2D array. Then you can remove the coordinates from the Ground structure and you'll just be left with an enumerated value.
The point is: when in doubt, start with a full structure carrying all the attributes of each object, then you can make some of those attributes implicit when it makes sense.
If you want to take advantage of the fact that some types of objects share certain qualities (like a size and position), you can make them share the subset of their structures that they have in common. The parts that differ can be encapsulated in a seperate structure, to which the common structure carries a reference.
This can be a hassle in statically-typed languages, so many such languages have built-in mechanisms to automate the process ("inheritance" if you like). Note that using this technique increases the complexity of the program, so don't use it until its benefit outweighs the cost.
Be prepared to rearrange your data structures as improvements become apparent. For instance, if you decide you want shrubs in your game, and you notice that the structure is identical to that of Trees, you might rename the Tree structure to Plant. But then, in anticipation of the addition of other immobile objects that are quite similar, you might decide to instead rename the structure StaticObject.
Like good prose, good code requires revision. You can start with a simple process as described above, but as you work, always keep in mind the question: "How can I make this simpler?"
#21500 - keldon - Sun May 30, 2004 1:58 am
Good comments and suggestions by Mike and Sajimori. I'd personally go by Sajimori's advice by start looking at games.
When I first got interested in the gameboy; I learned its hardware, but was still young. So since I had thousands of classic games under my wing, I played them and wrote down everything that made up the game. So metal gear had 'hotspots' that woke up guards.
It's not rocket science, we all do it when we attempt to cheat a game by avoiding an enemy that really *should* get you. Only in this case you have to second guess the programming behind it and what structures may be used.
I've included a bit of this in my website, but looking at my original notes, I feel I should have included a lot more.
But for you to do, unless you'd like to see some examples from us, is to really look at all types of games - especially games that are different. What's different between, say Zelda DX's control and Zelda, Link to the past's engine for taking your around the levels. Also think about how those out-run racing games work; it's most certainly not 3d, nor difficult.
In terms of prototyping, there are two types of it; throwaway prototyping and evolutionary prototyping. Throwaway prototyping is where you create a simple solution to your problem to understand how to tackle it, you then throwaway the solution and start again. Evolutionary prototyping is where you build on your prototypes until you have a finished product. But for now, start with throwaway prototyping until you are happy with what you have got.
Working on clones can help you to understand how to tackle a few problems at an early stage. RPG's tend to prove the biggest problems as items can be present, or not - and at the beginner stage everyone has their own methods.
#21509 - sgeos - Sun May 30, 2004 7:03 am
| mr_schmoe wrote: |
| What I'm struggling with is how to structure the elements of the game such as the player character, the monsters and the environment such as tree and the ground, etc; and also how they interact with each other. I'm not taking about collision detection. I can do collision detection. I'm taking about the level between the hardware coding like graphics and sound and the title menu. I now that's a big area, but I think that's the area that's talk about the least. |
It sounds like need to learn more about software architecture. I have not read any good books dedicated to the topic yet. I'd be happy to hear any suggestions.
| keldon wrote: |
| It's not rocket science, we all do it when we attempt to cheat a game by avoiding an enemy that really *should* get you. Only in this case you have to second guess the programming behind it and what structures may be used. |
You don't need to figure out what method the programmers of the game used, but rather *a* method that would work.
I was playing a strategy game for the PSX (SD Gundam G Generation F, Japanese). The enemy units take turns in order. On some maps it looks like they act in plane, Y, X order-- except that "boss" units moved last. On another map the enemies were set up in a ring and act in spiral order. It looks to me like they are on a linked list and act in that order. From a editor/stage loader stand point, that looks like a great way of doing things. Knowing that that would work fairly well, I don't care how it was actually programmed.
| keldon wrote: |
| In terms of prototyping, there are two types of it; throwaway prototyping and evolutionary prototyping. Throwaway prototyping is where you create a simple solution to your problem to understand how to tackle it, you then throwaway the solution and start again. |
In general, you want to finish a throwaway prototype quickly. It can be buggy and crash if the walks off the map, etc. It's going to be thrown away. Throwaway prototypes can be written in a different language on a different platform if that will get them done faster. Take the general organization, improve the areas that are lacking, trash the prototype and either start the real thing. (Maybe prototype again if that seems beneficial.)
-Brendan
#21515 - keldon - Sun May 30, 2004 10:56 am
| sgeos wrote: |
| It sounds like need to learn more about software architecture. I have not read any good books dedicated to the topic yet. I'd be happy to hear any suggestions. |
I could attempt to rewrite some of my uni notes - I'm not allowed to give you copies of the slides, but I can give you my own interpretation =). But not right now because I've got a lot of work to do this week, plus I'm going to slovakia for another week, I'll then be coming back to face a board meeting, etc. But I will be spending my next week working on my website so you may be lucky, it's just that I've also feel I should also discuss game structures and tackling game design problems also.
#21565 - Miked0801 - Tue Jun 01, 2004 1:02 am
Finite State Machines :)
#21571 - poslundc - Tue Jun 01, 2004 1:50 am
Sounds like someone's singing my old tune... ;)
Dan.
#21597 - Miked0801 - Tue Jun 01, 2004 6:23 pm
It's a catchy melody - one I've been singing for years myself :)
#21635 - sgeos - Wed Jun 02, 2004 5:59 am
| keldon wrote: |
| I could attempt to rewrite some of my uni notes - I'm not allowed to give you copies of the slides, but I can give you my own interpretation =). |
That would be fantastic. Also, did you use a text? If so, what was it and what do you think of the book? It looks like "Software Design Patterns" is the magic catch phrase- I'm looking for a good book on software design patterns.
-Brendan
#21643 - keldon - Wed Jun 02, 2004 11:42 am
Discrete Mathematics, Computer Science, Numerical Computing, Algorithms and Data Structures
Sometimes you are lucky enough to get a direct link to a university, but my one brushed up so you can only access with a password. But I still find a few nowadays.
#21671 - sajiimori - Wed Jun 02, 2004 8:57 pm
http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/
This book is a good starting point for learning about design patterns. It's heavily oriented toward strict OO design, but most of the ideas are applicable to more flexible methodologies. Exceptions include patterns that only exist to work around the limitations of object-orientation (like Singleton).
Be warned, though, that applying these patterns will make your code longer and less direct (though not necessarily slower). I designed a game engine based on the ideas in this book, and it resulted in a ridiculous number of 1 or 2 page classes that were mostly scaffolding. Interesting lesson, though. =)
#21672 - poslundc - Wed Jun 02, 2004 9:12 pm
| sajiimori wrote: |
This book is a good starting point for learning about design patterns. It's heavily oriented toward strict OO design, but most of the ideas are applicable to more flexible methodologies. Exceptions include patterns that only exist to work around the limitations of object-orientation (like Singleton).
Be warned, though, that applying these patterns will make your code longer and less direct (though not necessarily slower). I designed a game engine based on the ideas in this book, and it resulted in a ridiculous number of 1 or 2 page classes that were mostly scaffolding. Interesting lesson, though. =) |
That is one of the things I do not like about OO... is that it gravitates towards code bloat. OOP is great for a lot of things and a good way to help wrap your head around many design concepts, but it is not a panacea!
The same could be said for design patterns... they try to formalize a methodology the way OO does, but if the peg is square and the hole is round you wind up working for the methodology instead of the other way round, and code usually bloats as a side effect.
I guess the point of this post is that design patterns - like any concept in computer science - are worth learning, but for heaven's sake please don't become a slave to them.
(And yes, I realize I am the one always lauding on about FSMs as if they were God's gift... but the same applies to that as well. For example, I wouldn't try to incorporate the GBA-reset key combination into a control FSM design when an interrupt can handle it so much more elegantly.)
Dan.
#21675 - sajiimori - Wed Jun 02, 2004 10:01 pm
I agree.
One thing to keep in mind about the aforementioned bloat-causing patterns is that they often pay off (in lines of code) as you scale up. (This is old news to you, Dan, but maybe it'll be of some use to somebody.) For instance, let's say you're writing a program that processes some data and prints a report in some format. You decide that it's simplest to write the output as you are doing the processing.
Now let's say you want to be able to choose between 2 different report formats. You consider a few options:
1) Write a complete processing path for each output format.
2) Set a variable that specifies which format to use, and switch on it whenever you print some output.
3) Create an intermediate data structure that represents the processed data, and then make output modules for each report format.
You immediately toss out option 1 because it involves way too much repitition -- all the processing code appears twice.
When choosing between options 2 and 3, you mentally estimate how much code would be required for each, and decide that the total switching code will be smaller than the overhead for defining and building the intermediate data structure.
Now let's say you wanted to add another output format. How about twenty more? At some point, the overhead for the intermediate structure will be overcome by the redundancy in the switching code.
Of course, that's just considering length. Adding new formats is obviously much easier when they are in seperate modules, rather than scattered thruout the program.
Lastly, considering readability: Highly modular designs are harder to understand by reading them directly because sequences of operations are spread across different modules. More direct designs are harder to follow while reading because many concerns are intermixed. Either way, a higher-level description is helpful while reading.
#27407 - Mucca - Tue Oct 12, 2004 1:25 pm
#27414 - poslundc - Tue Oct 12, 2004 2:27 pm
I am convinced that UML was invented by middle-managers who wanted something they could put as a requirement on job applications and that programmers could put on their resumes instead of simply needing to prove that you could design things properly.
Dan.
#27415 - Mucca - Tue Oct 12, 2004 3:07 pm
Of course to an elitist it seems software design should be a natural ability, but if someone's confused about how to approach design, simple techniques like noun extraction, relationship mapping, use-case a&d etc. are invaluable. You're right that knowledge of UML et al doesn't necessarily mean that one can design programs, but it doesnt hurt. At the very least it allows people to communicate clearly on the subject.
Anyway apologies for digging up old thread, I realised too late. It wont happen again.
#27418 - poslundc - Tue Oct 12, 2004 4:00 pm
| Mucca wrote: |
| Of course to an elitist |
...?
I prefer to think of myself as a meritocritist. I studied and practiced software design for 14 years to get as good at it as I am, thank you very much. :P
I have no more of a problem with UML than I do with any other technology that gets commercially hyped and treated as some kind of technological panacea. Nor do I think it was inappropriate to bring up in this thread. I just don't like the software industry, and UML is a symptom of that.
Dan.
#27424 - keldon - Tue Oct 12, 2004 8:16 pm
UML should not be taken too heavily or lighly. It will lead to a complete object oriented approach to the untrained eye. Not anything against OO, because it's a tidy approach to some problems.
But many things simply can not be modelled by simple OO techniques, or even a FSM. The key is understanding these and using them to your own devices. Any lecturer will tell you that, for example, SSOP at most times can be altered to your own needs; which is why you have ASSOP.
Realise that these modelling tools are tools at heart, and you'll have to hammer a nail with a chisel and phillips if the screw don't work, or on a similar note, perfect OO in ASM, and a speedy app in Java =D.
To finalise, the rebirth of ASM (or so they call it) is fuelled by the sluggish bloatware Top Down Language approaches. But a majority of the problems ASM coders have is bottom up coding and a bottom up approach completely. Having a top down approach to a bottom up language can really work wonders. Just remember OOD came long before OOP
#27432 - sajiimori - Tue Oct 12, 2004 10:42 pm
I can't say how or why UML became such a buzzword, but visual languages in general are handy for providing a bird's-eye view of a program, at any stage of development.
When the benefits of a highly modular and hierarchal design outweigh the benefits of linear code, there's no reason to fear going the abstract route if there's an overall visual description nearby to alleviate the disorientation that readers feel when they've got their noses to the screen.
#27439 - Abscissa - Wed Oct 13, 2004 1:36 am
I often consider UML to be something that's mainly necessary just because there's so many under-qualified "programmers" out there in the IT world. But then I look at something like the GCC source, and wish I had some sort of visual way of making sense of it all ;) I question UML's necessity in developing code, but it can be very helpful when trying to learn a huge API or some other very large codebase.
#27443 - keldon - Wed Oct 13, 2004 2:43 am
UML is a powerful tool to use when creating an API, it's seamless with the code too. And apps like Eclipse and Together allow you to integrate coding and design together.
Like I said before, whatever tool fits the bill. Also when you're making changes to code, you'll thank UML (or a similar modelling tool, or Eclipse if you have it).
#27451 - sajiimori - Wed Oct 13, 2004 4:26 am
Visual languages are helpful during development for the same reasons they're helpful when learning an existing system. They tend to orient your mind toward the big picture.
keldon, can you qualify the statement that UML is "seamless with the code"? Do you consider this something that seperates UML from other visual languages? Does the code have to be in a language similar to Java for the seamlessness to be apparent? Do you have to have special IDE support for UML to get this quality, or are things still seamless if you draw your UML diagrams on paper?
Edit: Being such an old thread, I've actually changed my opinion about object orientation since I lamented the file/class explosion it supposedly caused. I now blame C++. =) The problems I encountered can be addressed (to varying degrees) by multimethods, implicit or dynamic typing, smarter compilers, and more modern languages that don't require header management.
#27453 - keldon - Wed Oct 13, 2004 4:53 am
Oh sorry, that was poor communication on my part. With Eclipse and the together plugin, your code generates UML diagrams, and your UML diagrams generate clases, variables, etc. It is a further step to OOP being able to be identical to the design by tying in design and code where actions to one effect the other ( and there's a word our lecturer uses for this, when he doesn't just call it magic ).
We're using eclipse with Java, but it apparently works with C/C++ and even cobol.
But even with paper UML diagrams, your classes inheritance, composition, etc. will look the same. So your stage from design to code is seamless as your UML designs fulfill your code also. But Eclipse is a sexy piece of kit, it even lets you look up what methods make access to a particular variable, and shows you where you've edited code since you last opened eclipse.
#27454 - sgeos - Wed Oct 13, 2004 5:27 am
| keldon wrote: |
| But even with paper UML diagrams, your classes inheritance, composition, etc. will look the same. So your stage from design to code is seamless as your UML designs fulfill your code also. |
Design to code is one way. I only see it as seamless if nothing needs to be changed. UML is very bird's eye, but unless the code and diagrams update one another I refuse to believe it is seamless. =)
I think UML is a good way of giving a person an overview of the components in a system.
-Brendan
#27456 - sajiimori - Wed Oct 13, 2004 6:24 am
He said Eclipse will generate UML diagrams from code. Does that satisfy your requirement?
Anyway, the interaction is not so magical if you think of UML diagrams as code written in a visual language, rather than "just a design".
The distinction between design and implementation is slowly fading as we move to more expressive languages and more powerful IDEs. Calling something a "design language" only suggests that it isn't rich enough to describe all the aspects of the system (i.e. you have to switch to something else to finish the "implementation").
#27498 - sgeos - Thu Oct 14, 2004 5:09 am
| sajiimori wrote: |
| He said Eclipse will generate UML diagrams from code. Does that satisfy your requirement? |
Certainly.
| sajiimori wrote: |
| Anyway, the interaction is not so magical if you think of UML diagrams as code written in a visual language, rather than "just a design". |
There is no silver bullet that will magically create code. If there was, programming would suddenly become unskilled labor.
-Brendan
#27500 - sajiimori - Thu Oct 14, 2004 5:59 am
Umm did I say there was? Or did you just feel like throwing that out there? =)
#27505 - keldon - Thu Oct 14, 2004 8:36 am
| sgeos wrote: |
There is no silver bullet that will magically create code. If there was, programming would suddenly become unskilled labor.
-Brendan |
*cough* Visual Basic Programmer *cough*
#27525 - sajiimori - Thu Oct 14, 2004 7:09 pm
Exactly -- programming doesn't have to be magic to be easy. The VB approach is to make brain-dead-simple ways to do a finite set of common tasks.
#27529 - sgeos - Thu Oct 14, 2004 7:47 pm
| sajiimori wrote: |
| Umm did I say there was? Or did you just feel like throwing that out there? =) |
Do I strike you as the type that just randomly throws stuff on the table? =P
-Brendan
#27532 - sajiimori - Thu Oct 14, 2004 8:13 pm
Alright, then maybe you could explain why you responded in that way to my seemingly unrelated comment.
#27570 - tepples - Fri Oct 15, 2004 9:25 pm
| sajiimori wrote: |
| Calling something a "design language" only suggests that it isn't rich enough to describe all the aspects of the system (i.e. you have to switch to something else to finish the "implementation"). |
On 8-bit microcontrollers such as the 6502 CPU emulated by PocketNES, anything but assembly language is a "design language" because the architecture just isn't conducive to compiling HLL code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27572 - sajiimori - Fri Oct 15, 2004 10:23 pm
Yes. In context, my statement was referring to how things are becoming, not how things were.
#27585 - sgeos - Sat Oct 16, 2004 1:44 am
| sajiimori wrote: |
| Alright, then maybe you could explain why you responded in that way to my seemingly unrelated comment. |
I had a strong reaction to the word magical and it seemed like the thing to say at the time?
-Brendan
#27666 - Miked0801 - Mon Oct 18, 2004 5:21 pm
Alright, dead thread. Everyone knows that FORTRAN is the programming language of choice for all things!
Bad troll, no cookie :)
#27670 - sajiimori - Mon Oct 18, 2004 6:26 pm
Hey, at least it's not C versus C++ again. ;)