Developing production code (with database)

Hi,

I have been using C2 so far for prototyping quiz game ideas. I am now wondering, what does it take to develop production quality C2 code / application in general, and a quiz game that includes a centralized database, in particular?

More specifically, what are the issues that one needs to take care of?

thank you,

Dan

Do you want to track the results of the quiz between users or add additional questions through the database or something else?

How is your knowledge of 1. xml or json, 2. sql and 3. php or asp.net? If you can do all these, then it'll be very easy.

You'll also need a server for the server side script and database hosting.

Thank you Indie.

Although I mentioned database, my concern is also C2. How does production code in C2 look like. What are the issues professionals deal with when creating production code.

In terms of database, i am thinking about linking the game to Wakanda backend, a javascript based NoSQL database -- possibly by creating a plugin for database services. The database would store game behavior data of each user, as well as user profile details.

In terms of database, i am thinking about linking the game to Wakanda backend, a javascript based NoSQL database -- possibly by creating a plugin for database services. The database would store game behavior data of each user, as well as user profile details.

Oh thats good you have a plan already for the back end.

Thank you Indie.

Although I mentioned database, my concern is also C2. How does production code in C2 look like. What are the issues professionals deal with when creating production code.

It'll depend greatly on the coding ability and knowledge of how C2 works for the coder. There are multiple ways to do about everything, so you'll have to gain experience before finding the best approach. C2 won't have any problems handling a quiz type game. But if you are asking about the javascript quality generated by C2; I haven't checked that out yet

Thanks Indie,

Here are some examples of what i am thinking about:

1. Internationalization

My quiz needs to work in more than one language. At this stage I developed a simple but not too efficient solution for that. What do professionals do in cases like this.

2. Dealing with common pre- and post- processing during each game segment.

In the quiz there is code that needs to run before and after every quiz screen, example, to start and end timing the quiz length of time. I am currently using a call back feature and include sheets, and a guideline how to construct a main event sheet (always e,g, include eventsheet pre-post). Are there better ways to do this

3. Global variables

It turned out that I have a lot of global variables. I am not sure this is good practice. Do professionals avoid global variables, if yes are there different techniques for that (i know of static local ones, is this used extensively)?

4. etc.

there could be all kind of additional issues that professional C2 developers know about and deal with in a production environment -- i wonder what those are ... what makes product code different to prototype code ... thats my question

1. Internationalization

My quiz needs to work in more than one language. At this stage I developed a simple but not too efficient solution for that. What do professionals do in cases like this.

The Source engine (which is used for several first-person shooter games) references multi-language strings with special identifiers. Day of Defeat has one that looks like this: #Dod_Join_Team. An external language file is used to replace the identifier with the language specific string. For Construct 2, I think you should use a dictionary object, whose keys are the language identifiers, and the values are the language specific string. Load the dictionary contents from an external file (such as lang-en.json, lang-es.json, lag-de.json, ect). Then, at the start of every layout, retrieve the language string from the dictionary and use it in the text objects.

2. Dealing with common pre- and post- processing during each game segment.

In the quiz there is code that needs to run before and after every quiz screen, example, to start and end timing the quiz length of time. I am currently using a call back feature and include sheets, and a guideline how to construct a main event sheet (always e,g, include eventsheet pre-post). Are there better ways to do this

You should try to have all of your quiz layouts using the same event sheet, with any differences that are needed specified in the layout in some way. Since layouts don't have variables, I create an object specifically for this purpose (I call it 'LevelProperties'). Give it some instance variables, and configure them as you see fit for each layout. Have your events reference these variables to handle the differences.

3. Global variables

It turned out that I have a lot of global variables. I am not sure this is good practice. Do professionals avoid global variables, if yes are there different techniques for that (i know of static local ones, is this used extensively)?

Personally, I try to avoid global variables whenever possible, since they clutter up the combo box for selecting a variable. If you can get away with using a local, do so.

Thanks Indie,

Here are some examples of what i am thinking about:

3. Global variables

It turned out that I have a lot of global variables. I am not sure this is good practice. Do professionals avoid global variables, if yes are there different techniques for that (i know of static local ones, is this used extensively)?

4. etc.

there could be all kind of additional issues that professional C2 developers know about and deal with in a production environment -- i wonder what those are ... what makes product code different to prototype code ... thats my question

3. Its not bad to use global variables. You have to assess each case if using a global variable makes sense and is the best option. Other options include reading from json, xml files for large amounts of static data, Local and Session Webstorage, Local variables, etc.

4. I think you want to skip the step of writing the "prototype code" and go straight to the "production code". Unfortunately you can't skip this step. The link between these is time + experience + testing!

Many thanks for the feedback.

re: "You should try to have all of your quiz layouts using the same event sheet, with any differences that are needed specified in the layout in some way. "

Since the quiz I am constructing has layouts that are significantly different its not possible to have a common event sheet for all. Instead, I turned it around, extracting commonalities to sheets included in all layouts.

re: prototyping

There is a key decision that I have made early on during prototyping, which is to focus on prototyping the game rather than optimizing code, including code reuse, unless absolutely necessary. I rather duplicate code than write parameterized code.

The reason is simple, debugging parameterized code is hard and one spends a lot of time on this, while at the same time, what really counts early on is working out game ideas that work. Also, as I add new game ideas, new flexibility are identified that are needed in parameterized code -- which further complicate matters.

What is your experience when trying out new game ideas?

Since the quiz I am constructing has layouts that are significantly different its not possible to have a common event sheet for all. Instead, I turned it around, extracting commonalities to sheets included in all layouts.

It is very likely that you can, in fact, use the same event sheet for all of your quiz layouts, despite them being "significantly different". The levels in Super Mario World are "significantly different", and yet they all use the same code to run them. "Not possible" is a rather bold claim, one that likely wouldn't stand if you were to post your capx.

I rather duplicate code than write parameterized code.

I strongly disagree. Code duplication is one of the evils of programming.

If you need to fix a bug, or change how it works for any reason, you have to remember to do it in all the places where you copied it. You will inevitably miss a spot or two, and have bugs that you already fixed show up in very specific situations.

"Parameterized" code is also better for readability. What is easier for you? Reading this:

sqrt((Player.X - Enemy.X)^2 + (Player.Y - Enemy.Y)^2)

Or this:

distance(Player.X, Player.Y, Enemy.X, Enemy.Y)

With the distance function, just glancing at it tells you what it does. With the formula code, you have to spend more time on it figuring out what it does.

re: "Not possible"

I agree. With the right parameterization it can be done, but it would involve other tradeoffs, such as larger event sheets and more parameterization -- which makes the code less understandable.

re: duplicate code

I surely understand the "evil" of code duplication. However, during prototyping, code duplication can save significant time and cost -- even if i systematically need to make changes across several event sheets -- and I have to do this rather frequently. These event sheets are btw easy to spot since code duplication is only needed for very similar layouts -- such as when "AB" testing layouts ...

re: "Not possible"

I agree. With the right parameterization it can be done, but it would involve other tradeoffs, such as larger event sheets and more parameterization -- which makes the code less understandable.

re: duplicate code

I surely understand the "evil" of code duplication. However, during prototyping, code duplication can save significant time and cost -- even if i systematically need to make changes across several event sheets -- and I have to do this rather frequently. These event sheets are btw easy to spot since code duplication is only needed for very similar layouts -- such as when "AB" testing layouts ...

Well, at the beginning of this very thread, you asked for advice on production quality code, and that's what I'm giving you. And I beg to differ on parameterization making it less understandable. Consider the example I edited in to my previous post.

Thank you for your parameterization example:

There are indeed different kinds of parameterization. The kind that I am referring to are those that act as preconditions in events, and/or use data structures (such as dictionaries and arrays) to allow flexible processing of contents. In such cases, code typically becomes less understandable, since the code deals with exceptional cases, that have to be treated in a generalized manner, and with acting upon datastructures that store relevant data rather than the data itself (it adds indirection).

To give a simple example,

Suppose you have an language dictionary set up to deal with multiple languages. So your code "knows" (is designed) how to map the current language setting, say "en", and a unique string identifier, #Game1Greeting, to a language string. All works well for languages until you notice that you have to specifically deal with the gender of the player -- in Hebrew, for example. So now you need to think how to add this additional detail into your code and datastructure -- and it doesn't fit as neatly to the mapping before.

Its clearly doable but its unanticipated changes you encounter as you learn more about the structures of the game add key complexities.

"well, at the beginning of this very thread, you asked for advice on production quality code, and that's what I'm giving you. "

Indeed, and your advice is very sound!

thank you,

Dan