Jump to content

  • Log In with Google      Sign In   
  • Create Account

We need your help!

We need 1 more developer from Canada and 12 more from Australia to help us complete a research survey.

Support our site by taking a quick sponsored survey and win a chance at a $50 Amazon gift card. Click here to get started!


Member Since 07 Aug 2012
Offline Last Active Aug 15 2015 11:28 AM

Posts I've Made

In Topic: Appropriate number of bugs

12 November 2013 - 05:21 PM

I'm amazed by the quality of the answers here at Gamedev (and that we actually get a response!). Thanks!
I'd like to clarify some things.
Our team is just two persons, who work with the project after the day job. This is kind of a hobby, but a little more serious than a hobby.
Sometimes the team morale isn't that good. I guess having ownership is a double edged sword. I don't have anyone except myself looking over how I'm performing, and some days are better than others. Some days I really get into the flow, other days I'm just to distracted / tired / sleepy / fogheaded to do anything good.
Most observations above are correct. I like to start new and cool features before I get to completely finish old features. Again, this is on the edge of the sword again. Sometimes having a partially working feature makes it easier to see if a feature is worth keeping or throwing away. And sometimes it's easier to come up with ideas and features when there is something (partially) playable.

In Topic: Appropriate number of bugs

10 November 2013 - 05:53 PM

Hi there.


Thanks for your time. The bugs we're facing are more or less "design bugs", which is as you say, a result from a lack of a detailed design document on paper. But on the other hand, when we started this project we didn't have any idea of what game we were making. We started by making a terrain generator, where you could play around (goof around) and destroy the terrain.


The code is written in C++, and we're using the Entity-Component model with messages for passing information / data between the different parts of the game. The technical part of the code is robust (namespaces, library wrapper projects, not reinventing the wheel etc).


For some of the actual bugs we're having at the current time of writing are:


- No shadow on certain objects

- Some objects intersect (physics model is smaller than the graphics model)

- The game sometimes crashes hard.

- Certain objects are not loaded when loading a savegame.

- Some Components aren't cooperating that well (the small buddies, your helpers, are just goofing around when they should be gathering resources for you)

- Player has the wrong orientation when starting / loading the game

- Trees aren't unloaded when the terrain under is unloaded.


It's just an example of some of the bugs present.


We have unit tests, but it is too time consuming to implement for many of the components of the game. There are tests for the code which is simple to test (math, vector++). It's not trivial to implement tests for unloading of objects when the terrain is unloaded, and it takes time to maintain those tests when the original code changes.


Are there any best practices when there isn't a detailed design document explaining every detail of the game?

In Topic: Monday morning code...

23 May 2013 - 03:03 PM

I once made this "beauty" at work...


// Write
bool result = insert(results, data);

if ( m_CurrentSet )
       result = result || insert(*m_CurrentSet, data);

The idea was to store the latest of anything that has been written to file in memory, to make sure the latest set of data was in memory. However, this being a real time application, which in theory should run forever (and generates data for a multi-million dollar service), the results were pretty poor.


No harm done, since this was in a test and not production.

In Topic: Some ideas on what to do with our game

06 January 2013 - 05:20 PM

First, I want to thank all of you for taking your time to help us, we really appreciate it!
Here are some more details about what we thought of before we started development:
- An open world game where you could do everything possible in games (build like in Minecraft, shoot monsters, explore, dig...)
- A game without a goal (is it possible? Minecraft didn't have a goal at the beginning, but was fun)
- And we thought we'd figure out gameplay later.
An important thing about the engine and why we can't really throw it away - we make it ourselves so it's easier for us to change it as well.
So far, we've had no clear visual style or theme. Since neither of us are artists, some things have been kept primitive to get progress and something working. Now we have that something working fairly well, and no good gameplay ideas have popped up.
Reading from your feedback, the most important items are:
* Immersion.
* Consistent theme / visual style.
* Sound for everything.
* Smarter enemies.
* Cause and effect.
* Limited resources.
And finally, we'll polish and keep flying.

In Topic: Sphere acting like a ball in Bullet Physics

06 November 2012 - 03:21 AM

Is your colShape a btSphereShape? Another option is to give it more mass.