Jump to content

  • Log In with Google      Sign In   
  • Create Account

frob

Member Since 12 Mar 2005
Online Last Active Today, 03:08 PM

#5306000 Good C++ Learning Materials For A Beginner

Posted by on 15 August 2016 - 11:18 AM

I'm seeing how unhelpful the book is.  It's a shame I have to use it for this coming semester too.

 

That's actually a good thing.  The more you code and books you are exposed to the more you can learn.  As you gain experience you'll see some patterns that work well and some that are poor or ineffective, these days they are called anti-patterns.

 

Learn from as many sources as you can.  

 

The biggest benefit of academic studies is that it forces you to be exposed to ideas you may not normally want to study, yet it only gives the shallowest exposure to the topics. You should do as much learning as you are able on your own. 




#5305837 Handling Items in RPG

Posted by on 14 August 2016 - 08:12 PM

Here is a discussion from two weeks ago, with several different examples of ways to do it.




#5305835 Use of user journeys in game development

Posted by on 14 August 2016 - 08:09 PM

I know we've never used them, at least to my knowledge.

 

From the description, it looks like the kind of thing instructors put in to try to prove that a concept is used in industry where you look for something that doesn't exist, find things that somewhat match what a person might have done, and thereby establish to a young impressionable student that it is actually industry standard.

 

 

There are times where people describe what a user might experience. It is good for products to develop a series of statements about a product. There is the single statement about what your product is. There is the "elevator speech", fast enough you can give it when stuck in an elevator and someone asks "what do you do?", typically from 20-60 seconds. There is a two-minute version. There is a two page version. And there is a 10 page description or overview or pitch.

 

All are quite different from "user stories", which are descriptions of tasks or features inside a program. Like "As a user, I can pick the 'game options button' and be shown the features for the game, including this and that and the other."




#5305586 Interfaces and code duplication

Posted by on 12 August 2016 - 10:57 PM

As this is For Beginners, trying to stick with answering your actual questions before the educational aspects...

 

 

 

Every Java resource I've read goes crazy on the idea of interfaces, and uses them for almost everything. What I don't get however, is how they are better than plain old inheritance.

 

 

Because as far as software architecture goes, it is a much better design in general.  There are some specific cases where that isn't true, but in the general case you should depend on abstractions rather than concrete types.

 

The are better than "plain old inheritance" because depending on an abstraction means you can add whatever implementation details you want later and they automatically fit into the system, they just work.

 

An example I frequently give is with graphics systems.

 

Programmers rely heavily on the abstract classes in Direct3D yet they don't care one bit about the concrete types.

 

I request an ID3D11Device* and it just works.  I can do all the things I want to with that device.  I don't care if the device driver actually implements it as an ID3D11GeForce620, or an ID3D11Radeon6230, or an ID3D11IntelHD4400.  The only thing I care about is that it does all the things an ID3D11Device is supposed to do.

 

I can use my object, no matter what the final concrete type happens to be, and it should work perfectly.  Every concrete type is completely replaceable with any other concrete type.  It does not matter which one the system provides.  If I obtain something that implements an interface it implements it perfectly and could have been interchanged with any other object that implements the type.  That doesn't mean they perform identically, different graphics cards from different eras may perform faster or slower, or may perform different operations at different rates, but (barring driver bugs) they will always implement every operation exactly as specified, and you can do all the operations on any card that follows the interface.

 

I shouldn't ever need to write code that detects what specific device it happens to be and write special-case code for that concrete type; instead I can use the provided interface and decide based on that.  Some functionality may differ between cards but I don't need to hard-code every single card that can support the feature, I can rely on the interface to query if the feature exists by getting device capabilities.

 

That last point also allows future-proofing.  If I write my program that works on all of today's cards, and sometime in the future someone introduces a new card with different capabilities, it just needs to implement the right interface and it drops in perfectly.  If it provides different capabilities they must be queried exactly the same way the interface allows for querying capabilities.  

 

I don't need to modify today's program to support a new graphics card that ships three years from now, it will still work perfectly because it follows the same interface and is completely interchangeable with any other graphics card that also implements the interface.  By following the interface everything works perfectly right out of the box.

 

 

 

 

 

 

 

For another example, let's say I implement an event bus in my system. I want to be able to broadcast "Here is the event" and have everyone listen.  I don't care what systems are listening, they can be logging systems, they can be networking systems, they can be debuggers, they can be game event handlers, they can be anything else.  All I care is that they implement the interface called IEventBusListener.  If someone six months from now, or six years from now, decides to implement some code that implements the IEventBusListener interface they can add it to the code base and it will work perfectly.

 

For another example, let's say I'm working on a game and I want to find the nearest thing in the map that is a weapons spawner.  The foolish way to do that is to look for a specific list of weapons spawners that the developer happened to know about when the code was written.  If sometime later somebody adds another type of weapon they need to search for all the places in the code that relate to the weapons and hope they update all of them correctly.  It is impossible for someone to come along and add a new spawner type without modifying all the source code.  The smarter way to do it is to provide an interface, perhaps IWeaponSpawner, and search the map for anything nearby that implements that interface. If sometime later someone adds another type of weapon in the world it is automatically hooked up and completely integrated into the system.  (This works just as well for component based or ECS systems, some happen to use a slightly different identification method rather than inheriting an interface, but the overall design is identical. Look for something that implements the component, something that implements the interface, something that claims it does the action, rather than looking for a specific list of items that you happened to know about at implementation time.)

 

 

When you write code, always write code that depends on the abstract types, on the interfaces.  Only use the operations provided in the abstract types, on the interfaces. This helps all development down the road and new code can just drop into place.

 

 

 

 

Say I have a class GameObject, being the abstract base class for everything in my game. Something in the game might be a visible physics object, so if I want an object that does that using Interfaces, I would write a Renderable interface and a Physics interface and implement both. But say I have an object which doesn't use physics. I would have it implement just the Renderable interface.

 

You could do that, but most systems don't.

 

As mentioned above, this is a HAS A interface. This is composition, not an interface.

 

A game object does not satisfy IS A.  Trying to replace them doesn't work.  Swapping it out, a game object IS A model doesn't make sense.

 

A game object HAS A model.  Or maybe it doesn't.  Or maybe a game object has several models.  Maybe there are models for "Full", "2/3 Full", "1/3 Full", and "Empty".  Maybe there are models for "Base Started", "Base 10% Complete", "Base 20% Complete", "Base 30% Complete" ... "Base 100% Complete".  Maybe there are models based on damage taken, or based on state of repair.  You might implement an interface that says your object potentially has a model and request a reference. 

 

Again, your game object does not implement the interface to be rendered. It is not a thing to be rendered. You should not be able to swap it out with any other thing that could be rendered.  It may expose an interface to provide a reference to a renderable object, but it is not renderable itself. 

 

 

 

Similarly with physics, a game object HAS A physics shape.  Or maybe it doesn't.  Or maybe the game object -- a character -- has a capsule physics shape when running, a sphere physics shape when squatting, and no physics shape when deceased.  Once again, you might implement an interface that says your object potential has a physics object and request a reference to it, but it is a HAS A rather than an IS A relationship.

 

 

 

Why are Interfaces used instead of just Inheritance alone?

 

 

There are a set of programming principles under the great acronym SOLID.  Through a bunch of trial and error, people have discovered that when you implement these principles in your code designs it goes a long, long way in keeping your code maintainable. It helps reduce bugs. It helps make it easy to swap out systems, to extend systems, to reuse systems.

 

Interfaces enable several of those principles.

 

Yes, interfaces have a small cost of a few nanoseconds when they are followed.  If there is only one concrete type and there will only ever be one concrete type you should consider just using the concrete types directly rather than using virtual dispatch as interfaces or abstract types use. For Java, that means marking this as final.  The O in solid, the Open/Closed principle, means to keep things open for for extension (meaning you can make new behaviors and extend on it but it is also closed that it must implement exactly the behavior of the base or abstract type, and be completely interchangeable with it.  If you are not following this rule, when something is closed to both, make sure you make it completely concrete, and in Java that means marking it all over with final so you're not paying the cost since java is virtual by default.

 

However, any time you want replaceable parts -- and you almost always want replaceable parts -- it is the cheapest method available because every system out there has heavily optimized the pattern.  

 


Use interfaces or abstract base types or whatever they are called in the various other languages when you need it, and you almost always need it.  They are a great solution to many problems that every experienced programmer knows and every tool recognizes and makes faster for you.




#5305422 Estimating development time

Posted by on 11 August 2016 - 09:07 PM

I need tips on how to better estimate development time for games.

Experience and training.

The way I most improved my estimation was being the only programmer on the team. I estimated all my programming tasks and was held accountable -- via extra hours -- for my estimates.

If you aren't accountable for your estimates in a very real way it is difficult to be motivated to improve them.

Also if I were to give you a project like this, how long do you it would take to develop it from start to finish? Assuming there is only one programmer and one artist and the game is being developed in Unity.

Features are very terse, there isn't enough detail for good estimates.

Endless runner, IOS & Android, Unity engine, single player. By itself if you know what you are doing and want to make a potentially viable commercial product, I'd say bare minimums of 4 months programming and 3-4 months art. That's for a terrible product that cannot compete commercially but at least is not embarrassingly bad on the marketplace. If you aren't already experienced and don't know what you're doing I'd say at least 8 months programming (or far more, depending on the programmer's skills) and 4-8 months artwork, since the artist may have to rework things many times.

Online cross platform multiplayer for 4 players is going to add about two months programming if you really know what you are doing and your app is built for it up front, easily six months or more if you don't or the app is wrongly designed for it, and you'll need to include QA because bugs are hard. Artwork is UI, so far less time, perhaps a few weeks.

The random powerups are not that difficult, maybe another 1-2 weeks programming and whatever time is needed for art depending on visual complexity, perhaps a few more weeks if you have many diverse powerups or they do different things.

The link to facebook could be fairly simple if it is just posting directly, there are components you can buy that do almost all the work, add two weeks if you're using one of those, one if you've used them before and know what you're doing. Otherwise add in about a month, or two if you are learning how to post everything for the first time. If you want more than that, maybe full facebook integration and all that jazz you can add a full development year or even multiple development years.

Same for twitter. If you're just posting, and using a plugin, or just posting using their direct API, about the times mentioned above.

In-game chat basically comes for free with the other networking. Maybe 1-2 weeks for UI if you know what you are doing, more time if you have to learn how to handle UI and text input.

Friend invites, friends list, and join-in-progress all mean trouble unless you've got a lot more infrastructure than you are hinting at. Far beyond the scope you're mentioning.

Global leaderboards are a huge risk, I wouldn't touch them. The simple solutions are the most hackable, and they tend to become cesspools.

Having in-app purchases itself isn't too bad but you didn't list what it is that is going to be purchased. If you use a good cross platform library you won't need to write anything yourself, just hook in to a cross-platform entitlements system.

Ads will depend on the types of ads you use and the libraries they provide. Anywhere from one month to six months to implement, depending on your skill and experience.



The bare-bones "I can show my friends I made a game" endless runner could be done in about a month of programming work, about the same in art. The "I made a product that has the tiniest chance of being commercially viable" is anywhere between one to three years of programming work and anther year or so in artwork.

If that wasn't enough, the market for endless runners is not favorable to newcomers. The niche is saturated and even an amazing product is unlikely to succeed.


#5305358 Life as a Tools Engineer ( in game development )?

Posted by on 11 August 2016 - 01:08 PM

I have reached a point in life where the sort of hours you work in this role aren't meshing with my family life.
 

 

Stop working those hours.  It depends on the company, but from those I've worked at they are not required by management, but instead worked quite voluntarily by those on the team. I've been on teams where a few people run themselves ragged with extra hours and stay late into the night, and others on the team work exactly a full day and leave at 5:00 on the dot. In such environments there are engineers who (mistakenly) believe that the entire company success hinges on their putting in unreasonable number of hours.  If management truly is demanding you work more hours than are standard for your nation, change companies.

 

The last company I worked with the entire office of several hundred people was typically vacant around 4:45, those who remained were finishing up their daily tasks. It is entirely cultural, and sadly many studios operate in startup mode, taking on the behavior of the company founders who are fully invested in the company rather than a worker at the company.

 


1) see if anybody here has been/is currently a Tools Engineer in the Games Industry?  

2) What is the day-to-day like?  

3) What are the projects like?  

4) What are the hours like?  

5) I have worked with Tools Engineers in the past, and I am curious about the role.

 

1) I've worked on tools teams at two companies.  Many others here on the site have worked and are working in the role.

 

2) Day to day it is a programming job.  Instead of gameplay tasks like "write a script for weapons spawners" it is tools tasks like "write an importer for Collada files".  The exact needs depend on the team's needs.  They may need stuff for the engine, stuff for content pipeline, stuff for build systems, stuff to make various people's lives easier.

 

3) Every project is different. I've built image compositing tools, tools for processing resources for Nintendo DS, art tools to help the artists view their assets faster, engine tools for screen layout, engine tools for data parsing, pipeline tools to help the build system, tools to help designers modify data more easily, tools to extract game statistics that are run automatically and appended to a file to generate trend lines.  Lots of tools out there.

 

4) Hours are whatever you let them be, as above.  A small number of companies are abusive, don't work there.  Most companies have sane core hours, many in this industry are more than willing to let foolish young workers abuse themselves with late hours if the workers wish. Pay attention to detail of what management says, if the core hours are 9:00 AM -4:30 PM, you shouldn't routinely be at the office at 6 PM or even at 5:30 PM.  Yet I've been at companies with those core hours and a few people still put in 9-hour, 10-hour, even 12-hour days. Mostly those were young, single adults with no real life to speak of.  

 

5) If you've worked with them you should basically know the role.  It isn't too radically different from gameplay engineers, it is still writing code to solve problems, just uses different topical areas of code and different software libraries to accomplish it.

 

I know that their schedules are often different than the rest of the team, since they are in a support position.

 

That depends entirely on the company and teams.  Nearly every company I've worked at everyone has had the same core hours, except for QA who often arrives a few hours later in the day and works the same number of hours later in the evening.  

 

Those rare teams that had different hours usually worked with other remote groups in different time zones.  When you've got teams on US Eastern Time and British Time, the US people arrive early and the UK people may work later.  When you've got US east coast and US west coast teams the west coast people may need to arrive at 8 AM, the east coast may not arrive to the office until 10 AM.  




#5305336 Confused about 3D game dev

Posted by on 11 August 2016 - 10:15 AM

now im just confused to start which one?

 

 

Any of them will work.

 

 

 

also don't know basics of 3D gamedev ... can use only free resources on internet 

 

 

In my view, the biggest thing you need is the math of 3D worlds.

 

When you are in the 2D world you need 2D points (x,y), you need 2D vectors of (dx,dy), you need orientation which is typically an angle from a top-down view.  The mathematics to work in the world are elementary algebra, discrete trigonometry, and geometry.  That is, the math of elementary algebra to manipulate formulas and equations, enough trigonometry to handle the basic trig functions to manipulate the world, and enough geometry to handle things like circle/circle intersection, circle/line intersection, etc.

 

When you are in the 3D world you need 3D points (x,y,z), you need 3D vectors (dx, dy, dz), you need orientation which is typically a 3x3 or 4x4 matrix from the world's origin.  The mathematics to work in the 3D world are linear algebra, algebraic trigonometry, and topology, in addition to the math of 2D worlds.  That is, in addition to the math of 2D worlds above you need linear algebra to manipulate matrix and vector equations and higher dimension coordinate systems, enough algebraic trigonometry to manipulate polynomials as they operate in 3D, and enough topology to understand how to work with polygonal meshes in 3D space.

 

If you're looking for a good, free, online textbook consider this one.  If you're looking for tutorials and videos, Khan Acadamy covers many of those topics.

 

When you are starting out, many people are able to hobble along without actually knowing that math. They will try to find math functions that give them their forward vector and up vector and similar without actually knowing the math involved, they will try to figure out what is forward-facing or backward-facing and with some luck stumble upon a web site that explains it. They will look at the programs that show them model meshes and try to figure out the names and words and manipulations through trial and error.  Some people are able to get started that way, but ultimately you will need a solid understanding of the math to succeed.

 

 

i use C++ for game dev, do you think i need more languages in future or i should start to learn more languages right now like c# or java?
 

 

Any of those will work.  C++ is adequate, and Unreal Engine uses it.  C# is adequate, and Unity uses it.  If you only know C++ then Unreal Engine may be a better fit for you right now.




#5305180 How To See A Router's Forwarding Table?

Posted by on 10 August 2016 - 03:48 PM

Sometimes I miss the bad old days when network hubs were not switches, when computers didn't have firewalls, when all IP addresses were right there on the public internet.  

 

Networking was so easy when I first learned it. You could just reach out to a dotted quad and a port and it would talk with you.

 

Of course, in the modern world, such systems would be attacked by random strangers on the internet within a few hundred seconds. Depending on the source the average time for an unpatched machine to be attacked with a raw connection like that is anywhere from two to five minutes. Sad.

 

Congratulations on getting through the configuration hurdles. Hopefully now everything will fall into place.  If you can implement raw communications, a basic chat with raw sockets, you can implement anything on top of it.  




#5305173 What Would You Do If...

Posted by on 10 August 2016 - 03:21 PM

No name that I'm aware of. Universal computability, perhaps? Computational universality?  I didn't spend a lot of time with those studying the topic, and I really only learned enough of it to get me through the graduate qualifiers, and that was years ago. (Meaning I could teach the undergraduate theory courses with the help of a good book if I needed to.)

A bit of Google and Wikipedia shows it dates back to the 1600's, the mathematician Leibniz was building the first computing engines and wanted to build a machine that could evaluate the truths of the universe on its own. It closely matches the described "scientific modeling simulation of a god"; knowing all truths of the universe through mathematical means. Through the 1700s and 1800s it was a common theme, building computing machines and engines that could compute everything, seeing if there could be elements of the universe that were not computable, that sort of thing.

 

Over the centuries it evolved into the full branch of mathematics and computer science called "computability", and it includes proofs that certain properties within the universe absolutely cannot be computed.  Some of them are provably uncalculable. Others are provably undeciable, you can never make an algorithm that is correct for it. Still others are calculable but are intractable, a solution could exist but the solution requires more effort or space to compute than the Universe can contain.

 

This type of scientific modeling of the universe can make simple simulations and gross approximations, but the full real thing of a complete universal simulation is believed to be noncomputable.  In simpler terms, it is easy enough to make The Sims or Farmville, a lot harder to make an accurate weather simulator, but a simulation of "Our Actual Universe 2.0 (now with real physics)" cannot be constructed, it is believed noncomputable.




#5305143 What Would You Do If...

Posted by on 10 August 2016 - 11:38 AM

when I say it is a "scientific modeling simulation of a god", that is something very specific. ...  It creates all of its reality, and plans the future of every individual "living thing" within its reality.

 

In an effort to throw a final constructive spin on this...

 

It is an interesting idea.  Once upon a time it was a hot research topic. People were hugely interested in discovering if it was even theoretically possible to implement this.

 

The answer came back as a resounding NO. Big names started a whole new field of mathematics that eventually became computer science, all in an attempt to answer that question.  Kurt Godel did a ton of research on it and came up with proofs that several parts absolutely cannot work, there are operations that fundamentally cannot be carried out, there are statements that can neither be proved nor disproved within such as system, and such a formal system cannot show itself to be self-consistent. Alonzo Church invented lambda calculus (horray!) in the process of trying to prove the parts of that simulation and ended up providing a proof of undecideability. Alan Turing had a parallel line of research and papers, and ended up working with Church. In trying to prove that such a simulation was possible they ended up discovering the opposite, they constructively proved that such a system cannot be made. Even Stephen Hawking dug into that problem for a while, and gave up on it as he wrote in his book "God Created the Integers".  

 

Many mathematicians and computer scientists, both famous big names and minor researchers, have tried to construct rules and systems that work around those problems. Every attempt to solve it has resulted in negative results. Even in today's software, Mathematica was originally written in part to help visualize a potential solution around the problem using FSMs, but like every other solution ended up with negative results. Fine software for computing all kinds of things, but it offered yet another proof that such a thing cannot be made.

 

The basic idea of such a simulation is tantalizing. It seems a natural fit for exactly what computers can do.  But as you get far along the process there are problems that so far nobody has been able to overcome.  Back in graduate school our CS department had a series of lectures about this exact item. It is a holy grail, a thing that people seek out but likely doesn't exist.

 

 

 

 

Yes, there is a remote possibility you have come up with an idea around all the existing problems. It is possible you have designed a solution that doesn't trigger undecidability, doesn't trigger incompleteness, doesn't trigger the halting problem, doesn't break Piano's axioms, doesn't come across Hilbert's Problems.  But really, unless you can articulate exactly WHY and HOW you get around that, nobody will give you the time of day. As the one proposing the idea, the onus is on you to show that it actually works. An enormous body of research has found reasons it doesn't work. If you found a way to make it work, you really need to prove it before anyone will listen.




#5304952 How To See A Router's Forwarding Table?

Posted by on 09 August 2016 - 01:46 PM

You look it up in the manual for the router.  If you don't have the manual, Google.

 

If the web form has two numbers it is probably for a range.  Many applications follow a range of ports such as 6881-6889 TCP.  In that case you'd probably enter the first and last port in the range.




#5304768 Runtime Error With Opengl App

Posted by on 08 August 2016 - 05:09 PM

You're following a null pointer.

 

#0  0x00000320 in ?? ()

#1  0x004020cb in StateManager::Loop (this=0x6bfeec) at src/StateManager.cpp:81
 
The first line, #0, the address is a very low number. This commonly happens when the compiler is looking at a null pointer (typically address 0) plus the offset of a data member.  In this case, it is probably looking at 0 + 0x320, meaning it is looking for a function or data member 0x320 bytes in to a null object.  (The value 0x320 == 800, meaning the address is 800 bytes in, which is fairly large for a non-resource object in C++. You might consider trimming your object size.)
 
Fortunately you've got another line in your dump. When the first line is a very low number like that generally you look at the second line, #1, and nearly always this will be a line of code that calls into a pointer.  In your case, it is src/StateManager.cpp:81, which reads:  (*it)->Event ();  Jackpot, you've got a few of them.  You dereference an iterator, then you follow it as a pointer.
 
So now to see what the iterator points to and what it contains. Look up one statement before for the definition, and this is the first line any of those items were used, which reinforces that one of the values are bad.  The line that initialized it was: auto it = m_states.begin() + m_current;
 
So that gives a few possible errors.  
 
For one thing, you don't check what happens if m_states is empty.  Even if m_current is 0 you invoke undefined behavior.  If the container is empty, the .begin() function will equal .end() and it is undefined behavior to dereference it.   Bug #1.  Ensure your container is not empty before using its contents.
 
It is also undefined behavior to move past the .end() of a container.  You can reach .end(), but it is undefined to advance beyond it. Bug #2. Stay in range.
 
Next, if your m_states contains data but m_current advances to the end or beyond the end, then .begin() gives an iterator to the first one and the addition moves it forward. Depending on which condition the same as above, either you are forbidden from dereferencing that value, or you are forbidden from advancing past the end. Potential bug #3 because you don't validate either case.
 
Alternatively, your line of (*it)->Event (); could have a perfectly valid iterator, but the contents of the iterator are a null pointer.  It is undefined behavior to follow a null pointer. So potential bug #4 is that you have stored a null value.  If null is a proper condition for your code then you need to test for null before following your pointer.  If null should never be allowed then you've put bad data into your container and you need to hunt that down.
 
Drop a breakpoint on line 79 and inspect the values to see which of those conditions you triggered.  Whichever way the problem lies, you should modify your code to address and prevent all four possibilities.



#5304460 Detailed Work Flow For Two Member Team.

Posted by on 07 August 2016 - 01:20 AM

The same patterns apply on tiny teams.

Start small and simplify. Then prioritize, noting dependencies. Break work down into tiny pieces, about what can be done in a single day. Prioritize again, noting dependencies so depended-on stuff goes first. Re-review the estimates remembering that work should be broken down to the point where you *KNOW* you can get it done in that time window. (If you don't know how long it will take than you have yet another bundle of work, figuring out what it is so you know.)

Again the key points are to sort by priority and make sure the tasks are broken down into things you KNOW how to do. If you don't actually know how to do it, or are thinking "I'll just look up how to implement a pathfinding algorithm, I've heard about A-Star, should only take an hour or two" then you're in for a shock.

Once you've got everything figured out exactly what tasks you need to do for your small and simplified project, look at the time and work you can do in that time. Make sure the work fits, normally a two week increment is good, often called a work sprint. If you want your first fun pieces to come out in two weeks, and you're able to put 10 hours per week into your hobby project, count out the top 20 hours worth of tasks. That's all you can do. Make sure you can really do it, then do it. Make sure it builds what you want, and review carefully for hidden dependencies or work you may have missed. If it doesn't work out then generate different tasks and re-prioritize until it does. Honest assessments of how long things take are really hard for many people. Most people underestimate the time it takes, and sadly many people underestimate over and over and over again. Work takes time, and game development work is hard. Get good values for the time you expect work to take and get it prioritized.

Then get to work and do it for two weeks.

At the end of two weeks figure out what you can improve on, and do it again.

A frequent recommendation for beginning is to do one month. At the end of one month you have learned a lot. Call that project done and start a new one. After about six months you get to a pace that you know what you are able to do and can create a game in a month, or not. Again, start small and simplify. You won't be making a massive AAA game since those take thousands of work-years. You won't even be making a shove-ware style title as those take work-decades to complete. Think tiny, and even that is probably too big.
Oh, as for specific tasks, you might have "Hook up a character controller", "Add input to character controller", "build a prototype white-box map", "Implement a simple 'attractor' behavior", "Create a player character on the map", "Create an enemy on the map", "Make player move around map", "Make enemy use the attractor behavior to chase the player". And on and on and on.

Good luck on your project. It can be something fun to do as a family, but you absolutely need to keep it simple, especially as it is a hobby.


#5304390 [C++, Oop] Setters Vs. Friend Functions

Posted by on 06 August 2016 - 01:25 PM

In C++, "friend" is a keyword you should never write.  

 

It is something that you might be forced to write when you cannot come up with a better solution, and even then with a great big comment in the code saying "someone help fix this awful situation".  I can't recall using the keyword in code for well over a decade, about 2002 or 2003; that was for a bunch of code that we didn't have the ability to modify for political reasons so we used language-lawyering to get it done.

 

You say you have a collection of actions you want to do.  That is perfect. 

 

Provide an interface to take those actions.  Describe all the actions in the interface. Keep that interface abstract.  Then create an implementation that implements the interface.  Anywhere you code, rely on the abstract interface. Provide a factory method or similar to create and retrieve your concrete implementation.




#5304235 Rpg Stats - Temporary Changes, Harder Than I Realised!?

Posted by on 05 August 2016 - 11:51 AM

Conceeding that point.

 

In my mental model of an RPG, if I get an effect that says "10% bonus to healing", or "5% bonus to fire resistance", I would expect that to account at the end so it is the full amount and the multiplier.

 

I can't recall ever playing an RPG that had effects like "5% bonus to base but not applied to other buffs".  If that is your design and you can message the effect clearly to others, go for it.  But it seems weird to me.






PARTNERS