Multiplexity: Submarine Hero

[rtf]

To quote from my design doc:


"Submarine Hero" (a title which will probably be dropped) is not about rocking out on hoagie sandwiches; it will be a game about deep-sea exploration with some storytelling aspects. The action-adventure part follows obviously, with the perspective being a 2d side-view one and core game mechanics being very shmup-like; the building and management part was not part of my original concept(which was prototyped in the "Game Maker" tool many months prior to this competition, but will now be rewritten with Free Pascal) but is included to satisfy genre requirements - the player will, in between adventures undersea, participate in the development of his home port, gaining access to new equipment and advancing the story.

I already have bits and pieces of an engine put together, including sprites, collisions, and Lua scripting. Today I finalized my graphics format:

Native resolution 400x250x32bit colorx60fps
upscaling to 800x500 with scale2x

That looks like a crazy resolution, but lower res makes it easier to draw for, and it scales to the 16:10 widescreen ratio perfectly. For people like myself who don't have a widescreen, we get to see black bars at 400x300 or 800x600. Performance is pretty good for software rendering; I'm down to around 40% cpu usage for rendering at 800x500 and can probably improve on that.

Something I am not happy with is smoothness of scrolling. This has as much to do with my monitor as with the code. LCDs have blurring when colors change rapidly. When the resolution is low or has a lot of bright solid shapes, these effects become very prominent. So when I double the resolution, I have four times as much obvious blurring. I'm pretty sure I can't do anything to really solve this(though raising the native resolution would help somewhat).

My agenda for the next week is to get my entity system working. The model I have is:

TEntity, the highest-level type, which currently contains:
TCollider (a container type for one of several collision objects)
either a TImage or a TImageGroup, which contain one or more sprites.

I have Lua working with bits and pieces of code to set images and colliders. Some things I still need:

-Image display sorting
-One or more pointers to Lua functions so that the game loop will execute that code each frame

Something I noticed this weekend while testing: SDL seems to have memory leaks. At first I thought it was my code, and then after removing all use of SDL, and then trying demo programs, I thought it was the bindings. Then I went and ran a whole bunch of SDL programs in various languages through Valgrind and found that they all had the same issue; similar leaks with similar characteristics, traced to the SDL libraries. There goes my hope of a leak-free game, but it seems like I'm not the only one.

[rtf]

Music: Tangerine Dream - Midnight in Tula

Today(er, yesterday now that it's past 4 am - I'm a student so I can get away with strange hours) I got a lot done with the entity system and Lua bindings.

First I added some more variables and bindings to set the image and x/y coordinates. The system I've come up is like this: Each entity contains a "image" pointer, and an "imagestyle" which helps resolve the type of image being used(this could include image groups - so along with multiple colliders, one entity can be used to represent many instances!). Further, there is an "imagex" and "imagey" which can be used to direct the placement of the image, independently of the entity's colliders if necessary. With all of these features, the Lua code can control the look of an entity with great precision, without requiring Lua to pass a new set of coordinates every frame - though that's what happens in the case of most sprites. But if I need to really optimize common entities like bullets it can be done without much trouble now. I can comfortably loop 1000 entities this way.

The strangest bug I had was my last one: to draw the entity images I was calling a procedure "drawloop" in my engine. It looped over the global TFPList "allentities" and called a procedure in each one, which resolves the type of image being used and does the actual drawing. Thinking myself clever, when I wrote this function I made it an inline. For some reason(which I'm not entirely clear on), this totally bugged up the loop and made it only draw the LAST entity. To make matters worse I tested with only one entity at first, and then only later found this bug. Once I figured it out, I just moved the loop back into the main procedure since it wasn't all that big anyway.

Right before I finished this post I tried seeing the total performance with scale2x on and found it causing a display bug and a core dump on exit. Hmm.... (tries some things) works fine if I make the scale2x surface 4 times instead of 2 times the resolution. Crazy o.o time for bed.

[rtf]

I took a break most of the last week. I had been grinding away at the engine long before the compo started so I was getting a bit burned out. My scale2x bug turned out to be a silly mistake; I had a "pre-screen" surface that was initialized in a procedure with other graphics init stuff, and it was using the scale2x size, rather than the starting one. So when it came time to perform the scaling the result had to be twice as big as that :roll:

This weekend I started piecing together things for the map editor. Since it's not the core game I have no language requirements whatsoever, but I settled on wxLua (http://wxlua.sourceforge.net/) since any code I used in the editor would translate immediately to the gameplay code, and using Wx would greatly simplify the interface work. It's pretty nice to work with, though I have a learning curve to work up from.

I have this line that is causing a little trouble:
testimage = wx.wxBitmapFromFile("test.png", wx.wxBITMAP_TYPE_ANY)

If I run from the location of my program, "test.png" loads. But if I run from the wxLuaEditor IDE, the path is wrong...and I don't know how to get the right path. But as I say that I get an idea...getting the command line argument data. It's not all that important for usage since I can just run it from a known path, but it'd be more "polished" to figure out the right path always.

I plan to have a working editor by week's end. That's hoping nothing goes hugely wrong...

[rtf]

http://i13.tinypic.com/2lcoil3.png

I didn't try figuring out a "wrong runpath" workaround today. Instead I got the editor interface to a near-final state. And, it does one thing: you can place entities! :twisted:

There's still a lot to do though:

-Add grids (that'll take more interface stuff for sizing/on/off)
-Add Load/Save to menubar
-Change add behavior to follow entity selection
-Add delete, move, change

Or basically all the functionality. The thing that slowed me up today was that I was trying to put the top stuff into a wxPanel. This was the wrong paradigm: there is a wxSizer for both the tools and the view(which I had right), but while the view is a wxPanel, the tools are in a second wxSizer, and then you have separate widgets within that. I had a lot of wrong behavior until I figured that out.

There is a bug I haven't looked at yet: the right side bottom status panel should show your x,y coordinates. In Windows it worked, in Linux not so. (Tests the wxLua scribble demo. Doesn't work in Linux there either) Probably something to do with my having inverted/high-contrast colors.

I have a headache.

[Huehnerschaender]

I like undersea 2D scrolling games... I ever liked them :)

Any ingame stuff to show yet?

[rtf]

No ingame yet, I just have a graphics test which isn't very interesting for screenshots. Gameplay will be next week.

The map editor is now called the "graphics tightener" (http://mediacast.sun.com/share/ChrisM/BeAGameDesigner.mpg). It actually works, unlike the guys in the video. Doesn't have all the features in yet, but it's serviceable for the first stage so I should really get cracking on the gameplay now. It feels like a pain to get started on that... what I should do is take the graphics from my old prototype, that would be a good start.

[rtf]

Still no play screenshots yet. But I can report that the code is progressing and I need to do one more major thing before there is a real "gameplay" going on: collision behavior. Kind of a nasty subject - it's easy to make things STOP if they touch a wall - just set their speeds to zero and push them out if they're inside, but the artful thing is to allow colliding objects to brush against each other or at least bounce.

I'm a bit worried that my collision system won't be flexible enough to get a "perfect" behavior. Flexible performance-wise, that is. It was made to do "test everything against everything each frame" very fast, but I didn't include any "what-if" test for doing behavior resolution. It might be easy to add, I dunno...

[WILL]

Hey rtf, bouncing isn't terribly hard to do depending on the complexity you want to accomplish.

But the easiest way on a 2D engine is to simply reverse the X or Y velocity(speed) depending if the object hit some thing's sides or top/bottom.

You could also try an 8-way collision system where you would reverse the X & Y velocities when it hits a corner, but that would also mean you will need at least 8 collision check points to make that work.

You can also multiply it by something like 1.10 to give it a bit more of a springy effect as well. Such tricks were used in Scorched Earth for the different wall physics.

More detailed then that, as in hitting a round object for instance, may require a bit of trig to do.

[rtf]

You've left out corner cases, and that's where the difficulty is:

-if an object is "squeezed" between two other objects and collides with both, a simple forceout/reverse-direction may cause the squeezed object to get stuck or advance very slowly in the wrong direction.

-expanding on the last one, you're hit on all sides by many objects in a single frame; how do they react? how do you react? In a naive bounce system you'll jitter; depending on how the collision boxes are untangled you may end up with objects teleporting as well.

I may still use simple bounces for my game since the environment is appropriate and I won't have very complex map structure, but it's something I might retune a few times before I'm done.

The last time I seriously worked on collision(two years ago? was in Python) I had a system with sliding, where tests against the map were done along the map's tiles; the moving objects had many test points, allowing collisions to be detected properly even with very large objects. But before I got sliding done well, I had various issues like these:

-Walking alongside walls of tiles sometimes left the player "stuck" (until they moved directly away from the wall)
-Walking into the corner of a wall exactly also left them "stuck"
-The player would get stuck on some walls but not others.

It took several days to get right, so I'm not exactly looking forward to this.

[WILL]

:) You should practice tossing 2 objects from apposing angles hitting a 3rd at around the same time. See what it does and then you'll know in what cases to account for.

The alternative is to get rid of the rectangular collision detection and instead use circular with some simple trig functions to determine angles of force and such. In this you can apply mass which will allow lighter objects to be affected more so than heavier ones.

Then you'd just have to recalculate each object's force and force changes based on who it's collided with and what their speeds and masses are.

This may be alternately easier than trying to build a box with points to determine corners and such.


I have some older math functions for such 'faked' space physics posted about a year or more ago if you care to do a google search on the fourms.

[rtf]

http://i4.tinypic.com/2d769hu.png

Here is a win32 build(with a linux binary also):

http://321f.net/3f_dist.zip

You can move around the map, and if you install wxlua you can edit the map too by running ed.wx.lua! There isn't any shooting or enemy yet, and I don't know if I can get it done by friday - have an exam to study for. Is this enough or will it cost me points if the gameplay isn't "done?"

[Huehnerschaender]

Hi rtf,

I tried it and it seems to run smooth most of the time although there are some situations where the game starts stuttering... Don't know why or when exactly this occurs... it seems to have something to do with the amount of "rocks" drawn.

And of course I can't tell you if this is enough "engine" for stage 2. I am no judge :)

[rtf]

I've made the game a high-priority process in Windows, but I didn't have it in that build. It seems to help the problem you mention. Also, if your cpu is older it will show in this test because I turned on scale2x and that puts a huge load on it - in windows I go from 20% to 90%+ load. (in Linux the max load is much smaller, I think. Hmm. Or maybe I didn't look at that after making the "big" map.)

Scale2x is going to be more like a bonus option for people with high specs, I think. The graphics overall aren't going to change much at this point, but I can optimize collision by doing location-based culling. That will make large/detailed maps a LOT more efficient.

[Huehnerschaender]

Just for your interest my specs:

Intel Pentium 4 HT, 2.8 Ghz
ATI Radeon X800 Pro, 256 MB
1 GB Ram


And I have a laptop I can test it on, too, if you want:

Celeron 1,6 Ghz
512 MB Ram
ATI Radeon Mobility 9000

[Sascha Willems]

Just gave it a short try on my system and so far it runs very smooth. I didn't encounter any stuttering.

[rtf]

Updating because after a long struggle I've revamped my collision system. It can do more things than before and is generally more elegant in most ways. The main thing that made it a struggle was that I decided on using FastGEO, but it needed a lot of work to compile in FPC2. I ended up making "Minigeo" instead of converting the whole thing: taking out only the stuff I knew I wanted, compiling to find dependencies, adding said dependencies, repeat, etc. And then once that was done I found that - also probably because of compiler differences - the behavior was wrong in some instances, which drove me crazy.

...I still haven't gotten to the optimization that led me towards a rewrite in the first place :oops: I think I'll put it off until after the next milestone though....right now I still have to get text implemented, do menus and dialogues....and really get a full gameplay demo together.

Oh and wxLua behaves differently on Win32 than in Linux/GTK. My radiobox doesn't function in Windows(visuals work but no behavior) and I can't figure out why :evil: Something I can look at when the project's over with maybe.

[AthenaOfDelphi]

Something I can look at when the project's over with maybe.
Not if you plan on using radioboxes... I'm only running on Windows :-)

[jdarling]

Oh and wxLua behaves differently on Win32 than in Linux/GTK. My radiobox doesn't function in Windows(visuals work but no behavior) and I can't figure out why :evil: Something I can look at when the project's over with maybe.

Post it to the Lua Mail Group, I think I've seen a solution to that problem go by, but I don't remember when.

I'm curious, since it looks as though you and I are the only two utilizing Lua, what version of Lua and what headers are you utilizing for your project?

[rtf]

Something I can look at when the project's over with maybe.
Not if you plan on using radioboxes... I'm only running on Windows :-)

You won't be the one editing levels though...the gameplay doesn't use wx at all. So it's not important unless you want to judge on how easy the game is to mod :wink: I've looked on the lua archives a little but getting any information on this bug has eluded me. Maybe I will ask about it.

jdarling: I looked at a few options but settled on ThLua (http://assoc.orange.fr/thallium-software/thlua.en.html) because it compiled and worked immediately. Official support only goes up to 5.0...but it's worked and I've had no trouble, so I can do without 5.1.

One issue I've had with using Free Pascal is that a lot of stuff is built first for Delphi and while in some cases the Lazarus tools and libraries might cover up those gaps, I never looked into using it - I wanted to stick with a text editor and command line compiles for this. Simplicity, you know? But a lot of stuff has had to be patched up as a result....so for example, instead of JEDI-SDL I'm using SDL4Freepascal and then integrating files from the JEDI-SDL code when I need them. It's actually been amazingly simple and a much better experience than I've had with most languages/platforms.

When this project is over with I'll try to work out any license issues and get the code in shape for an open-source release...then we'll have a flexible 2d engine designed specifically for FPC.

[savage]

instead of JEDI-SDL I'm using SDL4Freepascal

What differences have you found between JEDI-SDL and SDL4FPC?

[rtf]

SDL4FPC is less bulky. JEDI-SDL has a lot of structure and overhead to support multiple compilers, which made it harder for me - a relative noob to the compiling systems used in Object Pascal - to get it working. But they seem almost interchangable beyond that, even down to naming conventions.

[jdarling]

Hmmm.... Never looked at THLua before, actually, never even heard of it. I rolled my own by basing it off of other Lua wrappers I could find for 5.0 then upgraded that to Lua 5.1. Nice thing is that I now have the best of both worlds across Win, Lin, and Mac. Down side is, that there are now A Lot of compiler flags if you want to switch between 5 and 5.1, and it can't be done at runtime (yet).

Still, I'd love to see a sample project with wx utilized in it. I've yet to play with wx at all myself, that whole no time thing :)

[rtf]

Submitted the milestone. I mirrored it locally, so you can try it if you like:
http://321f.net/3f_milestone3.zip

Still minimal gameplay but I can build on this really fast now. I put together all the effects, mines, death, dialogue and menus in the last four or five days. Also there is a bonus included. 8)

[Huehnerschaender]

Just tried it..

started without problems...

The gameplay seems to be much too fast. I am not able to control the submarine like I would suppose to.

Also the keypresses seem to be processed nearly a second after the key is pressed... and its cached somehow... so I can press a sequence of keys very fast and then lean back, watching the ship doing the steps afterwards... Is this intended?

Greetings,
Dirk

[rtf]

No, that's not intended. :P The speed maybe, you are supposed to move quickly, but unless you could make a video I wouldn't know for sure. But the controls should feel very tight. I already got your hardware, but were you running other programs? Did the old build feel like this at all?

[WILL]

Might I suggest a visible FPS counter? Many developers put one in to see such things.

[rtf]

I put up some alternative engine settings to try:
http://321f.net/alternate_engines.zip
Drop them into the base directory and they should run.

The default engine uses the Windows HIGH_PRIORITY process setting.
The "idle" and "normal" versions change this setting to lower priorities.
The "lowres" version is at half resolution and may be the solution if the problem is actually a performance one and not a scheduling one.

[rtf]

A quick update. I now have inventory items in the game; during the mission mode you can mount them to either the front or the back of your ship, or both(but only one side can be used at a time). All settings - except controls - are fully configurable and there's a main menu. I'll get to controls later!

In addition to the machine guns there is now a "blade" weapon that slices up enemies good,,,if you can get close enough :wink: I will soon add a tractor-beam weapon that should help with using the blade.