Jump to content

  • Log In with Google      Sign In   
  • Create Account

00Kevin

Member Since 12 Oct 2005
Offline Last Active Today, 09:21 AM

#5295839 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 09 June 2016 - 12:38 PM

btw,  you gotta love coders who, before they even begin to make modifications, waste half the day or more changing the coding style.    

 

One guy I worked with changed all the database commands to upper case.   I was like really?

 

As for camelCase or PascalStyle,  my pinky has been brutalized on this shift key because you! 




#5295838 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 09 June 2016 - 12:32 PM

 

Yes, if you want good code style, you must make classes as CMyClass and interfaces as IMyClassInterface

This is a subjective opinion presented as an objective fact.
...and it's not even a popular opinion.  

Naming classes from lowercase is bad practice, and using "_" in defining is bad style(for readeable). You must start every letter from uppercase and not use "_".

Lowercase with underscores is actually the most 'official' style that C++ has, as it's used by the standard library (and many other projects).
The people who choose it would say the opposite opinion: that CamelCase is bad style and makes code less readable..

 

I work with one programmer who hates underscores.   So we all try to add a few extra once and a while just to hear him scream "I hate f**king underscores!'.    




#5295836 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 09 June 2016 - 12:28 PM

 

 

Actually, m_ for members and g_ for globals helps quite a bit while reading a lot of unknown code.


The problem is that this kind of convention is brittle. It encodes information about scope into the variable name, but if you refactor to change scope the encoding is wrong and the variable must be renamed.  Forget or neglect to rename the variable and now you've got misleading information.

 

A far more robust convention is to require the use of this-> for members and to require full namespace naming for globals.  The compiler can then help you by catching incorrect usage.  In an ideal world C++ would have had these requirements from the outset.

 

this, a thousand times this (pun absolutely intended). I sometimes wish c++ had gone the same route as python or rust with an explicit self/this parameter. which could also enable things like templates based on the reference qualifiers of the object.

 

 

shortly after the wheel we invented find/replace and yet things still get missed.  




#5295835 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 09 June 2016 - 12:23 PM

 

There are no strict standards for success.


Actually there is. Be consistent, at least in your own codebase. If I know something is called a foo bar I should be able to deduce its name without having to check on which day it was written. FooBar, CFooBar, TFooBar, foo_bar, ... are all somehow acceptable provided they follow a clear pattern.

I still wished C or T prefixes would remain in the dustbin of history though.

 

 

That doesn't happen. 

 

The point I'm making is that readability (for the next guy) is far more important than a bunch of strict coding styles that are largely subjective and change over time. 

 

I'm talking from years of experience developing large enterprise level systems that evolve.  Code bases developed by multiple developers often contain mixed styles. That's the reality regardless of how idealistic you are.    As programmers we deal with what IS and not with what should be.  The fact is most successful business systems contain mixed conventions and poorly written code anyway .  So unless you are the sole developer for the entire life of an application, there's no sense in being strict in regards to programming style.  For success, focus on the architecture of your product, which is the true measure of success,  and don't be guilty of using meaningless notations. 

 

Now, I'm not trying to write a book here or publish a thesis to become famous, I'm just telling you the way it really is.   With that said, I'm frequently reminded of all those jokers in my class that couldn't code very well.   I found out the hard way that they are busy writing endless lines of bad code for us all.  :)  So in the grand scheme of things, stylistic conventions are the least of our concerns as programmers. 




#5295636 Do you usually prefix your classes with the letter 'C' or something e...

Posted by on 08 June 2016 - 10:20 AM

This reminds me that many years ago it was also common to use the prefix letter 'T' for the class definition...    I wonder what happened to that.    

And the prefix 'C'?  don't remind me the horror that is MFC.  

 

 

With that said, after working on a several large business system across many different languages I hate prefix / Hungarian notation with a passion.   

 

I find that coding conventions (especially prefixes) are rarely enforced, change over time, and are usually only grudgingly accepted (if at all) by subsequent developers who inherit your work.   In the end, everyone tries to adopt their own conventions and the code base becomes a complete mess.    

 

IMO, just make your code readable.  There are no strict standards for success.   In fact, sometimes the variable name 'i' is more readable than a long description and sometimes it isn't.  If you write your code for other people to read then you'll be successful.   If you code for yourself and include your own bullshit or the latest fad conventions you won't.  




#5294672 HTML5 / Javascript , box2dweb, createjs pitfalls?

Posted by on 02 June 2016 - 11:35 AM

Hi,

 

I've created a game using HTML5 / javascript, box2dweb and createjs.    My plan is to publish the game to the playstore and the appstore by using PhoneGap/Cordova.  

 

 

If you have any experience publishing and supporting a game using any of the above technologies could you could share your experiences?   Is there anything I should lookout for?   

 

Thanks




#5266544 Your development workflow

Posted by on 15 December 2015 - 02:27 PM

 

If you had to create a workflow to manage your development process what steps/stages would you implement?  Would you keep it small or make it as detailed as possible?
 
It seems to me that I need a process that starts with a user wish list and ends with a build in production.      
 
Here are buckets I'm planing on using per feature 
 
1. Register 
2. Initial Requirements
3. Review ( Approve / Reject)
4. Detailed Requirements.
5. Approved for Development (enters the development backlog) 
6. Development
7. Unit Testing
8. User / Play Testing (reject / approve)
9. Build & Release


Having a vision for your game and a small amount of planning is definitely beneficial. You don't want to dive into a game project that is too large in scope and you want to have a rough idea of what you final game will be like but this waterfall approach has a major flaw. You cannot anticipate everything you game needs or even if it will be fun in the planning stages. If you lay out a detailed map of what your final game will be like you will find major problems with the gameplay partway through development. At this point you can scrap all the work you did in planning or just stick to the script and have your gameplay suffer because of it.

Alberth describes pretty well what I try to do. Build the game in small incremental steps. Try out the gameplay early with simple prototypes. Be willing to kill an idea that will either take more resources than it is worth or just isn't fun. Identify problems with gameplay and come up with solutions as you find them. Eventually you begin to converge on your final game, which may be quite different from your original idea.

 

 

I think that if the above waterfall method is used per feature it won't have such a flaw.   I agree you can't anticipate everything.  




#5266510 Your development workflow

Posted by on 15 December 2015 - 11:55 AM

 

Mine is very cyclic, incremental:

while not done:
    think_of_a_nice_next_feature();
    try:
        consider_feasibility();
        consider_implementation();
        refactor_for_implementation();
        add_new_feature();
    except FeasibilityError:
        add_learned_lesson_to_knowledge();
end

 

Those are some very critical and important steps that are often overlooked. 




#5266465 Your development workflow

Posted by on 15 December 2015 - 09:21 AM

If you had to create a workflow to manage your development process what steps/stages would you implement?  Would you keep it small or make it as detailed as possible?

 

It seems to me that I need a process that starts with a user wish list and ends with a build in production.      

 

Here are buckets I'm planing on using per feature 

 

1. Register 

2. Initial Requirements

3. Review ( Approve / Reject)

4. Detailed Requirements.

5. Approved for Development (enters the development backlog) 

6. Development

7. Unit Testing

8. User / Play Testing (reject / approve)

9. Build & Release

 

 

 

 

 

 

 

 

 




#5054204 Don't like ending games

Posted by on 17 April 2013 - 09:51 AM

Sadly, may RPG's only let you create character(s) once.  It's odd that a large amount of development effort goes into the character creation process and yet it's only ever used once at the start of the game.      

 

I guess you could handle character death like XCOM does.   




#5047233 Turn Based Action Economy

Posted by on 27 March 2013 - 08:26 AM

Apart from what you already, and the one that you can whatever with what ever action points you have, the alternative is this.....

 

Each turn, a Unit gets 3 different Action Points.

1 Action Point for Movement 

1 Action Point for Action (Offensive or Defensive)

1 Action Point for any of the two.

 

This way, each turn, a unit can ...

Attack Attack Move

Move Attack Move

Move Attack Attack

Attack Move Attack

and such.

 

This will somewhat encourage players to utilize terrains and covers and flanking and positioning their soldiers, and not just keep attacking until one is dead.

 

I like this design.    Especially the Attack, Move, Attack option.    Far too many systems just end movement once you attack.

 

I just think I need more options for Defensive actions.  So far I only have Dodge and Tumble.    Actions like parry, disarm,  or block are provided per weapon.    If you have a shield you can block or shield bash with it.   If you have two weapons you can make a parry with one and disarm with the other, or even make a parry with each weapon.   The reason for this design is that I have weapons and shields that provide different bonuses to parry and block attempts.   

 

I just need to find a system that fits elegantly with my design and doesn't over complicate things.   So far the added touch of realism is making this game a little more complex than I had anticipated.  




#5047231 Turn Based Action Economy

Posted by on 27 March 2013 - 08:18 AM

You don't have a buffs/debuffs/charge up for next turn category?  But I personally like systems where actions cost AP varying from 1 to 10, and a normal unit has somewhere between 5 and 8 per turn, and you can do however many you can afford, so different combinations of moves are optimal for different units.  In that kind of system MP are separate, except that your AP abilities can give you more MP or require you to sacrifice MP.

 

This is a good idea.   I actually was toying with this concept the other day, but I just don't know what each unit could possibly spend them on each turn.   

 

 
One idea I had was that attacking with a weapon would cost you one action point.  This might serve to balance out dual wielding (1 point each).  In addition, movement could cost you 1 point for every 2 squares (or more depending on unit movement rate).   As you move your character you see your action point total reduce.
 
Currently, my attack actions all have options.  Each unit has by default one Action per hand with options that are dependent on the weapon equipped (slash, bash, stab, shoot, hack, grab (available when unarmed), subdual, etc.   What this means is that the player selects a target, selects his weapon attack, and then picks an option.    
 
Things like trip, disarm etc are all untrained options available to all units by default.   Feats/Talents only serve to improve them.  Weapon types also improve upon these default abilities.  



#5046972 Turn Based Action Economy

Posted by on 26 March 2013 - 11:56 AM

I'm currently making my first turn based tactical combat game and I'm interested in your feedback.

 

So far I've grouped all actions into 4 categories

 

1. Offensive

2. Defensive

3. Movement

4. Incidental   (for actions like falling prone, taking cover,  or opening a door)

 

Actions are managed by action points.  Every unit gets 2 action points per round which can be spent on offensive, defensive, or movement actions.   Incidental actions are free actions. 

 

What this means is that in one round you can

 

1.  move, attack

2.  move, defend

3.  move, move

4.  defend, attack

5.  attack twice

6.  defend, defend   (full defense)

 

At the moment, I just need to figure out how my 6 armed troll will attack.   At this point I might have to create several action points per category, but I'm not sure I like how complex it seems to make the system.     

 

 

Can any of the experts here suggest a better action economy?




#4971941 Inventory System Design

Posted by on 21 August 2012 - 01:31 PM

And doesn't it sound fun to put bunnies in sacks!?


lol... Can I use this in my game? I think the demo will have a few sacks with bunnies in them. :) Perhaps it will be an ingredient for fresh rabbit stew.

hmm actually, I could add a decay factor to the items. Food could go bad and and live animals might die if you don't feed them.


#4971614 Inventory System Design

Posted by on 20 August 2012 - 02:40 PM

Over the last week I managed to put together an fairly realistic rpg inventory class.

I'm mulling over a few concepts and I'd like to know what some of the more experienced game designers here think.

Realism vs Inventory Tetris

At this point, my inventory component supports nested container objects (much like a tree), in fact any item can be a container. My thought was that inventory could be presented in a tree view, but after reviewing the inventory system of several games like fallout, skyrim, diablo, nwn, and even some anime like rpgs, I've been debating if gamers would really appreciate a nested tree concept.

Personally, I'd really like the idea of being able to place a bunch of items in a sack and trade the sack to another party member. Of course, my system would allow you to place several small sacks full of gear into a large sack and then place the large sack inside your backpack. The system also has container size restrictions, which prevent you from placing a suit of armor inside a small pouch.

Coinage
One other concept I'm debating right now is how to best represent gold. I recall playing Ultima Underworld in which gold was an actual (gold pile) item in your inventory. Actually, that game is one of the only games I can find with a realistic inventory system.

Stackable Items
Stackable items is another concept I noticed in many of the games with inventory Tetris layouts. 24 Arrows per slot, 10 throwing daggers, 20 potions of healing, etc. Why not simply allow an endless number of similar items to be stacked together?


IMO, provided the presentation layer doesn't cause any frustration, I appreciate realism in my games.

Thanks.




PARTNERS