UML Diagramming - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Game Programming Fundamentals (/forum-7.html)
+--- Thread: UML Diagramming (/thread-10022.html)
UML Diagramming - hughnivers - Apr 26, 2012 03:38 PM
I'm new here but I hope to start participating a lot very soon. I'm hoping to wrap my head around objective-c and any other technology I might need to get my project up and running.
I believe my first step should be to create a UML diagram to get a big picture view of all of the game objects and how they will interact. I'm struggling with knowing how to break things down into discrete objects. Right now I'm just circling around my own ideas, thinking about where to dip my toe in first.
RE: UML Diagramming - OneSadCookie - Apr 26, 2012 04:06 PM
Yeah, don't ever use UML for anything, ever.
RE: UML Diagramming - MattDiamond - Apr 26, 2012 06:33 PM
The only reason to use something formal like UML is if you need to communicate with a large team, and that's the tool everyone has already agreed on. Or a client demands it as one of your deliverables.
Don't overthink this. Pick a tool you already know how to do. Jot down types of objects and what you think each one should do on scraps of paper or a whiteboard. Break big vague actions into smaller actions or pseudocode. Then turn those into methods or messages, along with arguments that will need to get passed. Be prepared to erase a lot.
I go through pages of scrap paper sometimes, but sometimes I use a whiteboard, a word processor/outliner, or a mind map tool (Freemind, specifically.)
Frankly I do a lot of it by feel as well. I'll write the code one way, get it almost working, then see all the problems and ugly details and rework it. Unless it's for a 30-day contest, in which case I ship it. :-) There's a lot to be said for deadlines like that: they force you to concentrate on getting the game mechanics working, and not worry so much about making the code indentations line up, or redesigning your objects to be slightly more efficient or to remove an ugly global variable..
The main things is to get it working. Yes you want to plan ahead and break down the project into manageable pieces, but don't think that once the diagram is perfect that you are almost done. You won't even be halfway. Better to get something working quickly that you can demo.
RE: UML Diagramming - OneSadCookie - Apr 26, 2012 08:00 PM
Diagrams are useful as a way of explaining what is already coded to someone else. They're very seldom useful as a way of designing anything.
RE: UML Diagramming - SethWillits - Apr 26, 2012 08:21 PM
This being your first real exercise in programming, rather than trying to design the internals correctly the first time by doing a bunch of diagramming and all that, just focus on getting things to work, one piece at a time. You can evolve it into better designs over time.
So rather than trying to design the entire game up front, just figure out how to get things drawn on the screen, then add to it little by little. At different points along the way you can step back and look at how things are organized, determine what a better way might be, try that, and then apply the knowledge you gained to the next few things you add to the project.
RE: UML Diagramming - funkboy - Apr 26, 2012 09:45 PM
You will screw up.
You will architect your code in a way that, months from now, will fall somewhere on a scale between inefficient and ridiculously awful.
Don't worry about doing this.
These are really important things for a beginning coder to learn who shows signs (like you are) of planning something out in extreme detail for their first project.
I am not as anti-diagramming as the rest of the folks here.
You need to have some idea of what your game is going to be.
And *especially* make user interface mockups. Get out the pen and paper, draw out how you transition from one screen to another, and have *some* kind of plan before you start implementing.
Just don't have too much of a plan.
Get the basics down, and don't bite off very much at all. Bite off less than you think you can chew. Do as little implementation as possible before you get something up and running as a prototype.
Since you're an artist, you have undoubtedly made lots of art that you now think sucks. That's exactly like programming, which is also an art. Programmers go through different phases, and everybody's work sucks at the beginning, but they make something, get it out there to the world, and improve next time.
It would be great if there was a way to show a programmer's oeuvre over his career...
But wow, what a digression.
Just get some prototype up and running and make some gorgeous artwork. Nobody playing your game cares what your code looks like, but they care a helluva lot what the artwork looks like.
RE: UML Diagramming - AnotherJake - Apr 27, 2012 08:57 AM
The negative comments here about diagramming and avoiding over thinking things are spot on IMHO. Planning and over thinking most often lead to trying to achieve things you are simply incapable of. You wind of conceiving of things and wrapping your mind around the problems in a way that is opposite from how they are actually solved, and so when you finally set out to solve them you either give up or throw the plans out and do it the right way.
Software development is fundamentally a messy process so the best way to start a project is to just start it, rather than wasting time planning. Having some sketches about how you want things to look, and notes about the main goals you are trying to achieve is fine; I do that all the time, but I don't regard them as concrete. The steps to get from point A to point Z are often a mystery though, and they're best worked out "on the fly". Usually starting somewhere in the middle, where the most interesting part is, makes the most sense and gets the project rolling quickly.
For instance, for this project, you might know that you will have a menu at the beginning to select options and at the end you might have a save screen or something. In the middle is the meat of the project, and the interesting part, which is looking at and manipulating/animating 2D characters. Therefore, I would start with the animated 2D characters.
Are they going to have multiple parts tied together and animated something like South Park characters? Okay, then skip down to the more fundamental aspect of that by learning how to draw one body part on screen on a plain colored background. Once you can draw the body part, then learn how to move it. Once you can move it, then add another body part and tie it to the first and move them together. Once you have achieved this, then you will have a pretty good idea of what kinds of challenges you face. At this point you can either abandon the project as being too complex, or you will have a clear idea of some next steps to take, such as adding user interface elements to control the body parts.
RE: UML Diagramming - hughnivers - Apr 27, 2012 12:20 PM
Thanks everyone. I really appreciate the feedback.
I'm gathering from your responses that I should just dive in an engage the inevitably messy process. I have already begun to do so, but I find the chaos and uncertainty uncomfortable and was hoping to reign in the terror a bit with a little order. I realize I'll just have to work through the pain.
I created this really buggy prototype - ( http://www.davidwhall.me/tag/tag.html ) - of a small portion of my project for a usability test. And yes, funkboy, the art is still not great. That's also a work in progress. The prototype was made in Flash using AS3 and it only represents about 5% of the total project. My original intent was to make this a Web/Flash game but with things moving rapidly toward mobile, I would prefer to focus on the iPad.
The animation interface accessed under the number "3" on the main interface will form the core of the application. This step will allow users to create their own animations and save them to the server. Step 1 is to be a video tutorial on the specific principle of animation. Right now I just have a place-holder video there. Step 2 is to be a game which allows the user to practice the principle, not unlike this game which teaches typography: http://type.method.ac/
The current game there is nothing like it will be. Again, it's just a place holder and is very slow.
So I plan to have about 10 principles of animation, each with its own screen with three steps. The pages of the book will flip and each page will eventually look like a pop-up book page.
Surrounding the teaching of the 10 principles will be a social animation experiment where users will use an original animation I provide, and then re-animate the fixed sequence of shots to make their own animation, using the assets provided in the game. Assets will include voice over clips, audio sound effects, visual effects, animation cycles, background art, foreground art and props, not to mention the character rigs which are characters in my story. Some of these assets can be created and uploaded by users and some will be built into the game itself. A flagging feature will allow the community to police inappropriate content. The intended age group for the game is between 7 and 14.
Users will be able to animate complete stories in three ways:
1. go-it-alone - i.e., do it all themselves from shot 1 to shot X
2. Randomize - Create a film by clicking a button which will randomly grab numbered shots and put them in the proper sequence. These will be more humorous as the animations won't gel, but the outcomes may be surprising.
3. Build-a-team - this is where the social part comes in most. You can invite other users to create a shot after the hand off of the previous shot, creating a sort of telephone game version.
The resulting videos can be rated, reviewed and shared to social sites. The app will track game inputs and award points for completing tasks, making comments and rating other user's films.
Okay, now that you know more and have seen the crap prototype, where would you sink your teeth in first?
RE: UML Diagramming - AnotherJake - Apr 27, 2012 09:03 PM
(Apr 27, 2012 12:20 PM)hughnivers Wrote: Okay, now that you know more and have seen the crap prototype, where would you sink your teeth in first?
First rule of game prototyping is that *nothing* is "crap" This is great, actually. Now we *see* more clearly the direction you want to go. It is far more useful than any flowchart/diagram/etc. and you are darn-well underway!
I developed and released a game for iOS a few years ago which was entirely prototyped in Flash. Recreating that in native Objective-C and OpenGL is not realistically doable for someone who doesn't have plenty of experience. It took me about 500 hours of labor for a game which looks like maybe a similar level of complexity to what you are showing, and I already knew the technology and how to do it.
So... Based off of your prototype, I would suggest that you need to change your technology approach. Native Obj-C and OpenGL appear to be a bad fit. Perhaps you would be better off using an existing iOS game or graphics engine for this, such as maybe Corona, or something similar.
RE: UML Diagramming - hughnivers - Apr 27, 2012 09:32 PM
(Apr 27, 2012 09:03 PM)AnotherJake Wrote: Perhaps you would be better off using an existing iOS game or graphics engine for this, such as maybe Corona, or something similar.
I'll take a closer look at Corona.
Also, one thing that I am completely ignorant of is the ability to run an app socially like "Words with Friends." What technology will I have to learn about to let my users look at and create films using other user's animated shorts and also to rate and review other user's content? In other words, users will upload and generate content as they play the game. I want other users to be able to access these assets.
RE: UML Diagramming - AnotherJake - Apr 27, 2012 09:56 PM
I would say that as a new developer you would be well advised to avoid social features until very last, if at all. It is hard enough to simply get the local mechanics working.
It's fun to talk about how your new project will have all this cool Facebook integration and Twitter compatibility, plus cloud integration and peer reviews, etc. etc. , because those are things your drinking buddies can easily envision from familiarity, and they sure seem cool when sitting on the toilet, but in reality those features mean little to the actual product you're struggling to make in the first place (unless it is something like Words with Friends which requires another player). They distract you from the core problems you need to solve. Take it one step at a time and tack the social crap on later if you still have the energy to do so at the finish line.
RE: UML Diagramming - MattDiamond - Apr 30, 2012 05:40 AM
Quote:My original intent was to make this a Web/Flash game but with things moving rapidly toward mobile, I would prefer to focus on the iPad.You might consider using Unity. You can develop for PC/Mac/Web for no charge (their own webplayer, not Flash). It does a lot of the grunt work for you for loading rigged models, playing animations, sounds, 3d objects, textures, physics.. I don't see anything in your spec that would require you to pay for the Pro version, unless maybe you want to play actual video. Later on you still have the option to deploy to Flash, iPad, or Android, though those would cost a fair bit of money.
If you have your heart set on iOS and your budget is severely constrained then this probably isn't the best choice, but starting from scratch has its own problems, particularly if you aren't already an experienced programmer.
RE: UML Diagramming - hughnivers - Apr 30, 2012 10:14 AM
(Apr 30, 2012 05:40 AM)MattDiamond Wrote: Ambitious project.
Thanks for the ideas. I have been hearing a lot about Unity lately. I'll take a look at that as well.