Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Oct 1999
Offline Last Active Today, 08:13 PM

#5303918 Best Way To Comment Code Without Cluttering

Posted by on 03 August 2016 - 10:59 PM

As you get more experience ... you need less commenting ... but then you start working on bigger teams, where other programmers need you to comment.


I find that I only FORCE myself to comment in 3 cases:


1. When I'm defining an interface (pure virtual class for c++ peeps), and/or virtual base class method ... so people know what the contract is supposed to be ... not just exactly how its used today.

2. When I had to google something hard or unexpected to solve the problem ... or fix a non-obvious bug.

3. When I couldn't find good enough method names or variable names, so a comment was the only was I could read my own code from top to bottom.


I'm a big fan of long names and short methods ... but sometimes a name like "UpdatePhysicalDamageWithoutResistence" is just a silly method (and also usually a sign your code design / organization isn't great ... but at the end of the day sometimes you just need to write some more code).


Never write comments targeted for beginners or people who've never seen the codebase at all.  Write comments targeted at average intermediate programmers who've worked on the project for a short while ... that way you won't need to repeat the standard idioms over and over ... but you will point out the new and interesting stuff.

#5296893 Need help on what to do with my idea

Posted by on 16 June 2016 - 09:24 PM

AyJay, expect to write many more "stories for games" or at least partially written ideas and story outlines ... than actual games.  Partially because for most cases the amount of time people will invest to deliver a pretty interesting story outline and game idea is measured in the "hundreds of hours" while the time to build actual working and fun games is usually in the "tens of thousands of hours" ... don't get me wrong, there are some "games" that are built in only a few dozen hours ... usually by creating them with a framework that is specifically for the game type you are building ... and then only creating the custom details ... or by being expect at using powerful tools and intentionally making something very simple.


I don't mean this to discourage you ... please keep writing and creating and coming up with ideas.  And if you keep coming back to the same idea(s) ... and improving them over time ... and getting closer to finishing them ... great.  Just don't think everything you create has to be production quality, nor every good idea has to actual be made into a finished game.  Try to come up with 3 ideas, or 5 ... try to work on them all a little ... stopping when one seem either compete, or a waste of your time to continue.


And try to find other people that have fun "working" with you ... bouncing ideas around ... or artists who like drawing or modeling from some ideas you discuss, or programmers who like trying to make something work ... 


good luck.

#5296889 Simple RTS

Posted by on 16 June 2016 - 09:07 PM

The key to creating ANYTHING of value that requires you to learn and also product more than you can do yourself in a reasonable time frame is ... find other like-minded individuals and form relationships with them (some will be very short, some may be lifelong).


Some random ideas ... find or create a meetup group ... go to the local college/community college ... go browse the gamedev.net "Forum -> Community -> Hobby Project Classifieds".


Don't start by trying to find the 1 or 2 people, or the 1 or 2 projects that you are going to commit to for the next few years and deliver your opus.


Start by trying to find the first 1 or 2 people or the first 1 or 2 projects that you can contribute to, have fun doing it, help them, and help yourself in the process.  Mutual benefit and enjoyment ... those are the goals to start with.  And yes, projects that die in 2 weeks, or struggle for months but deliver nothing are NOT fun ... but projects that make a little progress over 6 months, generate a demo that sucks initially and then sucks a less after a few more months ... before people move on to better things ... isn't worthless.  Its the experience that counts.


And while I'm not going to tell you to give away all your ideas and creations for free to whoever wants them ... I am going to suggest you think of some (not all) of your work as work you do just to learn, not to earn ... like coursework in school ... don't expect anything but knowledge in return.


The other important thing ... don't look for people just like yourself ... and don't look for people you don't understand at all ... look for people you can talk to, chat with, work with ... but at the end of the month, each of you is adding some value to the whole.


Good luck and godspeed.

#5230250 Can a lone indie dev do an open world like this?

Posted by on 21 May 2015 - 08:23 AM

First, rock on Norman ... passion and dedication are the key to doing anything great.


Second, go OP ... it doesn't hurt to dream big.


And I want to give thumbs up to the ideas that learning is always a good thing, even if what you thought you were learning for doesn't work out.


I absolutely love Norman's posts 2 main points about (1) tackling each thing in VERY small chunks ... cause it does no good to "work" for 2 years with no progress or fun.  and (2) for a real project you want to actually finish, identify and solve the basic shape of each and every piece before you actual start building anything.


They didn't build a space shuttle by designing a fuselage this year, and then a propulsion system next year, and life support after the fact.  They broke down the requirements that would apply the whole thing, then to each subsystem.  Then they looked at which ares are "solved" (a drop-in usable system such as the radio, tires or oxygen tanks), which ones were just work intensive (refining the shape of the wing, landing gear), and which ones required actual advancement and had risk (designing a propulsion system with high enough thrust to weight, the heat shield for reentry).  Then they made rough estimates on the whole, made sure the budget had a reasonable chance of success, and started work on the hard parts first (no point designing a wing, if you can't get it into space or keep it from burning up on reentry).  Also, besides risk, what they did and what you need to do is: tackle the part that affects the other parts the most.  You can also work on parts that are totally independent at your leisure (like characters, history, etc) - because this work won't get thrown away, even when you tech research gets abandoned as you adopt new technology.


But now I want to expand on a few related ideas.  You do NOT need to keep switching to cutting edge technology every year, if you do, you will never release anything.  However, you will probably need to plan to switch technology once or twice during a long project like this - because you will encounter cases where you just can't bear to keep working on something you know is crappy, when the shiny new thing is right in front of you.


And also, ongoing projects that last 6-20 years are fine ... but NOT projects that are in a no-fun useless "in development" state for that whole time.  Almost all of the interesting, or success, or enjoyable projects I've heard about that people have worked on for 10 plus years, are version 2, 3, 11 or 15 of something that only took 0.5 - 3 years to get to some "interesting" state.  Every one of these "lifelong" indie projects I've seen go anywhere started out with much much smaller scope, than it had after 5 - 10 years.  It doesn't work the other way.  You can't start with "I have to build a GTA V clone, but better.", you have to start with something either dramatically smaller (so you can actually do it), or dramatically better (so you can attract others along the way to help you), or dramatically different (cause the ability to release something like a AAA 2015 game in 2025 doesn't motivate people for long).


My personal recommendation is to see this as a journey with many many stepping stones along the way.  Don't start your 10 year game now, that will be very un-enjoyably in a few years and feel like failure.  Start something else, that will either teach you a part of what you need to build your big game, or that you can use to explore a part of your idea for your big game, or that is a fun vehicle to work on that same world/characters that your big game may eventually be built on top of.


This post is getting a little long so I'll leave you with this:  

(it's a video on the history of Bethesda Softwerks, but most importanting, watch up to a little past the 4 minute mark to see how, when the developers started work on what they wanted to work on, as they went on, it morphed into something else, eventually being very different than their original idea, and becoming the foundation for the Elder Scrolls series they've continued with to this day).


And this: http://www.illwinter.com/dom4/

Its a recent release from a very passionate small developer, whose been working with the same stuff for a decade, but not without releasing the earlier versions along the way.  If you back up to the home back, you will see a timeline of his releases from 2003 - 2014, mostly chronically the release of successive versions of his 2 games ('Dominions' and 'Conquest of Elysium' ... which are 2 related but different games built with the same technology, art and data).


Good luck and enjoy the future!

#5218758 Card game Class Structure

Posted by on 24 March 2015 - 08:14 AM

The part I didn't say is that ... this is really just standard OO and polymorphism ... OO has always had factories and such ... people just think of it as "composition over inheiritance" because in 1 specific detail (the card's effects) you are composing a set of objects, instead of coding those compositions as a class ... but really this is just standard data driven OO ... no different than the way physics engines have worked since the dawn of time (A physical object is composed of a set of "parts" ... each combination is not coded manually as a separate class).


I think the reason people get confused is that OO classes all teach things wrong ... they talk about Animals with Dogs and Cats ... or Shapes with Square and Circle classes ... but that is a bad example, because it isn't based on what the computer is doing in a real world data-oriented way ... better examples would be something like a UI system that has Control, Button, TextBox ... where there is a very useful based behavior related to accepting input and knowing where you are on the screen ... but then the derived classes are actually different in their behavior ... and they have a valid logical reason to be aggregated ... I've never seen an "Animal" or "Shape" base class do anything useful ... not like a "Control" base class, which can support child control containment, etc.  Another good example might be an "Image" that has derived classes for a Bitmap (or similar) and another for a VectorDrawing ... (which in turn has a list of shapes).

#5204143 Code appearance, is it really important?

Posted by on 13 January 2015 - 11:43 PM

What's funny is this:


Almost every one of the replies answered your original question (in my opinion correctly) ... but also, almost every single one either completely ignored the specific example you used, or (in my opinion incorrectly) expressed  a thought like the second version someone shows better programming than the first.  This is completely untrue.  The second version of your examples is in fact better code, and more readable.  But it does not in any way show that it was written by a better programmer.  It shows that it was written by someone who happened to be aware of a library function that exists and is useful, while the first example (yours) is exactly the type of code any decent normal recent programmer would write if that library function was not available, or they were not aware of it's existence.


It is a good idea to skim ALL the methods of any library class you are using, to see if another method might be better for you, but it is also true that 100s of times more code is out there and available to be used than any programmer is every going to know about and be able to use.


So your friend should not have "laughed at you" except in that good natured version of "man that code isn't needed because of this cool way you could do it instead".


The important thing in programming is NOT somehow having to know all the code out there and use it all correctly (although constantly working at this is important).  The important thing is CLARITY OF THOUGHT ... and the second important thing is CLARITY OF EXPRESSION.  Clarity of expression is VERY important, but always way less important than clarity of thought.  Clearly writing a program based on a poor and muddy design is not good (and is done more often than not) ... writing an unreadable mess based on a clear and good idea is not good (and is done often too) ... having a clear idea of what you want to accomplish and then a clear expression in code ... that is the goal.


Good luck.

#5201691 Requesting advice on where/how/what (sequence) to start.

Posted by on 04 January 2015 - 12:32 AM

As I'm sure you know, there are DOZENS of ways to do this type of game, and it would vary by your expertise (if you had some), however your original list of "tech to use" was a sound set of tech that is A) used for this type of thing a lot .. and B) used TOGETHER with each other a lot ... and therefore C) has a LOT of online help available ... so it is a good choice.


Don't let yourself worry too much about doing things the RIGHT way at this point ... until you get something at all satisfying DONE, BY YOUR OWN HAND ... don't judge how it should be done, just try to do it BY ANY MEANS POSSIBLE.


For the client UI (in a browser) you are going to pretty much have to use either:  HTML, CSS and Javascript ... or else Adobe Flash, which requires the client to have installed the flash player to play your game ... those are really the only 2 options ... both are great ... 5-10 years ago most the simple cool games would have been Flash (which uses the language ActionScript), but recently HTML (XHTML or HTML 5 specifically) is getting to be more popular.  Neither one is a bad choice at all .... just spend 2-10 days trying the tutorials of 1 and see how it goes.  If you hate it ... try the other ... but after you've tried both, if you hate them both ... pick one anyway.


For the server side there are too many good choices to list.  But PHP and MySQL would have been the best cheap indie choice 5-10 years ago for sure, and is still fine.  


For Data - You can now use ANY of the SQL backends (MySQL, PostgressQL, MS SQL Server Express or SQL Anywhere, SQLlite) or even NoSQL options like MongoDB (and many others I've never used).  That said, the issue is not which DB you pick, that won't matter (except of course the choices between SQL based and NON-SQL based, which does matter).  The issue will be - learning RELATIONAL DATABASE MODELING / DESIGN well enough to organize your data in a way that doesn't suck for your game / goals.  Given a decent data model, I can use ANY of the existing tools with almost no issues.  So my recommendation is A) pick a tool (like MySQL) and use it ... but mainly just use simple standard ANSI SQL - don't bother learning any more custom MySQL specific stuff than you absolutely have to.


For Langauge - You can use ANY decent server supported languages.  5-10 years ago that would be either PHP, Perl, Python, ruby ... or Java or C#.  Today it's basically the same list ... except most people don't use Perl for server code much anymore.  PHP is extremely easy to use for small programs.  Python and ruby are similar but harder to start with ... however better for bigger programs.  C# (and probably Java) are great programming languages for programmers ... which I am, so I prefer C# ... but less good for people who aren't professional programmers.  If you want to learn programming in general, I recommend C#, PHP, Python or Javascript as good starting points ... but if you want to get stuff done on a webgame quickly .. I'd skip C# (even though its my personal favorite).

#5201685 "List iterator not incrementable", error enhanced for loop and remove

Posted by on 04 January 2015 - 12:10 AM





each type of container has a reason to exist, don't think for a second that there is 1 choice that is "better" it simply isn't true, period ... I've read 4 sets of benchmarks and programmed in embedded C++ for over 8 years (not recently though)


The only thing you need to know though is:  The BEST container for a given job is NOT something you can figure out by using logic.  Because the performance of the use case is HEAVILY affected by object size, locality, operation ratios, and variations in data set vs cache size (and even branch predictors).  So the ONLY way to know what container is best for a job is to write the code and benchmark it.


Personally, I used to start with my default goto item "std::deque" and then switch to vector and list if I was pretty sure they were better (and in my experience about half my simple linear containers ended up being vector, most of the rest deque, and a small percentage ended up as lists - usually the obvious ones that were LARGE and had many RANDOM or FRONT inserts),  BTW occasionally you can get the most bang by not switching container types, but by switching container usage (like mentally swapping the MEANING of front and back if your vector has a lot of FRONT inserts but few back inserts)

#5183244 code for doing something while the game is off

Posted by on 26 September 2014 - 11:42 PM

Pretty much all the games in this genre (including cookie clicker) are ONLINE/SERVER based games.  Meaning that you information is in a database on a server, and all the "truth" of the world is what's on that server ... so every "action" of any significance is a web request ... so the time in question here is always just the official server time  ...


so .. lets say the user does the action:  "build object A" ... it sends a request to the server which puts that in the db (with server based timestamps etc) ... then the client receives a response (usually with object A's id in it) ... and starts a local (on the client) display related to time passing.  Each message back and forth with the server includes a response, which includes the current server time, which the client uses to "sync" to (and avoid getting increasing amounts of client clock drift involved) ...


Then lets say the phone dies ... nothing "happens" when the phone is disconnected.  NOTHING.


The server is just sitting there with static rows in the db for that user, the client is just off ...


Then when the client runs the app again, it makes a "login" or "start session" or "resume" request to the server ... which then pulls all the "active/pending" builds from a list, updates their status based on current time, and sends the relevant info back to the client for updating in the UI (and notifying the user with things like flashing or pop-up displays ... etc.


The server is the holder of all truth, and runner of all important logic, the client is just a dumb data display and user input device .. which in certain areas has logic which mirrors or imitates the game logic to provide "real-time" updates to the UI (between server interactions).


There is also 1 exception to the server doing nothing except during client requests ... if the game uses push notifications (or anything like it) ... then the way that works is that the server usually has some periodic little method running to look at data that should generate a push notification (for instance when a building has just finished) ... and then package that up and send it to the client device (not a running app ... push notifications actually go to the phone, for when the app isn't running, ... then when the user clicks them, they launch the app ... which then does that "session resume" type call I spoke of earlier) ...


Servers that generate push notifications usually have some minimum threshold (like lets say 2-10 minutes) that must have passed since the last request came from the phone, else they won't send the notification (or they will send it to the app in a different format, instead of to the device as a push notification) ... systems like PubNub exist to make this stuff easy.

#5179991 Diablo type attacks

Posted by on 12 September 2014 - 05:09 PM

You have probably already realized this, based on the 2 posts and your own, but just in case you didn't:


There are 2 separate ideas at play here:

1.  Determining what the targets are.

2.  Determining if the targets take damage (or how much).


For most diablo type games, number 1 is based on either a "collision template" or a function that does the same thing ... the goal being to have a quick method to determine what enemy (or set of enemies) is within the potential "hit box" (which can be a cone/sphere or whatever) ... for non-AOE weapons, the "nearest" such enemy is usually selected.  For AOE weapons, all such enemies are usually selected ...


And then the logic passes the (hit / potentially hit / targetted) units to the part of the code that computes / applies the damage ... which takes into account things like resistence, etc.


Then the output of this function is used to generate sound/graphic/particle artifacts (so that blocked attacks sound different than crits, etc) ...

#5179624 GOTO, why are you adverse to using it

Posted by on 11 September 2014 - 10:37 AM

People should never discuss "goto" without first acknowleging that there are 2 different types of goto ... (that are as different as for loops and foreach loops).


The "goto" that exists in languages like (the old line numbered version of) BASIC, and a high proportion of early langauges is the unscoped goto.  It is the all-powerful, context free, danerous and evil goto.  This goto has the power to transfer execution from a line in any method in any file, to a line in any method in any other file.  This goto is "dangerous" in every sense of the word ... because it has no limits.


Just like a military grade weapon it is powerful, and appropriate at the right time (perhaps if you are writing an optimizing compiler or some such, or working in a langauge that is more efficient when using unstructured paradigms).  And because this goto is so powerful - it takes rules and training to use it without hurting people.  But this goto has been removed from nearly all modern langauges ... because its power CANNOT be used safely if you cannot trust every developer to always follow whatever rules you invent to guide its use ... and its use would deny the ability of any but the most awesome non-JIT compiler from ever being able to guarantee ANYTHING about ANYTHING ... it couldn't know how to clean up stack frames, free resources, do garbage collection, etc ... because the "jump somewhere, anywhere, whenever" feature would block any logical solutions to any but the simplest programs.  ... "tail call optimization" is kinda like a goto ... but this leads to my point.


The universal unlimited goto was REMOVED and REPLACED with other, more structured (aka limited) contructs ... that have been proven to be able to acomplish all necessary goals ... albiet without ideal efficiency in some cases ... with less danger and more guarantees.


The current GOTO in almost all currently used languages (except ASM) is a different goto entirely ... it cannot see or reference any labels outside of its own method/scope ... therefore it is just simple, weak, powerless syntactic suger for doing multiple breaks, etc ... if this goto had been named something else (perhaps "escape" or something) people would realize that it isn't the same thing written about over the years ... it is mathematically similar in structured programming consequences as the practice of using more than 1 return in a method (which violates structured programmings rules ... but since it is limited in maximum scope to a function, noone cares ... cause any real programmer can handle seeing it in any function that isn't so large it shouldn't exist anyway).


So just remember ... your goto in whatever language you currently use, probably isn't really a goto at all ... its just a slightly more powerful flow construct than a break statement, with a really bad reputation ...


but also remebmer, when they removed the POWER of the goto ... they also removed the REASON for a goto ... there is no longer any case where the current goto cannot be restructured as some other layout of code, that yields IDENTICAL performance and machine code in every way.


So goto is no longer harmfull, it is just pointless.

#5139154 No Low Level Programming is better ?, Please explain this then ?

Posted by on 14 March 2014 - 11:22 PM

No professional programmer, let alone game developer, would say that all low level programming / optimizations are bad.


But experienced professionals will tell you that things similar to the saying "premature optimization is the root of all evil" ...


The gist of most professionals opinions is that you should not focus on specific target or performance concerns too early in the life cycle.  Partially because there is no point in optimizing a program or feature that may not make the cut into a final product anyway.  Partially because by the time the product comes out, the exact appropriate optimization might change.  Partially because clean logical code is easier to understand and modify, and you want to be able to change and improve as much as possible while learning what is fun and what isn't.  And Finally because it is often true that developer time is more important than efficiency in many cases and they'd rather make 3 games that are fun and for sale, then 2 highly optimized games that are just as fun and just as for sale.


Also, don't confuse "premature optimization" with "building for a platform".  An example of the type of optimization that would be discouraged is "oh man I have a great idea for how to make this highly detailed crafting system for this fantasy MMORPG i'm working on ... but I don't know which data structure or algorithm is the most efficient implementation".  An example of the type of platform utilization that is NOT bad would be "oh man, since this game is for phones and tablets I have a great idea for how we can leverage the gyroscope to control the crafting system in a unique and cool way".  See the difference is, in the first case, someone has a great idea and is letting the low level aspects reduce their ability to deliver a functional feature.  In the second case, the developer is being inspired to create a more enjoyable or fresh experience in harmony with the target platform characteristics.

#5131432 From C to ?

Posted by on 14 February 2014 - 06:12 PM

I also love how people complain about C++, C# or Java version issues, and then don't comlain about Perl, Python or Ruby versions issues ... which are absolutely the worst, except most of the history of Perl 5 has been about as stable as C++,C# and Java ... hell, you can just now BARELY get a linux distro that ships with Python 3 (which is at 3.3) because they have a dependency on incompatible Python 2 code.  And ruby, a langauge I actually like, got stuck at 1.8 for more than 2 years after 1.9 was released, and now that 2.0 is released, only 1 major distro ships it.


The fact is in my entire C++ history, I had exactly 1 type of code I actually used that wasn't compatible with C++ 11 - related to how it disambiguates names in some cases.  I spent 3 hours fixing my code base, problem gone.


Also, in C#, none of my working code has ever failed to work on newer versions, except for 1 change they made with 1.1 as a security fix.

#5104254 GUI aspect ratio independence

Posted by on 24 October 2013 - 10:51 PM

Depends on what you mean.  Do you mean you want letter boxing, so the actual controls are in correct aspect ratio as your base version ... or do you mean if the screen is 20% wider, you want your controls to be 20% wider?  Either way, you can see that if you just thing about it from those 2 choice, the answer is almost obvious.

#5098201 How to cut out duplicate code

Posted by on 01 October 2013 - 11:20 PM

Or better yet, do not combine 2 completely separate concepts into single classes.  The responsibility to have manage a list of event handlers is a single purpose.  Aka a class.  This is a basic common pattern known by many names include Broadcaster / Listener, Publish / Subscribe or Observer pattern.  The responsibility to define a callback signature is another responsibility - usually using a function pointer typedef, a delegate, or other technique.  And the responsibility to define an actual specific slot, for a specific purpose within your program is a 3rd one.  So to put in some possible specifics.


Alvaro's EventHandler is a good class here - although for the way I plan to decompose responsibility in this example, I would rename something else, perhaps "EventManager" or something.


I would then use EventHandler or EventCallback as the base class for various event signatures, perhaps ClosedEventHandler, ResizedEventHandler, etc.  So a "ClosedEventHandler" would be a function signature for a callback that accepts the "closed event argument type" as its event argument.


I would then using INSTANCES of the EventHandler class, for each slot I had.  So perhaps:


EventManager<ClosedEventHandler> Closed;

EventManager<ResizedEventHandler> Resized;


And the OnClosed() method would iterate over the Closed EventManager calling all of the managed handlers (ie, "Raise" the event).


If you just look into how C#/.Net events and delegates work, you'll find a great example of a design like this.  But back in my C++ days I had written something quite similar to what I am posting here - although I haven't looked up all the details, and the names and such were different.