• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
  • entries
    625
  • comments
    1446
  • views
    1006490

Epoch and Constructors

Sign in to follow this  
Followers 0
ApochPiQ

214 views

One of the things I've been thinking about heavily for the Epoch language is the way constructors work. Epoch does not have null values or default initialization, so all constructors require explicit arguments to satisfy the type requirements of a given variable.

Here's a quick example:

structure foo :
(
integer(NumericField),
string(StringField)
)

entrypoint : () -> ()
{
integer(demo, 0)
foo(demostructure, 42, "test")

debugwritestring(demostructure.StringField)
}


Constructors are actually special functions named after the type which they construct. There is some metaprocessing magic which handles the case where a constructor needs to create a local variable (which is always, at the moment). This is handled by the first parameter to the constructor, which is of type Identifier. The identifier becomes a local variable of the appropriate type within the scope where the constructor function is invoked, and the value is initialized as given by the constructor parameters.

This works very well for the moment, but has a couple of drawbacks. First, it is impossible to construct an anonymous temporary variable, as in the statement somefunction(foo(42, "test")) Secondly, for structures with a lot of fields, it can be tedious to have to explicitly initialize every field every time the structure is constructed.

I have plans for this, though, which should appear sometime in the indeterminate future as time permits.


Overloaded Constructors
Epoch already supports fairly powerful function overloading, and even allows for things like parameter pattern matching. This provides a very convenient mechanism for dealing with the constructor situation.

Anonymous-variable constructors can be implemented easily using a function overload which simply omits the first Identifier parameter. Since the only time that this is really useful is with user-defined structure types, and those constructors are magically generated by the compiler anyways, adding this overload should be trivial. This will allow for construction and usage of anonymous temporaries with ease.

The second case is a bit trickier. Ideally, I'd like to allow users to define constructors of any arbitrary number/type of parameters, so that it is possible to construct non-trivial objects easily, and effectively default-initialize fields as needed (since the language itself does not permit default-initialization).

This can be partially accomplished with the overloading mechanism, which will take care of allowing the programmer to invoke the constructor with the parameter set he desires; the tricky bit comes in with the magic that actually creates the local variables.


On Magic
There are three basic approaches I could take to this. First would be to have copy constructors set up automatically, and require that manually overloaded constructors invoke the copy constructor, so that manual constructors do not directly participate in the magic. This would look something like the following:

foo(variablename, foo("limited_parameter_set_demo"))

This is redundant, however, and requires expressing the type twice - something I've been trying to avoid. I'd like to minimize the amount of explicit typing required by Epoch, particularly via type inference, so demanding that all nontrivial constructors use the above syntax seems a bit wasteful to me.


The second major option is to automatically detect the presence of an overloaded constructor, and have it participate in the magic transparently. This would look a lot cleaner:

foo : (identifier varname, string parameter) -> (foo(ret, 42, parameter))

foo(variablename, "limited_parameter_set_demo")


Unfortunately, this requires a lot of magic. I can't think of any situations where this magic would get the programmer in trouble, i.e. where he wants a function that looks an awful lot like a constructor but isn't; however, I don't want to necessarily take that risk just yet.


Finally, the magic could be explicitly invoked. There's a couple ways this might look, but my favorite would be something like this:

foo : (identifier varname, string parameter) -> (meta_constructor(varname, foo(42, parameter))

foo(variablename, "limited_parameter_set_demo")


This defines a magical function return type called meta_constructor. When this magical type is used as a function return, it invokes the correct magic under the hood to construct the variable given by the first parameter in the calling scope. This all happens at compile time, so the runtime overhead would simply be offloaded to invoking the anonymous constructor and copying that value into the newly constructed variable. A tiny bit of optimization can make the copy go away entirely, so that the variable is constructed in-place, and the cost of using a nontrivial constructor becomes zero.


Final Thoughts
This is the dilemma I'm faced with regarding variable constructors. I hope to think up a good solution sometime soon, but in the meantime, if you've got any suggestions or votes on how this should work, I'd love to hear from you!

Part of the great fun of building a language is getting the opportunity to face challenges like this and figure out how to solve them. It isn't often that I have to solve a truly novel language design problem (in fairness, I probably have yet to actually stray into unexplored territory as far as language design goes) but when something like this does come up, it can be exhilarating to find a good approach to the issue.

I may or may not get a chance to work on Epoch a bit over the holidays (I'm sort of promising myself to have a working version of my GDC talk ready by the new year) but I will definitely keep you guys posted.


In the meantime, Merry Christmas, Happy New Year, and Good Coding [smile]

0
Sign in to follow this  
Followers 0


0 Comments


There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now