Thesis work log

This is most likely the last post to this log, and thus will be displayed at the top for a long time. So I'll start with just saying what this is:

This is the work log of a thesis focused on devising a scripting language for games. The language became named SM. For a summary on it, see its web page. As for this log, it's descending order, so the first post is last and if you want to read them in order, go to the end of page 5 (though it doesn't really get interesting until page 4).

What brings around the post of this entry is that I've finally updated the web page with the final report and abstract. Also available are the implementation and the test game.

If I get around to improving/working on SM more, I'll probably add a new log or feed for that, and link it from the web page.

There's now a web page up for SM, giving access to the report, slides, this log, and in a few days also the implementation source and the test game.

I have now held the presentation, and it seemed to go well enough. If you want, you can get the slides.

Huzzah! Ticked in on 79 pages including everything, or 58 just including 'real' pages.

It has been quite a job these last days -- since Monday evening, close to zero of my time at home has been spent on entertainment. No TV-series watched, no games played, and hardly even reading a single article that turned up on programming.reddit. I also reduced my amount of open chat rooms by half (from 2 to 1).

Now I can say something like: While I can't really recommend working close to 12 hours a day on writing (brain feels pretty weird towards the later part), it can get things done, which is good. Not that I've worked that much in more than one day in a row -- I attended CHARM during Wednesday, and also went to see a movie, which was probably good.

OK, I had not really intended to write a rambly post here. I just meant to write what the post title says. Huzzah! again.

I had really expected the report to be done Tuesday 12th, yet it wasn't entirely. Now a day after, almost all writing is completed. What's left to write is one or two expected paragraphs on the background, the conclusion and abstract, and some on the work process appendix.

Except from that, proofreading is needed. There's literally parts that I haven't had time to read through even once yet. The sources need to be formatted correctly, too.

I expect this to be completed the evening of Thursday 14th.

Then, maybe an acknowledge page would be good.

Yet another week with nothing interesting to write about here, so nothing as been written. Last part of the week has been very productive, though the earlier part varied. The report in its current form is 49 physical pages (including appendix, empty chapters etc). It's far from ready, though.

A comment on the fact that week 19 is ending. That would make it just one week left really. As it is, there's five unworked days in the backlog, or whatever it should be called, so there's really two weeks left. Which in a way is really, really good, because it means timing will work out better. But still, in the end, I'll just have to write on the report until it's done. Even if it takes a week longer. I've stopped all other work though, since two weeks back or so. So no work on implementation or example games will happen.

Yeah, this is mostly fluff, so I'll stop now.

It hasn't been such an interesting week. At least nothing very interesting to write about. I'm just (or should, it varies some among days and hours) writing on the report.

Day 1 I had a meeting with Aarne and Staffan, talking about the report.

Day 2 I managed to begin writing.

Day 3 was spent mostly on going on thesis presentations by other folks. I got my three signatures now.

Day 4 and 5 has varied in usefulness, but mostly it's been going slow.

Today has been extremely unproductive. I figured I'd take a shot at continuing what I started last night, actually starting on the report. This proved a bit hard, though. First I figured I could make a start at the language manual instead, and a thought a bit about that, set up a .tex and so, but then when I started with the introduction, it just felt like it were the report light and I would just have to rewrite whatever I wrote again in the report but better, so then I figured it'd be better to go for the report. Then I skimmed through this log. Did you know it contains 200 KiB of text data?

I've come to realize that the log, as it is, has been both good an bad. It's been good because I've been able to write down what I've been thinking and doing. It's been bad because I might have used it a little bit too much. Now, don't misunderstand me, what I mean is I wrote everything here, instead of writing less here and writing directly in the report from the beginning. I guess that's good and bad, too. In the log I've been writing in a very relaxed way. Very talky, and lots of I, and so on. It has made writing here easier, so I've written things I probably wouldn't have written in the report. Which is good. But it also means that a) I didn't write it in the report, and b) it makes the already written text harder to incorporate in the report.

After the reflections on the log, I tried to really start on the report. But it didn't go so well. It's really hard to just start. I've had a bad time getting started on things earlier, but this is worse. I've been thinking a little about it, and I'm figuring this report is actually the first thing I'll write that actually matters. It will be serious and people will (well, may--anyone will be able to) read it. It's supposed to show that I deserve the degree it will give me. And so on.

In the end, I've done little of value today. At least if brooding doesn't count. And I'll quit early too, because this isn't going somewhere tonight, and I've had the honor to get this fine headache as a reward for my hard work. Right.

Today I begun with continuing with what I did yesterday. I added highlights to the water. I added layers to the particle system and sprite components, added some more features to the particle system, added so the base positional component can have a base (thus move if base moves, etc.) (although it's kind of hacky). All this made it possible to add particle effects representing waves for the towers and nerflings.

While the water stuff still has no importance for the real thing here (it's just fun and pretty), I feel the component stuff actually do, as any game would have those components, and actually using such in the game shows how well (or how badly) the general model works. Seems it works pretty well so far, although the 'has'/property approach keeps coming up still when I think about some things.

Also, to further validate the time I've spent on prettifying Nerlfing Rush, some of the time was outside work hours, in my spare time. Oh, and yes, it was fun, too. Current appearance.

After getting those things done, I thought about what I could do then and how fun those thing would be. This is what I got: 'I can write on report (Very boring), write on language manual (Pretty boring), add some of much needed feature to implementation (Boringness varies greatly), add better UI (side panel) to game (a bit boring). Note that there seems to be correlation between boringness and importance.'

After some time I decided I might as well get on with it and start with the report, it being the most important thing left and all. I never really got as far as to begin on it, though, but the rest of the time I spent seeing what writings I previously had done (not counting log), getting tips/help and suggestions from Mr Friend (who is also Mr Opponent), and reading tips and guidelines on it. And also reading what little notes I had on it before from supervisors.

Started out with fixing bug from yesterday. Then also fixed some other bug I found, although I don't recall which one that was.

Then I continued gamifying Nerfling Rush. You can now build towers a bit organized and they cost gold, and so on.

Then I got stuck on prettifying it. While it feels largely irrelevant for the actual purpose, it just gives a much better impression when it looks pretty. I can't draw very well, but well enough. Also spent some time moving over some water animation code from another project. It looked like this when I stopped for today.

Read The Hundred-Year Language and some notes on it by Tim Sweeney. They're both from 2003, but they turned up on reddit. A bit interesting, though not much to say about at now. Maybe would have been a little bit earlier.

Today I continued work on Nerfling Rush, started actually making a game of it, or so it felt. While doing that I also went to implement explicit casts. Like cast(int)mrFloat. It's primary use is really for dynamic casting of objects, like cast(SomeClass)someObject which gives null if the cast failed, or else an object typed as that class. The only other explicit casts I so far support are


and also cast to the same type as value already are, only it doesn't really make much sense to use that one. I don't really want much casting of primitives, but as I haven't added implicit casting from int to float or hadn't added rounding functions for other way around, there was a need for it. Now I have added rounding functions, though, but it was just because they were easy to add when I had casting (well, to clarify: I had floor and ceil, but both those gave floats, as in the C lib).

I also found a bug I'll have to fix tomorrow. When using default block on a child class to initiate a variable defined in a parent class, it fails type checking if you inherit from that class. I know what's wrong and so, I just didn't have time to fix it today.

Also, in an attempt to get some work done, I'm now trying out to work during the night instead. It has worked well so far (tries: 1, success: 1). The reasons are that there's less disturbances from neighbours and outside (I'm currently working at home, not at Chalmers, where the same would probably be true anyway), I'm generally more creative/productive during the night, the last few days I haven't been able to fall asleep very well, and finally I haven't got much work done lately (of the 6 work days I had been back, I had only got work done on 2). So I thought it was worth a try. We'll see how it works out.

First of all, this entry is really for Friday. Just took me a while to write it. Or to begin write it.

I did an UI component binding, so I can get mouse input, and (when it's ready) do buttons and so.

I also spent a little time setting up a fairly OK syntax highlighting for SM for Code::Blocks.

It was largely an unproductive day.

I really should have worked the last three days, but sloth got the better of me, unfortunately.

Anyway, today I started with adding so you can do .x, .y etc lookup on float2 etc. For some reason I forgot that earlier. You can't use the as lvalues though. That'd be trickier. Better to think of small vectors as inseparable values that are immutable for now.

Having done that, I fixed so the towers in Nerfling Rush targeted nerflings within a certain radius only. They're still looking through all and checking distance, so it's not extremely optimal, but it's OK so far.

Then I added a particle system class with bindings, which is good to have for visual effects. So now you can actually see that towers attack nerflings.

Then I rewrote some code slightly. Very slightly. Making it more good looking. Got me stuck in some debugging though, which was a waste.

Made a change to the interpreter, too, so that a statement catches run time exceptions and logs them. Meaning, if a run time exception occurs, it only aborts the current statement. Then it continues with the next one. This means that with some luck the rest of the code can continue to run without problems. But I'm not fully sure about this yet. While it seems the least painful way of doing things, the following statements could do unexpected stuff if the programmer assumed the statement would run correctly and do something. In addition, it messed up assert a little. assert was viewed as a run time exception, but with this change, it just logs something, then continues anyway, which is clearly not the intended behaviour.

I've also been thinking a little bit about when you only need one instance of a class. Like a singleton. I don't remember how much I've covered about it before, but the situation that turned up was that I felt that the towers could share the particle system. This is not really necessary, but I'm sure there's more valid cases. What I had to write for this was:


Which seems very verbose. My first idea was instead a new? operator, that would only create a new instance if it didn't find any, and if it did find some, just return the first. This seems slightly weird though. When talking to Mr Friend he suggested that adding a 'single' keyword to the class definition might be better. It's certainly more organized. To be fair, I'll probably won't implement either of these, but I like the ideas written down.

It's now extremely possible to destroy objects. This is done via the native destroy function in Object. This is quite handy when you feel like destroying objects. It also calls the destroyed event.

A few bugs have been removed. For example, there was a bug where the wrong function was called: instead of the most derived class' function it called the function of the class the calling function was in. If that makes sense. Also was a case where current object (or this) got bad on second call or so. These bugs are now very much fixed.

A break statement now exists. It works exactly like you'd imagine: it breaks out of loops. This is very entertaining. Unfortunately, there's no support for breaking out of nested loops yet, but then, this isn't quite as common even though it's twice as entertaining.

The most interesting result of todays work is I've now added a kind of foreach statement. I don't think I've discussed anything about foreach yet, but I want to have two kinds of functionality from it: iterating over arrays (or list or whatever) and iterating over existing objects. The first kind is the most common one, and also the kind of which I still lack functionality (very much because of the actual lack of array support). The second kind is what I've added today.

It works like this:


This will iterate over every object existing that is of class Nerfling. So you can iterate over all objects by using the class Object instead of Nerfling.

A few comments: I want to add a way so native code can select special objects to iterate. So, for example, you could iterate every Positional object within a radius of 20. This is very useful. This is something UnrealScript allows, although with a slightly different syntax. I'm not sure when this will turn up, though. When I really need it for the example games, probably.

But that's not all. As it's not possible to actually destroy objects, I had to make sure invalid references compared to null gave true. Which it didn't. But does now. This was already planned/designed, I just hadn't implemented it.

Work has continued much as yesterday.

I've improved the glue code by adding support functions to call script functions from C. These are called events, and in the script uses the 'event' modifiers. I've probably mentioned these before.

I've also added a timer component and a moving component to the 'game engine'. Meaning, now you can actually do something that's remotely interesting.

I've also fixed a few bugs; in particular, I found a rather annoying bug that I spent way too much trying to solve, only to find it wasn't as obscure as it seemed. Such things are always very heartwarming.

What I had at the end of day was 20 red dots (Nerflings) moving slowly down the screen, past (over) a green rectangle thing (a Tower) in the middle. It's not very interesting. But it's something.

Happenings of today: Have continued to work on Nerfling Rush, but mostly it has just forced me to work on the other stuff. Kind of like last day. Improved the glue/bindings code, and the C API. Found a few bugs. Fixed a few bugs (on less than number found, though). Added a 'created' function that is called on server (or owner, I guess) when object has been created. Hm.. a bit more stuff, probably. I should write while I work, but didn't work out that way today.

Started on the Nerfling Rush example game. So far I've just set the project up, written some on the basic components (of which some was written already, some month(s) back), written a sprite 'engine' and some more. Also had to write some more on the SM API, and improve the glue code writer. All in all, nothing exciting yet.

I now has the three types float2, float3 and float4. All normal operators work on them, even ++ and -- (it's weird, but it was easier than prohibiting it), but using scalar types together with them doesn't work, so you can not yet do float2(2.4, 3.2) * 3.4. Supporting scalars would take some more work. Otherwise operators act element-wise. And no, ordering compares are not allowed. All in all, the implementation is not the best but I'll do for now.

So I can probably start on example game for real now. But ...

Now, this being the last work day before Christmas, I'm going to cheat a bit and quit early. While I've done this sometimes before, today it feels I have a really good excuse which is extra nice. Yay. So I'll be taking a break now. For around 2 weeks. But I might work some on the game examples for fun, and maybe work a few days to make up for the 5 I've missed. We'll see.

Happy Julmas.

Using the process of elimination it turns out today is set for the vec2 (or float2) problem. I touched upon this subject a little in Week 4, Day 4, but I never decided anything. What I need is a small vector type, but it could be given either by tuple support, special small vector support, or custom types/struct/records support. Or a combination of either. Or I could just add float2, float3, and float4 as built in non-general types, which would probably be easiest for now, though probably not in the long run. It wouldn't be as interesting as the other options either, but, well, you can't always do interesting stuff. And I can probably generalize it later. So I'm taking that easy road for now.

(OK, started doing Mr menial work, only to trail off a bit... when looking at the grammar for floatN construction, I kind of started thinking about list and tuples and spent a lot of time playing around with grammar for a minimal language much based on that.. only I seemed to keep ending up with lisp or lambda calculus. Fun waste of time though.)

Things got rather messy already when I was adding the floatN type/values to the implementation code. Previous use of templates and some other stuff created large havoc before I got it working, only it's still messy, which is very unfortunate. I don't think I have time to clean it up, either. Took too long as it were, didn't even get time to write the typechecking.

To start with today I've been working on what getting the setter/getters working, which they do now. Before I got to now I changed some stuff though. Primary change is I added a $ symbol to the start of the special function names (for the ctor, dtor, setter and getter) so that the user can't get conflicts with them in the script code, the user can not manually call them, and ... there was something more, only I seem to have forgotten it already.

So everything is fine? Well, there's a slight problem left: the $ symbol is not included in the C function names (of course, since it wouldn't be a valid C identifier), meaning if anyone added a native function set_var and also had a native variable var, it'd get errors when trying to use/build the glue code. This is already a problem with some other weird naming, and I don't feel it worth the effort to find a failsafe way to prevent.

Anyway, things do seem to work. I get ctor, setter and getter calls. The setters and getters should also work together with the replication code, although I have not had the opportunity to test it yet.

What currently happens when an object is created is this (in regards to native stuff):
1. Creation
2. Call native ctor
3. Call setters with default values

The reason setters are called after ctor is that before ctor is called the native code doesn't really know about the object. It's a bit weird though, as it's not possible to make use of default values in the ctor, and it can't really call script functions as that doesn't make much sense yet. But ctor is supposed to be a low level native function that sets up custom memory and such, and not much more. A bit more bothersome maybe (I haven't thought it completely through yet) is that the setters can't make use of default values of other variables either.

There's really more time available today, but I got pretty tired suddenly, so calls it a day anyway.