Jump to content
  • Advertisement

Corman

Member
  • Content Count

    242
  • Joined

  • Last visited

Community Reputation

558 Good

About Corman

  • Rank
    GDNet+

Personal Information

  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Education
    Production
    Programming
    QA
  1. Corman

    Things Change

    Well I seem to find myself slipping on posting anything or keeping up with the whole social thing time and time again. Things change, friends come and go, and personal interests seem to wax an wane. Right now I do not know how active I will stay here but I will continue to support the community and gamedev.net itself. I am looking at giving this whole social thing another go but I do not know to what degree and where and if I will still keep an up to date blog. All I know is my day job keeps me busy and my hobby focus have seemed to lean more towards the art aspect of life, still with a technical focus, than the raw code I have been so used to doing. So this is not really a goodbye but more so a quick drive-by update as there are changes brewing and I will still pop in here from time to time.
  2. From what I can gather from your post you are talking about 2d games, correct? I am figuring you are moving from a 2d tile based game system and now want to move to polygons? What type of game(s) are you interested in doing this for, top down or side scroller? And what level/depth of compexity are you wanting to deal with? Or are you just getting a feel for the waters that are ahead if you choose to make the transition?
  3. So I decided to do a little research and check the forums for your poject you have mentioned. I very much like what has been done so far and I hope you keep up the good work. I have rated you up because of this and also for the fact that you have shown the positive effort to improve your project's work efforts by speeking up and asking for advice here. I want to let you know what I have posted here was never directly targeted at you and holds true for many people/projects even myself, other people's projects I have worked on, and my own projects as well. What I think it boils down to is managing expectations people have or will have relating to every side of your project. This all starts with how you describe, show off, and bump your project to the end users who will want to play it, promote it, or even possibly join your team. And from what I have seen you are doing this pretty good so far. Next is monitoring the people you attract that have voiced their interest in helping you. I know you want people to join, but for the most part, the skill level you need is slightly above a large majority of the people you will run across. Most of the people that can do what you need already have their own projects or are working with someone else. Because of this you are going to get more people that are a bit green in this field. They will expect you to help them learn or be more forgiving with them. A lot have misconceptions of what goes in to working a project even as yours and believe the tools do most of the work for them. You can't always be picky but do not lead people on and give the the truth of the matter softly and do no lean towards being a dictator. The biggest expectations to manage are your own. This goes for any project starter, leader, core developer, and so on. You feel you have the greatest invested intrest in every aspect and your drive will be more than likely stronger than any others involved (and as it should be). You may be able to commit nights and weekends but you have to view this as an extreme upper bounds of what anyone else will be able to even add to. You should never expect anyone else to do more than you will be able to do or even match what you are putting in. Even if people pledge their efforts to you they still have lives and will still more than likely view this as YOUR project. You have to scale everything and look at it equivelently as if you were putting in 80 hour work weeks on this project. So even if someone is barely doing half of what you do they have still put in a great ammount of work. Even if they are only able to put in a few hours on a single day over the weekend they have done way more than can be expected. Between having to fix dinner, clean up, shower, and relax a bit before my next work day I barely have a hour or so of free time a night during the week. This will still be quite common for a lot of people even if they just only have school. So unless they have a strong drive and feel they are a part of something they can also call their own most of your peek times will be the weekend. But you also have to keep in mind people want their social lives too and have waited all week to go out on a Friday night or do something with friends on the weekends. There are only so many nights were you do not have to worry about staying out too late or having to get up on time for the next day. You also have to keep in mind the number of other projects that are out there and even how many of them may be farther along, larger groups of people, or even more compelling. So any ammount of activity is better than you many think. What you do have going for you is that you actually have something you can actually show vs. having just a help wanted thread five pages long with nothing but talk and no actual work to show. Most ideas die at this point because the people requesting help to form a team usually are waiting for people to make their dream come true because they are unable to do the work themselves. All this is just the start and a drop in the bucket but keep up the good work and that chin high!
  4. There are always exceptions to everything and behind most projects, even the short lived, are a core of very dedicated people. If this project is relatively new (less than a few months) you will find early on people with come and go like mad and at a relatively regular turn over rate. Even once you get past that you will always keep getting people come and go but you will start to find that you will be able to spot things sooner and smooth things out a little better. The best you can do is all keep working diligently and hopefully equally. You are only going to get better people once you have something to show that makes them feel they are on the same expectations and quality level. When it comes to doing work it also looks to break down like this: 1. There is more ideas about the project than ideas on how to tackle it reasonably 2. Artist that do stay will tend to produce more concept art than usable in-game content until they feel that the engine/technology is up to par to properly show off the quality work they believe they will do for the final product that the end user will actually see. 3. Programmers are usually more interested in the deep workings of the technology and feel it is hasty to deal with the things the desingers think of until they get further (but there are exceptions). 4. Then the split side of this is some of the coders are more interested in the gameplay mechanics and start working on things that are useless since they can not do anything until the rest of the "magic" has been done. 5. Everyone get distractive with "Ooooooo, what if?" things and jump from idea to idea and never work on anything beyond the first shallow proof of concept trial. 6. Endless cycles of trash and redo because no one is ever happy or they believe they see a problem they will come to that really could be easily worked around. 7. The core people always want the best for their project and actually create most of their own stress and barriers. 8. There are many and many little sandbox ideas done in code everwhere but no one ever truely sits down and melds it all together to keep building on. Sometimes you just got to make a stance and decide to just move forward and make what you have work for you vs. beating yourselves up. Just like muscians not everyone is going to become a rockstar. It takes times and practice and the more you shoot for triple-AAA ideas for projects and work quality the higher your chances you are going to fail. I am not saying aim low but what I am trying to drive is keep working on it. Your first project does not need to be your magnum opus.
  5. Corman

    3D Map Editor Design

    Indeed "Do I need this?" is something you should be asking youself all the time. Never do more than you have to and always think what is already at hand that with little or no work will give you the same outcome or something close enough that is acceptable. Simplest thing I ever did was use MSPaint as an editor. I basically created and arbitrary set of rules like each pixel represented so many world units and each color represented a different object to be placed in the world and wrote a small script that converted this into something that my engine could easily use. Also look at using file formats that already have code available to load and use free tools that export into this format. And if you are still set on doing your own editor look into leveraging available libraries like AntTweakBar to speed up development and even just to ease your own usability even if it is just for yourself. Never feel bad about using what is out there because even the professional game companies do and even license other peoples libraries all the time.
  6. Sad news is that I see nearly 90%+ (my own personal stats, this can truely be all over the place) of non-paid/voulenteer development in games end up like this over and over again until even the very talented and hard working parties are jaded beyond belief (myself included over past projects). And is usually broken down like this: 1. A large number of people under estimate the task(s) at hand and equally over estimate their own or other people skills to suceed or follow through with these tasks. 2. Join a project believing a lot of tangible/end usable work has been done and as soon as they get access to the inner circle feel that every thing was just smoke and mirrors and is nothing more than just sugar coated talk. 3. Want to be part of something but feel that everyone else will teach them or carry them along to greatness. 4. Everyone wants to be the idea guy/gal and getting in on the ground floor everyone pulls in a different direction or trys to inject their own personal goals in everything they actualy do. 5. Feels that they are only here to be the designer and drops the project when they feel the coders or artists (if any) are not doing anything or what they want. 6. Are not aware of the large dead zone periods where there is nothing to show and jump ship feeling it is not moving at their pace. 7. View it as a personal elective that they do not have to do so they feel that any sort of procrastination is fine since any work they do is worth more than what they are getting in return (that is nothing). 8. Like shinny new things and will move on to another project if it looks like it has more people interested or that it will go farther. 9. Everyone is in different locations around the world and have drastically different schedules that do not aline with others so ant any given moment it feels like you are the only one doing any work. 10. Feel that they are indeed doing all the work as everyone else sits back and slave drives them for something they are giving freely of themselves to do. 11. Think different tasks depend on other tasks to be finished before they do their work (ex. "engine" must be finished before artist start creating content, etc.) 12. Honestly do not know where to start for a good foundation and everyone scatters to different parts they believe are more important. 13. Do not like the coding style of everyone else and gives up on "princple". 14. Different levels of experience clash. 15. It was nothing more than an impulse moment and just kind of forget about it because it really did not mean that much to them in the first place. 16. The person who started the project usually is the one who trys to take the leadership role even if their skill set is not fully up to par with managing a larger team and more times than not are not open to taking some one elses lead in return. 17. Do not want to take suggestions from the people with real experience or at least the ones who have tried a particular route and maybe even failed (I see the wheel re-invented over and over with wrong paths retaken just because people do not want to listen to honest advice out of spite). 18. Some people are driven by what you can see and play with and sometimes if it does not get to that point soon enough the non-technical people usually drift away. 19. More people worry about making engines than games or planning for a future of re-usability and expandability that more than likely even with success will not come. 20. Really are not into it more than to have a social group that they can brag about. 21. Spend more time in idle planning and endless research for the "silver bullet" solution that nothing ever happens since they believe they have all the time they want. 22. Feel that no work can be done until they get more people or every "position" seat is filled. 23. Hold out hopping to nab a professional to fix all their problems. 24. Aim too high and never target a project with a subset of tasks that are best suited to the people at hand. 25. People just get dropped in with the basic feeling from others that they should know what they should do and work on right off the bat. 26. They never do any small team building projects to get used to everyone and have early sucesses. 27. Various age ranges and mental/physical maturity that may or may not be shared with others that causes clashes or misunderstandings do to how they talk or express themselves. 28. Ideas really are a dime a dozen and people become so inflexible to changing anything that they sabbotage what can be done for what they beleive should be done to the letter. 29. Everyone is a zealot over something, be it os, compiler, editor, art tools, or coding style and fight over thigns that really do not matter. 30. Just do not speak up and feel nothing is worth fighting over and just leave in silence never to be heard from again. This list is no where close to being exhaustive and could go on and on but is meant just to give a rough idea of some of the difficulties involved. So yeah, this is basically venting some frustrations I have come across and I am sure you and other have as well. There is no single solution or best pratice is this case since these sorts of groups are all over the spectrum. The only real solid advice is keep all these things in mind and understand what makes people tick and what they think and feel (like from the list above) and work to improve all the points even if it ends up being yourself and or your project itself. [Edited by - Corman on July 4, 2010 11:50:18 PM]
  7. Corman

    3D Map Editor Design

    Another thing to consider is that a lot of work will have to go into the user iterface itself no matter if it is fully graphical or not. Historicaly from many source this turns out to on average to be almost a 3rd of all your code and when things go wrong it will also account for more that half of all the bugs you will encounter with your own work.
  8. Corman

    3D Map Editor Design

    Writing an editor is indeed almost as much work if not more than the game [engine] itself. I worked on a commercial product that was almost nothing but an editor and it was an endless uphill change and maintance battle for 3 years before it reached the point were it was usable on a constant basis without people outside the development team moaning for a new feature or another way of process flow. The data structures changed from day to day and were not backwards compatible for some time until we switched to using a declarative binary file format. We called it FLOW (File Loading and Output Wizard) as a nod to the people that would want the program flow to change all the time. You described data structures in a FLOW script and "compiled" them in cpp/h files capable of now saving or loading that data file. The interesting thing was that if the field names stayed the same but changed format there were converters if they were single like int to float or double to string. You could also define conversions if they were a little more complicated. Our main goal was to basically add and try not to take away making it easier to support previous file formats we created. This also allowed to some degree older versions of the program being able to open up files created with a newer version as well. We also had an abstraction from the editor object and the runtime object. The runtime object was basically just what was needed to allow for end user interactions and rendering. The editor object changed constantly more so than the runtime representation and we had a final "process" to distill all the info for the release data. So in many ways we had two very distinct views of an object.
  9. Corman

    Mapping a Cube To A Sphere

    I know it may lack details but I do have an image up when I worked on this myself showing some LOD levels and how it looks when image mapped here.
  10. Corman

    UML design gui

    Murdocki, GUI requirements for any given system can always be different from each other and sometimes are very much tuned because of this for their special cases and needs. One of the reasons for the general case system that everything is a "widget" is to have a unified structure and data flow path that does not need endless special cases as you build onto it. Mileage may very but it gives you a good starting point most of the time. As for wondering about children it is a way of grouping and directing logic and or having them move when you move a parent. Yes there can be other ways to do this but the idea basically stays the same. For example take a number input field that also has up/down arrows to inc or dec the value. Technically this is one "widget" but is made up of 3 subwidgets. So what you have is a top-level widget that encompasses the 3 sub ones for a total of 4. If you "disable" the top level widget all lower level widgets can stop taking input. Or you can have logic that has a min and max value the number field can have and will disable the inc or dec arrows as needed but the widget is still active as a whole. But again like I said each GUI is usually based on what it is needed for. Like one of the systems I have done before worked better with the children being put into a subclass that still extended the widget. Here is just a "small" sample of GUI parts that I have developed and used before in a released project: class GuiWidget { protected: Rect2d mRect; Rect2d mClickRect; bool mIsVisible; bool mIsEnabled; bool mWantsFocus; bool mHasFocus; bool mHasMouse; string mToolTip; Texture mToolPic; public: GuiWidget(void); virtual ~GuiWidget(void); void SetRect(Rect2d& rect); Rect2d& GetRect(void); void SetClickRect(Rect2d& rect); Rect2d& GetClickRect(void); bool IsInside(Point2d& point); void SetVisible(bool visible); bool IsVisible(void); void SetEnabled(bool enabled); bool IsEnabled(void); bool WantsFocus(void); void SetFocus(bool focus); bool HasFocus(void); void SetMouse(bool mouse); bool HasMouse(void); void SetToolTip(const string& tip); const string& GetToolTip(void); void SetToolPic(Texture& pic); Texture& GetToolPic(void); virtual bool IsGroup(void); virtual void Render(void); virtual bool OnInputEvent(InputEvent& event); }; //---------- class GuiGroup : public GuiWidget { protected: typedef std::list<GuiWidget*> WidgetList; typedef WidgetList::iterator WidgetItr; typedef WidgetList::reverse_iterator WidgetRevItr; WidgetList mWidgets; public: GuiGroup(void); virtual ~GuiGroup(void); void AddWidget(GuiWidget* widget); void RemoveWidget(GuiWidget* widget); GuiWidget* GetWidgetAt(Point2d& point); bool IsGroup(void); void Render(void); }; //---------- class GuiButton : public GuiWidget { protected: typedef Callback_<GuiButton> ButtonCallback; GuiBrush mDefaultBrush; GuiBrush mPressedBrush; GuiBrush mHighlightBrush; GuiBrush mDisabledBrush; ButtonCallback mButtonCallback; bool mIsPressed; public: GuiButton(void); virtual ~GuiButton(void); void SetDefaultBrush(const string& brush); void SetPressedBrush(const string& brush); void SetHighlightBrush(const string& brush); void SetDisabledBrush(const string& brush); void SetButtonCallback(ButtonCallback callback); void SetPressed(bool pressed); bool IsPressed(void); void Render(void); bool OnInputEvent(InputEvent& event); }; //---------- class GuiSlider : public GuiWidget { protected: typedef Callback_<GuiSlider> SliderCallback; GuiBrush mThumbBrush; Rect2d mThumbRect; Rect2d mThumbClickRect; float mValue; float mMinValue; float mMaxValue; float* mExternValue; bool mIsDragging; SliderCallback mSliderCallback; public: GuiSlider(void); ~GuiSlider(void); void SetThumbBrush(const string& brush); void SetThumbRect(Rect2d& rect); void SetThumbClickRect(Rect2d& rect); void SetMinValue(float min); void SetMaxValue(float max); void SetValue(float value); void SetExternValue(float* value); void SetSliderCallback(SliderCallback callback); void Render(void); bool OnInputEvent(InputEvent& event); }; //---------- class GuiListBox; class GuiListBoxItem : public GuiWidget { protected: friend class GuiListBox; GuiListBox* mListBox; string mLabel; void* mData; public: GuiListBoxItem(void); ~GuiListBoxItem(void); void Render(void); bool OnInputEvent(InputEvent& event); }; class GuiListBoxView : public GuiGroup { protected: friend class GuiListBox; GuiListBox* mListBox; public: GuiListBoxView(void); ~GuiListBoxView(void); void Render(void); bool OnInputEvent(InputEvent& event); }; class GuiListBox : public GuiWidget { protected: friend class GuiListBoxItem; friend class GuiListBoxView; typedef Callback_<GuiListBox> ListBoxCallback; typedef std::vector<GuiListBoxItem*> ListBoxItemList; ListBoxItemList mItems; GuiListBoxItem* mActiveItem; GuiListBoxView mBoxView; FTGLPixmapFont* mFont; ListBoxCallback mListBoxCallback; bool mIsOpen; public: GuiListBox(void); ~GuiListBox(void); void AddItem(const string& label, void* data = 0); void* GetData(void); void SetListBoxCallback(ListBoxCallback callback); void Render(void); bool OnInputEvent(InputEvent& event); }; //---------- struct GuiToolTip { GuiWidget* mOverWidget; Point2d mCursorPos; bool mVisible; DWORD mTime; GuiToolTip(void) { mOverWidget = NULL; mVisible = false; mTime = 0; } }; class GuiManager { private: typedef std::vector<GuiResource> ResourceList; typedef ResourceList::iterator ResourceItr; static GuiManager* mSingleton; ResourceList mResources; GuiGroup mWidgets; GuiWidget* mFocusWidget; GuiWidget* mOverWidget; GuiWidget* mDownWidget; Point2d mCursorPos; GuiBrush mCursorBrush; GuiBrush mCursorDeleteBrush; bool mIsCursorVisible; bool mIsMouseDragging; GuiToolTip mToolTip; FTGLPixmapFont* mFont; public: GuiManager(void); ~GuiManager(void); static GuiManager* Instance(void); bool Initialize(void); void Shutdown(void); void Render(void); void Render2(bool del = false); void AddResource(const string& name, const string& texture, Point2dF& uvpos, Size2dF& uvsize); void ValidateResource(GuiResource* resource); GuiResource* FindResource(const string& name); void DrawBrush(Rect2d& rect, GuiBrush& brush); void DrawTexture(Rect2d& rect, Texture& texture); void DrawTexture(Rect2d& rect, Texture& texture, Rect2dF& uvrect); void AddWidget(GuiWidget* widget); void RemoveWidget(GuiWidget* widget); void SetFocusWidget(GuiWidget* widget); void SetCursorPosition(Point2d& point); Point2d GetCursorPosition(void); void SetCursorVisible(bool visible); bool IsCursorVisible(void); bool OnInputEvent(InputEvent& event); }; EDIT: realized this might help make more sense of the style callbacks I used: /* Deep Dark Voodoo Black Magic: All class methods must be thiscall with no thiscallvararg or virtuals allowed. All functions must take "TYPE*" as their input and must return nothing "void". The callback's primary use is for user interface state change notifications. */ template <class TYPE> class Callback_ { public: typedef void (*Proc)(TYPE*); private: void* mObject; void* mMethod; Proc mProc; public: Callback_(void) { mObject = NULL; mMethod = NULL; mProc = NULL; } Callback_(void* object, void* method) { mObject = object; mMethod = method; mProc = NULL; } Callback_(Proc proc) { mObject = NULL; mMethod = NULL; mProc = proc; } void operator()(TYPE* data) { if(mObject && mMethod) { void* object = mObject; void* method = mMethod; _asm { mov ecx, [object]; push data; call [method]; } } else if(mProc) { mProc(data); } } }; //---------- template <class TYPE> Callback_<TYPE> Callback(void (*proc)(TYPE*)) { return Callback_<TYPE>(proc); } inline void* ToVoidStar(void* dummy, ...) { va_list list; void* value; va_start(list, dummy); value = va_arg(list, void*); va_end(list); return value; } template <class TYPE, class MISC> Callback_<TYPE> Callback(MISC* object, void (MISC::*method)(TYPE*)) { void* methodptr = ToVoidStar(0, method); return Callback_<TYPE>(object, methodptr); } [Edited by - Corman on July 4, 2010 1:53:49 PM]
  11. It looks like something broke the linking directly to the journals like mine at http://members.gamedev.net/corman/journal/
  12. Corman

    Stone Cutting

    My article submission has been selected for the next Game Programming Gems 8... AGAIN*! * Yeah, yeah, I know you heard this all before and I bet you find yourself asking "Didn't this happen before? Where is his last announced article for that Game Programming Gems 7?". Well to make a long story short it wasn't just 7 I was going to be in but 6 as well. With 6 I had to pull my work because of a potential conflict with a client at that time and was just safer to drop it than get into any legal battles. Now 7 was harder to deal with for the pure fact I had to withdraw my paper because my father was just then hit with cancer. I would have liked to said I could of handled all the pressure and kept on working but I am only human. There was a lot of rough times ahead but I dropped just about everything to be with my father as much as possible. No amount of professional glory would be worth the time left that I spent with him through all his trials. I could stake my life on the fact that I became closer to him in that short span than I ever have over all my years and it saddens me that it took me even that long. Even though it has been many months since he passed away early in this year I still can't help but cry as I write this. For the man that helped make me who I am... this book is for you dad.
  13. Corman

    Red Matter

    What exactly is "red matter" in the Star Trek movie? I believe this might be some miss guided, artistic license, play on quantum chromodynamics and the strong force. There is what is known as color charge that is formulated to explain quark confinement and the residual of this why protons/neutrons can bind together to form larger groupings. The reason why it is called "color charge" is because it has three aspects so the primary colors red, green, and blue were chosen even though it has nothing to do with color. Gluons (what "glues" it all together) only come in "color" pairs of a color/anticolor. So this "Red Matter" can't be a Gluon but it can still leave the possibility of it being an exotic form of Quark matter. When Quarks combine to form say a Proton (two Up Quarks and a Down Quark) the Proton is "color" neutral since each Quark is a different color. But these Quarks are constantly changing color by exchanging Gluons. The possibility is that this "Red Matter" is some large mass of singularly "colored" Quarks of the Red charge. Of course this is by name only and by some miss guided, artistic license, running off a bit too far and made it ACTUALLY red. Being all the same color charge they would want to repel very strongly and explode. But even then they would start to exchange Gluons and change colors and color confinement would kick in. Because of this and the explosion in progress it becomes more energetically favorable for a new quark/anti-quark pair to spontaneously appear out of the vacuum. One would now have possibly a runaway chain reaction of mass/energy in a relatively small region warping space and time into a black hole. But of course this is just idle speculation on a movie plot device that wasn't talked about more than its color and that it makes black holes.
  14. Corman

    OpenGL Menus??

    You can get the widths of your glyphs with GetCharABCWidths with A+B+C being your total glyph width with leading and tailing whitespace if you want to create your own function for finding string space usage but you would need a lot more info to get it to come out. For what you have you could possibly get away with just using GetTextExtentPoint32 to get a bounding box for your string as is. Keep in most of these functions only work with the currently selected font so if you switch back to the old font before you use these functions you will only end up getting the info for the font you are NOT using to draw with. And be wise since these values will only help you in pixel units in screen space.
  15. Corman

    OpenGL Menus??

    With most font systems you can usually get global ascender, descender, and line heights for fonts to get the y space. The x (advancement) can be trickier but not impossible. You usually have to know individual glyph widths (including spaces) and sum these values while iterating over your sting. Once done you basically know the minimum bounding box for your sting. Pad this a little and you can get a box nicely around any text in a custom ui. If you need to guarantee a fixed font size you might have to pack your own font ahead of time in a texture. Doing this you basically already know the bounding box per glyph and can design accordingly.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!