mattwindsor91 / crystals Goto Github PK
View Code? Open in Web Editor NEWFree software monster-battling role playing game.
License: Other
Free software monster-battling role playing game.
License: Other
The tests in src/tests/ are unusable, because of the unified error message. There will be even more functions, types and whatever which makes it impossible to use those tests unless we compile everything into them and setup up a complete environment (g_config, etc).
The only option I can think of is to remove them. They were usefull for testing the specific parts of our game before we created dependencies on other files. But now they're broken and useless (and I can't fix them).
Since I'll be away for a week's holiday with a computer but no Internet, and I'm not by any stretch of the imagination the only person working on Crystals, I thought it would be a good idea for us to discuss which areas of the engine we're interested in working on in the near future (to avoid reduplication of effort, and suchlike.)
Items I'm looking to work on soon (some of which will be done over the week) are:
Pursuant to something barrucadu raised in person, and given that there is such a lack of development interest in the project, I've decided to drop the formal procedure for merging changes.
As of now,
Apologies to giselher, who I'm aware gets left out of a lot of discussion about the project because of majority consensus being achieved by myself and barrucadu all the time.
It's time, in my humble opinion, for the first ever crystals feature freeze!
In a bid to ensure all code contributed to crystals so far is of optimal quality (both written and compiled), normal progress on crystals is going to halt in order to allow for the work currently in staging to be properly reviewed and prepared for master.
The code review will take four forms:
No more feature pulls will be allowed into staging between now and the closure of this issue. The final push to master in this space will likely be tagged as version 0.01.
Hopefully, there will be a more detailed action plan going up soon.
Thanks to everyone who has worked on crystals so far! Even though crystals isn't capable of much yet, it's a start and I think the amount of work that has gone into it despite university and other more important issues is something to be proud of.
~ Matt
PS: Java map editor will be going up shortly.
As per something barrucadu mentioned a few days ago, I'm putting this to a sort-of vote/comment/etc.
The proposal is to stop targeting a pedantic flavour of C89, and instead target the GNU dialect of C, and also assume the presence of glibc.
Specifically, the change proposed is to:
CFLAGS := -ansi -pedantic -O2 -g3 -ggdb -DDEFMODPATH="\"$(MODPATH)\"" $(WARN)
CFLAGS := -O2 -g3 -ggdb -DDEFMODPATH="\"$(MODPATH)\"" $(WARN)
I'm happy either way. I know that other developers are probably strongly in favour of this, though. =D
Here are a few things I thought there should be a bit of discussion on:
The current idiom/style is:
if (do_something () == FAILURE)
{
error ("CODE MODULE NAME - function name - Error string.");
return FAILURE;
}
if (do_something_else () == FAILURE)
{
error ("CODE MODULE NAME - function name - Another error string.");
return FAILURE;
}
One alternative would be:
if (do_something ())
{
if (do_something_else ())
{
...
return SUCCESS;
}
else
error ("CODE MODULE NAME - function name - Another error string.");
}
else
error ("CODE MODULE NAME - function name - Error string.");
Personally, I prefer the first approach, as:
It keeps the error messages close to their originating functions.
It's more compact, and doesn't cause a massive load of indentation.
Idiomatically speaking, it represents a linear progression of "Try this; did it fail? If so, stop. Try the next thing... etc... everything done, the procedure was a success."
However,
It introduces many return paths, which could be considered bad coding practice.
Putting function calls in if statements seems a bit strange. This could be rectified with something like:
bool_t result;
result = do_something ();
if (result == FAILURE)
{
error ("CODE MODULE NAME - function name - Another error string.");
return FAILURE;
}
but in my opinion this is a bit long-winded.
This is a practice that I'm personally in favour of.
For an example in the current code, consider this extract from map.h:
/* -- TYPEDEFS -- */
typedef uint16_t dimension_t; /**< Type for tile-based map dimensions. */
typedef uint16_t layer_tag_t; /**< Type for layer tags. */
typedef int32_t layer_count_t; /**< Type large enough to hold a layer count. */
typedef uint16_t layer_index_t; /**< Type for layer indices. */
typedef uint16_t layer_value_t; /**< Type for layer value data. */
typedef uint16_t layer_zone_t; /**< Type for layer zone data. */
typedef int32_t zone_count_t; /**< Type large enough to hold a zone count. */
typedef uint16_t zone_index_t; /**< Type for zone indices. */
typedef uint16_t zone_prop_t; /**< Type for zone properties bitfields. */
Each typedef assigns a concrete integer type (stdint.h-style types, themselves typedefs) to another type encoding its semantics.
Arguments for:
Disadvantages:
This is somewhat more controversial practice and one that I'm very open to input on.
An example in the current code:
typedef struct map
{
dimension_t width; /**< Width of the map, in tiles. */
dimension_t height; /**< Height of the map, in tiles. */
zone_index_t max_zone_index; /**< Highest zone index in the map. */
zone_prop_t *zone_properties; /**< Array of zone property bitfields. */
layer_index_t max_layer_index; /**< Highest layer index in the map. */
layer_tag_t *layer_tags; /**< Array of map layer tags. */
layer_value_t **value_planes; /**< Pointers to map layer value planes. */
layer_zone_t **zone_planes; /**< Pointers to map layer value planes. */
} map_t;
If struct typedefs were to be allowed, it would likely be a style point that the typedef name and struct name share the same root. That is, the structure with name NAME would be accessible either as "struct NAME" or "NAME_t".
Advantages:
Disadvantages:
My personal opinion is that pointers should /not/ by typedef'd as regular types (eg no typedef struct map* map_ptr_t, as it hides C pointer conventions (eg passing by reference) and would likely lead to Hungarian notation popping up to differentiate between variable types and pointer types. Comments?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.