Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Aug 2012
Offline Last Active Apr 12 2016 04:41 AM

Posts I've Made

In Topic: CEGUI Change static text style inline

28 March 2016 - 02:00 AM

Have you tried formatting tags?

In Topic: CEGUI Text in a CEGUI::FrameWindow

27 March 2016 - 02:34 PM

You should add static text window to the frame.

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.