Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Multiplexity: Submarine Hero

  1. #1

    Multiplexity: Submarine Hero

    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.

  2. #2

    Multiplexity: Submarine Hero

    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.

  3. #3

    Multiplexity: Submarine Hero

    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 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...

  4. #4

    Multiplexity: Submarine Hero



    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.

  5. #5

    Multiplexity: Submarine Hero

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

    Any ingame stuff to show yet?
    <a href="http://www.greatgamesexperiment.com/game/Valgard/?utm_source=gge&amp;utm_medium=badge_game"><img border="0" alt="GGE" title="GGE" src="http://static.greatgamesexperiment.com/badge/game/valgard/gge400x56.png"></a>

  6. #6

    Multiplexity: Submarine Hero

    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". 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.

  7. #7

    Multiplexity: Submarine Hero

    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...

  8. #8
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Multiplexity: Submarine Hero

    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.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  9. #9

    Multiplexity: Submarine Hero

    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.

  10. #10
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,107
    Blog Entries
    25

    Multiplexity: Submarine Hero

    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.
    Jason McMillen
    Pascal Game Development
    Co-Founder





Page 1 of 3 123 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •