• entries
743
1924
• views
580063

# Better

205 views

Feeling a bit better today. Reckon by the time the weekend is over I'll be fine again. Quite a scary week at times though.

Anyway, I've started working on Udo again but I have some bad news for fans of my leaf monsters and rustling bushes - both features have been ceremoniously dumped from the game.

I know people seemed to really like them, but somehow they just weren't fitting in my mind into the overall game. It's a bit abstract, but they just didn't feel right.

I've made some minor improvements to my map editor to make it slightly easier to work with these multi-layer maps.

Haven't posted any map editor screenshots for ages actually...

Lot easier posting pictures here than on GGE. Have to say I really didn't get on well with that site. I haven't been there once since GDNet arose from the flames.

EDIT

Just finished implementing the autosorting of items order thingy, so it now doesn't matter what order you place items in the level editor.

The basic Item interface had a virtual GetZ() method added, which is then implemented in each class type, just returning constants at the moment, although of course individual items could store a personal Z value if needed later.

Then an InsertSorted() method was added to the ItemList class that replaced the Add() method that was being used by the level loader.

Simple as that really. Now you can declare items in any order in the editor and they will be drawn in the correct order during the game.

The only actual change this forced was to convert the door frames from being instances of a CStaticBlock type into their own CDoorFrame class. Even simple static blocks will now need specific classes to describe them so that there can be an implicit Z value for the class. I could have added a Z field to the StaticBlock class and set it in the editor, but it is precisely this kind of low-level fiddling about in the editor that I am currently trying to improve upon.

Next issue to tidy up is the management of all this messy additional data that each level file needs.

The level editor looks great! And I don't see how it would be hard to work with, at least not from that screen shot.

Well, the actual placing of blocks and stuff is quite easy, especially now that the layer placement is handled automatically. A slightly trickier bit is having to make sure you keep the item list in the correct draw order, but that is not too bad.

Biggest problem would be if someone else wanted to create a complete new level containing different graphics or enemies, since that would involve creating some quite awkward files using my slightly esoteric virtual assembler, which I wouldn't wish on anyone else, so I guess I'll need to create the templates for all the different types of world files before I ship the editor to anyone.

Also a bit inconvienient is the fact that each level's imp script (my homemade scripting engine) needs to be written and compiled seperately from the level, which for me involves jumping between the map editor and notepad, and having the imp compiler set up in the right-click context menu for .ic files in my windows explorer.

Really I guess I need to think about bringing the script creation into the map editor itself and embedding the compiled script into the level file rather than have it as a seperate file as it is at the moment.

I must admit I may have got too complex with the structure of the level files for this project though. Too late now to worry about it. Always trying to balance between simplicity and flexibility and my nature is to always sacrifice simplicity for flexibility, and then never take advantage of the flexibility. Daft really.

This is the current simple imp script for the demo level

include "udo.ic";

proc 0
{
}

proc 1
{
int x,y; getpcxy(x,y);

if(x>384)
{
activate(1005);
activate(1006);
}

if(x>1280) activate(1018);

if(x>3264)
{
activate(1033);
activate(1035);
}
}


The included udo.ic file just defines the function getpcxy(int&,int&) in terms of a service call that calls back the main application.

I'm thinking about extending out my scripting language into something a bit more generally useful and releasing it for other people to use if they wanted as it strikes a nice balance between ease of integration into a project and powerful language features.

Couldn't you sort the item list in some sort of smart way? I guess not because then you would already be doing that, what do you mean with keeping them in order, I guess some objects in the level obscure another one if you change the later and etc.?

You mean the making of bitmaps you talked about in my journal? That didn't sound too complicated, but I see the template making can be a hassle, and time consuming witch is the worst :)

Yes I've been thinking a bit on scripting for my level editor, I will be including the script in the map, witch is more secure and more convenient IMHO. But I haven't even started on the scripting part yet, so there may be a lot of changes in my plans.

Well, because this is a generic level creator and not specific to Udo, each level has to have the scheme file I was mentioning before specified, which defines the different blocks and types of item and so on.

However, Udo levels require a load of other binary information prefixed to the start of the file so the map editor has the facility to allow the scheme file to specify a header file that is automatically prepended to the start of the exported level file.

Currently this header file is created by using my virtual assembler script. This is the script for the current demo level:

"Resource/gamefont.spf" 0b
"Resource/sky.spr" 0b

"back.ubm" 0b

"Resource/level.sfx" 0b

11
"Resource/system.spr" 0b
"Resource/blocks.spr" 0b
"Resource/udo.spr" 0b
"Resource/star.spr" 0b
"Resource/platform.spr" 0b
"Resource/wave.spr" 0b
"Resource/particle.spr" 0b
"Resource/sheep.spr" 0b
"Resource/fstar.spr" 0b
"Resource/fish.spr" 0b
"Resource/pickup.spr" 0b

17
"[0,1]<" 0b
"[1,4][2,4][3,4][2,4][1,4][4,4][5,4][4,4]<" 0b
"[3,1]<" 0b
"[6,1]<" 0b

"[7,1]<" 0b
"[8,4][9,4][10,4][9,4][8,4][11,4][12,4][11,4]<" 0b
"[10,1]<" 0b
"[13,1]<" 0b

"[0,4][1,4][2,4][3,4][4,4][5,4][6,4][7,4]<" 0b

"[0,4][1,4][2,4][3,4]" 0b

"[14,4][15,4][16,4][15,4]<" 0b

"[0,6][1,6][0,6][2,6]<" 0b
"[3,6][4,6][3,6][5,6]<" 0b

"[0,6][1,6][0,6][2,6]<" 0b
"[3,6][4,6][3,6][5,6]<" 0b

"[17,6][18,6]<" 0b
"[19,6][20,6]<" 0b

5
3 8 15 15
6 0 15 15
6 1 30 30
6 2 15 15
6 3 21 21

0 // star particle
1 // fire particle
2 // fireball particle
3 // greystar particle
4 // shard particle

12
00 01 00 0 00 0 0   0
01 01 00 0 00 0 0   0
02 01 01 1 00 0 0   0
03 01 02 2 00 0 0   0
05 05 09 0 01 0 0   0
06 01 01 2 00 0 0   0
07 01 03 2 02 0 0   0
08 01 04 0 00 0 0   0
09 01 08 2 08 0 0   0
10 01 09 2 00 0 0   0
11 01 10 0 00 0 0   0
12 01 00 2 00 0 0   0



It basically defines all the graphics, animations, block types, particle types, background, music - everything that can vary from level to level.

The actual scheme file that the map editor loads looks like this:

header "header.dat"

layers 3

defaultlayer 1

width 64
height 64

filter "Udo Files" "*.udo"

autoid 1000

block 1 "Rock" img rock.bmp 0
block 2 "Rock Top" img rocktop.bmp 1
block 3 "Grey Box" img grey.bmp 1
block 5 "Wave" img wave.bmp 2
block 6 "Solid Rock Top" img rocktop.bmp 1
block 12 "Solid Rock" img rock.bmp 1
block 7 "Spikes" img spike.bmp 1
block 8 "Spring base" img springbase.bmp 0
block 9 "Glass" img glass.bmp 1
block 10 "Brick" img brick.bmp 1
block 11 "Bush" img bush.bmp 0

item 01 "Udo" 16 32
Class 01 ID 0 Bank 2 Width 32 Height 32 X 0 Y 0 Dir 1
AnStandL 0 AnRunL 1 AnFallL 2 AnDuckL 3
AnStandR 4 AnRunR 5 AnFallR 6 AnDuckR 7
AnDie 10 AnOut 15 AnIn 16
end
img "udo.bmp"

item 02 "Present" 0 0
Class 3 ID 0 Bank 1 Frame 5 Width 64 Height 64 X 0 Y 0
end
img "present.bmp"

item 03 "Horizontal Platform" 0 0
Class 04 ID 0 Bank 4 Frame 0 Width 64 Height 32 X 0 Y 0
Dir 1 Min -1 Max -1
end
img "plat.bmp"

item 04 "Springboard" 0 32
Class 05 ID 0 Bank 4 Frame 1 Width 64 Height 20 X 0 Y 0
end
img "spring.bmp"

item 05 "Star" 16 16
Class 06 ID 0 Bank 3 Anim 8 Width 32 Height 32 X 0 Y 0
end
img "star.bmp"

item 06 "Sheep" 8 24
Class 07 ID 0 Bank 7 Width 48 Height 40 X 0 Y 0
Dir 0 Speed 2 Turns 1
AnLeft 11 AnRight 12
Active 0
end
img "sheep.bmp"

item 07 "FireStar" 16 16
Class 08 ID 0 Bank 8 Anim 8 Width 32 Height 32 X 0 Y 0
end
img "fstar.bmp"

item 08 "Fish" 12 13
Class 09 ID 0 Bank 9 Width 40 Height 38 X 0 Y 0
TimeTarget 20 Jump 8 Speed 0 Dir 0
AnLeft 13 AnRight 14
Active 1
end
img "fish.bmp"

item 09 "Door" 0 0
Class 10 ID 0 Bank 1 Frame 6 Width 64 Height 64 X 0 Y 0
Open 0
end
img "door.bmp"

item 10 "Door Frame" -9 -10
Class 2 ID 0 Bank 1 Frame 7 Layer 0 Width 82 Height 74 X 0 Y 0
end
img "doorframe.bmp"

item 11 "CheckPoint" 8 8
Class 11 ID 0 Bank 10 Frame 0 Width 48 Height 48 X 0 Y 0
end
img "checkpoint.bmp"


Creating a new kind of level with different graphics or blocks or items would involve creating a new script based on the one above and a new scheme file for the map editor.

As you can see, the script is not very self-descriptive and so I don't really think that it would be fair to expect a modder to be able to modify or create these files, or link them into map schemes manually.

Creating new headers and schemes will largely be based upon modifying the existing ones, but it is not very user friendly. Perhaps I should be writing some companion tools to help this process. I don't know.

The map editor has evolved into a fairly complex piece of software now and I hope it isn't running away with me. [smile]

Regarding "smart" sorting the item list, I have thought about it. It should actually be possible really. The order I guess needs to be stars, then enemies, then Udo. The doors and doorways are special cases. The problem is that the doorways are just general-purpose static blocks, which could vary in terms of where in the layer order they should appear.

I suppose if I made the doorways objects in their own right, the order would just be doorways, doors, pickups, enemies then Udo, and I could implement some kind of ordering based on that. Rather than having general purpose static objects, I could enforce that any type of object had to have its own class, then an ordering strategy could be applied by the game when loading so that it didn't actually matter what order objects are declared in the editor.

That's probably the best solution.

Cheers for the input, walle. Really helps to discuss this stuff with someone.

Yea I can see how it can be fairly complex to use it with additional data :)
And no it isn't very self explaining. But a simple paper that describes what goes were would suffice for most coders I guess.

Regarding the sorting, maybe you could initialize the items with a z-index, used in the layer, like start = 1, enemies = 2 and udo = 3 and then make a function in the item list to change the z-index in case the default ordering isn't working.
Don't know if this is applicative but may give you some idea.

I like discussing this too :)
And I believe discussing this will help me a lot in my own development.

Walle is right: introducing a 'Z preference' for each sprite type would take care of the ordering problem for sure, and is probably the most elegant solution. To make life even easier, you can just use the built-in hardware-accelerated depth buffer. [smile]

As for making your data more easily extensible, I think that somesort of data editor would work just fine. How much of a pain in the arse it'll be to write is arguable, but if you want people to wind up modifying Udo in the future, then opting for user friendliness is definitely the way to go. Plus, keeping the low-level access (ie. text editing the script files) still gives flexibility beyond the simplicity of the editor. Best of both worlds!

Generally, it sounds like you have things in a better position than you may think you do. Zip up those two issues and things should feel a lot cleaner. And I know for a fact that developer motivation is directly proportional to how clean one's game feels. [grin]

Yeah, maybe that's why I've felt a bit flat on Udo recently. Perhaps I need to do a proper cleaning phase instead of developing new bits.

I'm not going to use a z buffer and let the hardware to my depth sorting because I found with some tests last year that that can really cripple the framerate and also increases the minimum specs for the game.

I think I am going to come up with a system whereby the game does an insertion sort of the items as it loads them from the level file though, so that you can declare them in any order in the map editor.

Actually, that should be quite easy really, thinking about it.

Quote:
 Original post by EasilyConfused... I think I am going to come up with a system whereby the game does an insertion sort of the items as it loads them from the level file though, so that you can declare them in any order in the map editor. Actually, that should be quite easy really, thinking about it.

Yea, that was what I meant with using a z-index in the layer level editor. Probably should have used "z-index" because I didn't mean a real one. :)

## Create an account

Register a new account