Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


aregee

Member Since 06 Oct 2009
Offline Last Active Mar 01 2015 06:57 AM

Posts I've Made

In Topic: Let's talk on how to make a product builder game?

25 February 2015 - 04:58 PM

I am by no means any expert on the topic, but I think you have a lot to learn, if HTML is all you know.  Just client side, I would add that you would need to learn JavaScript too, in addition to the other technologies you have already mentioned.

 

Unless it is a client based game where nothing is stored between sessions, you will also need a web server with a database system and a server side scripting system. In the past, I have used Apache, PHP and MySQL, but that is starting to be quite a while ago, so have a look around.

 

Other buzzwords you may have a look into is JSON, JQuery.

 

Security is a must, so make sure you understand the dangers and pitfalls of a poorly designed system for handling logins and sessions (how you store your passwords, for instance), and data that is sent to the server from the client (it can not be trusted without validation), and SQL security as well (SQL injection, for instance).

 

All these suggestions are based on what you mentioned in your original post, and there are other choices you can make too, like scrapping everything mentioned above and go for something like FLASH, for instance, client side. You will still need what I mentioned on the server side if you want persistence.


In Topic: Demo scene 90's, anastasia song

24 February 2015 - 02:09 PM

Never heard of the group or demo, but I am pretty sure it is this one:

 

"Toys" by "Gods" (PC demo, "Trip" party, March 1999, 1st place):

 

http://www.pouet.net/prod.php?which=710

 

I couldn't find any YouTube video of the demo.


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 06:17 PM

 

I will post a snippet from my parser which is one of the routines I needed goto the most...

 

[...]

 

I won't repeat what Álvaro said, but please...

 

Write sensible names.

 

Name 'dyn' and the likes more like 'isDynamic' (If that is even what you mean).  Then you can test like this, assuming it is actually a boolean:

if (isDynamic) { ... }

Instead of:

if (isDynamic == true) { ... }

Try to make your code as readable like a book that you can.

 

Always use brackets, even if your if, for, while, do..while, etc is having only one line.

 

'currentLineCount', or 'CurrentLineCount' is MUCH easier to read than 'CurLnCnt'.

 

What is 'IsPastEOS'?  'EOF' is so common, I guess most people would understand, but 'EOS'?  End of stream?  I would spell it out in either case.

 

I know that you have an assembler background, and labels like this were common back then.  I also think you actually was limited to 8 chars on certain assemblers too, and that didn't help.  It really feels like reading assembler code written in C.

 

And I will also point back to Álvaros comments again.


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 03:43 PM

I think exceptions have no place other than in the case of a fatal, unrecoverable failure in a program.  When I was learning Java way back, I was encouraged to use exceptions as the default way of reporting and handling errors.  I always felt that was a bit clunky, and it made for code that was filled with blocks that I felt never belonged in the code at all.  I always favoured explicit error checking over exceptions.  Who thought it was a great idea to throw a NumberFormatException when you feed bogus data to convert a string to an integer in Java??  That pretty much sums it up...


In Topic: GOTO, why are you adverse to using it

06 September 2014 - 09:52 AM

[...]

 

The "cascade deallocation" model:

 

[...]

 

Or the honest-to-god goto model:

 

[...]

 

And if you are thinking why I didn't just move the cleanup bit into its own function, let me ask you this: why would I create an off-screen helper function with critical cleanup code that intrinsically needs to be kept in sync with the do_work() function, when I can just have it naturally at the bottom of the function all by replacing "cleanup(); return 0;" with "goto cleanup;". What concrete, practical advantage is there? None. It's a waste of space and programmer energy, and a prime example of cargo cult programming.

 

 

If you want to think about this in a real technical way, you should be able to draw a flow chart of your function. This should be done in advance, but who does that? The rules of a flow chart is: that you are having only one entry point, and only one exit point, and that absolutely no lines are crossing each other. No, you can't cheat and draw a flow chart that branches to the right side, and then to the left side to avoid a crossing on the right side. If you are ever using any of goto, break, continue or early returns, then you are breaking this flow.

 

 

That's an arbitrary blanket rule. Early returns are a good thing. Breaks and continues have their places. Goto has its place too when you need some kind of control flow that improves readability (like the error handling example) and no other language construct naturally lends itself to that (admittedly, that is rare even in languages like C, and basically nonexistent for higher level languages). And when I see this kind of rule being repeated blindly all I can think of is the programmer who, told not to use goto, wrapped up his error handling code in a dreadful do{}while(0); loop to obtain the same control flow without writing 'goto' and obfuscating his code in the process. And that is far worse than any amount of gotos (well, almost any amount).

 

I'm not saying goto is good. Here the use of goto for error handling is justifiable because goto naturally lends itself to a rather elegant, very low boilerplate resource cleanup implementation in C. Clearly jumping all over your code, to labels hundreds of lines away, is nothing short of insane. But simply outright banning goto because there is a paper called 'goto considered harmful' without even considering the possibility that maybe, just maybe, goto could be used in a controlled manner (it is a tool, and just like any other tool it can be abused; break and continue are also tools which can be abused) simply shows a lack of intellectual depth in my opinion.

 

 

The cascade model is just plain ugly.  The goto way is actually really elegant.  In those cases I would probably go for a function in the past to avoid goto, but your arguments have convinced me.  There are definitively reasons for goto in certain cases, and the function way is not good either.

 

Regarding the blanket rule, I am not at all preaching the "flow chart" model, since I am obviously not following those rules myself, just wanted to hear some arguments, and I got a lot of good ones.  I am a follower of clean and elegant code, and that is for me more important than any other strictly (and blindly) enforced idioms.  Hearing comments like this also eases my insecurities/discomforts when I am breaking out of learned/taught conventions to make things more readable/elegant too, but the goto one has really got stuck in me for some reason. 


PARTNERS