Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 04:55:15 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsRobGetOut - 3D environmental puzzle platformer
Pages: [1] 2 3
Print
Author Topic: RobGetOut - 3D environmental puzzle platformer  (Read 8950 times)
Bad Sector
Level 3
***


View Profile WWW
« on: May 20, 2012, 02:44:16 PM »


About
    RobGetOut began a few weeks ago when i found a job ad for XNA and C# game developers. I didn't knew XNA (or much about C#) at the time, but i called them anyway and decided to meet a week later. In the meanwhile i decided to learn XNA and started developing RGO. When i finally went to the people who placed the ad, the game looked like that. Most of the content was reused from previous works of mine (all textures are examples for my 3D world editor and some sounds are from my She Loves You LD game, for example).

    The job didn't work out due to a miscommunication between the company and the site where i found the ad (the ad didn't mention an important piece of information: they wanted freelancers who would work at their site for revenue share instead of employers). And finding other jobs is a bit difficult here in Greece, especially with my skill set. So i decided to try yet again the solo game dev route.

    Since i already had RGO started, i decided to continue working on that. Even though it started as a learning game, i really like how the game progressed and especially how the robot navigated around the map. While the initial demo wasn't really much of a game, i decided to make it something i call "environmental puzzle platformer" (a term i came up just a few minutes ago :-P). Basically your progression in the game depends on solving simple puzzles whose elements are found in the game's environment. I'm talking about switches, triggers, pushing things around, etc. I'm not sure if there is a term for that, to be honest, since all the games i can think that might be similar are usually called "adventure" or "action adventure". But RGO isn't an adventure game and doesn't have much action elements (there will be enemies, but you won't fight them directly). A game that is probably somewhat close to what i'm thinking (although it has been a while since i played it) is Abe's Exodus.

Backstory
    While i do like my story-driven games, i'm not a believer that all games should have a story. I prefer more to a thematic background where the game stands on (and progresses through) than a full blown story-driven experience.

    In the game's world, a scientist had dedicated his life on building life-like artificial intelligence. His whole life was in his laboratory building and researching. While researching, he made several inventions to assist him in his goal. Outside of his inventions, he struggled in life - he wasn't born in a rich family or had any patrons or sponsors. His research would be interesting to the government or big corporations, but he was afraid of the implications of machines that were as intelligent as humans and controlled by them. He didn't want to see his intelligent machines be used as weapons. So he kept his major research secret and used his other smaller "side" inventions as a means for income by selling them to interested companies.

    People do not live forever, however, and the scientist died without fully completing his project. Before his death, the scientist had managed to amass a large amount of debt. His nephew was the only close relative and to pay off his uncle's debt he sold all of his inventions - including his incomplete work on "intelligent AI". The buyer was one of the largest electronics companies -one of the best former clients of the scientist- specializing in robotics and other smart machines for consumer and military use.

    The company quickly noticed how advanced the work was and how little they had seen over the years. They assigned a small team on deciphering the notes and reverse engineering the work of the passed scientist. At that point, they still hadn't realized what they were in front of.

    You begin the game as Rob, one of the scientist's prototypes. Your memory is fuzzy and yet you have full conscience of your surroundings. You even feel better than ever, even if that made sense for the first time. Looking around you see unknown machines of unknown purposes, some working but most not. A voice in your head says "You must leave this place immediately".

Status
    From a gameplay perspective, at the moment there is little development over the original demo. I spent most of the time creating original textures and a new map to try them (and other game elements). I posted about them in a previous post in Feedback. The game at that point looked like this. Initially i went for this sketchy and 90s look blend, which was relatively easy to do. Unfortunately it was also a bit amateur and bad looking, so i decided to go for a more realistic approach that you can see in the shots above (this Minus folder contains highres versions - the images are sorted from older to newer).

    Realism isn't what i'm striving for, however. In a range between cartoony and realistic, i go towards realism but more about stylistic. I want colored and tech-like looking environments. Color-wise, i have Bioshock in my mind (which was quite colorful). Obviously i can't do AAA-style graphics nor match the level of detail that a game such as Bioshock has - it just serves as "lighthouse" i'm going for when it comes to how unrealistic i can be.

    And besides, there has to be a point when i have to say "no" to putting more stuff on screen because the game won't be finished. This becomes even more important currently since i need the game to leave the pre-alpha stage ASAP so i can put it for alpha funding (hopefully in places like Desura and Indievania, but i haven't explored the options so far). My money reserves are depleted and there isn't anything in sight - if i wasn't living with my sister at my mother's house, i would be homeless right now. So, yeah. I need to put hard stops in the amount of time i spent brushing those textures and pushing those polygons around :-P.

    I have just finished replacing all the environment textures from the previous sketchy style to the new "more realistic" one (i need to find another name for that, everytime i mention "realistic" people assume i want to match Gears of War's textures...). I like the look of the textures so far, but i need to work more on the environments.

    I also need to work a bit on the editor. The features i need to add ASAP are calculating vertex lighting for meshes and placing areas (axis aligned boxes) for visibility, triggers, etc. Also i need to add support for placing decals on surfaces so i can break the repetitiveness.

    Finally, as far as the C#/XNA engine goes, i need to use these areas from the editor to split the world inside those because currently the engine renders everything and does collision checks against everything. This, combined with my old computer (Athlon64 X2 4200+, 1.5GB RAM, ATI X1950 Pro), means that i can't place as much geometry as i want on the levels.

    After the alpha is started, i'll also resume work on the C version (the engine already works, but it doesn't load yet the .rtw files the editor produces) because i want versions for Linux and Mac OS X (and maybe iOS and Android eventually... and who knows what this newfangled Metro for Windows 8 will come out to be). Since i'll use my LIL scripting language (which has C#/.NET bindings) for the game stuff, i don't expect the porting to be too lengthy.

    At this point i still need lots of feedback. It is better to have it earlier than later - especially when the "later" feedback means ignoring the game because it sucks :-P.

You can find a download of the game so far here:
http://runtimelegend.com/games/robgetout/download.html
(if you have the previous version mentioned at the top of my previous post, you'll need to uninstall it first)

Music
    I'd like to cooperate with someone to provide music for the game. Currently the game has some placeholder music i found in Jamendo which i used for the original XNA demo. It doesn't really fit the current game (which i think it requires more slow paced and "background" music). I haven't removed it because, well, inertia :-P.

    However this will need to be done after alphafunding (which, btw, will not include the current placeholder and i'll remove it in a next upload) because, as i mentioned above, currently i have $0 :-P.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #1 on: May 21, 2012, 02:24:42 PM »

Here is a sketch for some of the kind of puzzles i might put in the game:


In this puzzle you need to activate the platform D by putting the battery B in the control panel C. The battery is located up the platform at the left side of the image. You need to put the pushable blocks A in the open area between the two ramps to form a walkable area.

This example is a simple kind of puzzle, but i'm using it to show one kind of puzzles one might need to solve in the game. A real puzzle, however wouldn't have the elements so near to each other (i used a small area for illustration purposes). The battery for example might be in another room and even inside some other machine which might be activated and hostile to you, so you'll need to solve another puzzle there to obtain the battery for this one. Also the control panel may miss a switch or other element that you'll need to explore the map to find.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #2 on: May 24, 2012, 01:49:47 AM »

I decided to work a bit on the C engine and write Mac OS X and iOS backend code. So far i can render stuff using the Mac OS X code and get a nice green screen in iOS (not shown):



Next step is to write the code for OpenGL ES 2.0 based rendering.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #3 on: May 24, 2012, 10:11:50 AM »

And here is the OpenGL ES 2.0-based renderer, running directly in my iPod Touch:

Logged

~bs~
jackf
Level 0
**



View Profile
« Reply #4 on: May 24, 2012, 05:57:09 PM »

I really dig the song, but perhaps something a bit slower would be suited to such a puzzle game?

The camera moves a bit fast

I can't jump, but it looks like there's cool stuff I could get were I able
Logged
Bad Sector
Level 3
***


View Profile WWW
« Reply #5 on: May 24, 2012, 10:37:53 PM »

Yeah i like the song too, but as you said it doesn't fit. Also it is just a placeholder that i'll remove from the next build. It was there in the original demo i used to learn XNA that i mentioned in my first post and as the game progresses it feels more and more out of place.

Currently turning has an instant speedup. I'll change it to start turning slowly and speed up while you keep the keys down. With a digital control that is all you can get, but i'll also add mouse controls later (in fact the game will be fully playable just with the mouse).

Jumping won't be added as a core action, but i may add a jetpack module for reaching high places.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #6 on: May 30, 2012, 06:21:57 PM »

After spending almost the whole week trying to calculate a PVS from the arbitrary geometry that a Runtime World level can contain (despite the looks, it doesn't have the benefit of a solid BSP that Quake, Source and similar engines do), with varying levels of success and partial fail, at the end i chickened out (the first method worked but was abysmally slow) and decided to simply have the level designer place axis-aligned sectors (boxes) with the editor calculating portals between them immediately. In hindsight this is what i should have done from the beginning since it provides instant feedback (and doesn't have lengthy precalculation times that a PVS would need).



In the shot above the pink boxes are the sectors and the red thick holes as the portals. The editor saves the portals and their destination for each sector.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #7 on: August 07, 2012, 03:11:58 PM »

It has been a while since my last post. I worked mostly on the editor (i also

to test the portals) and a couple of weeks ago (plus some days) i moved to Warsaw (Poland) so there was a transition process too (i'm still in that, but now i can code somewhat at least :-P).

Anyway, i finally got .rtw files from the editor to load in the C engine. Here is a first render:



It doesn't contain entities yet (the engine supports the concept of entities, as shown in previous screenshots, but they're not loaded from the .rtw file at the moment and there aren't scripts for defining the entities that the C#/XNA version uses).

The yellowish lines are the sector boundaries (sectors are used for culling away stuff you don't see and they're connected via portals saved by the editor). The engine doesn't use portals yet (this will be the next step), although the geometry is assigned to sectors and the engine does perform frustum culling to the sectors (so stuff away from the camera isn't rendered, but stuff inside the camera's FOV is rendered even if obscured by something else).

Currently the desktop OpenGL render code uses the plain old fixed function pipeline (it is simpler to debug stuff with it) in a somewhat messy way. Later i will clean it up and add a shader-based render path.

Additionally i've added some new stuff to the editor, like indirect lighting with optional color bleeding, light shadows, inner radiuses and multipliers and even (mostly accidentally) negative lights. I want to experiment a bit with those to see how they can be used (although indirect lighting is somewhat PAINFULLY SLOW at the moment so i might either try to optimize it, or avoid it :-P).
Logged

~bs~
lava89
Level 0
**



View Profile
« Reply #8 on: August 08, 2012, 07:25:05 AM »

This game looks great! I love the art style, as well as puzzle games and robot games, so its a great combination.

But! I can't connect to your site and download the game. Would love to see an updated link!
Logged

Bad Sector
Level 3
***


View Profile WWW
« Reply #9 on: August 08, 2012, 10:04:41 AM »

Could you try again? (click on the big letters at the top)

It might have been some high traffic or something (i'm on shared hosting) because it works fine from here right now.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #10 on: August 08, 2012, 02:44:10 PM »

Now the renderer uses portals:



Up next: polishing the WGF (world geometry fragments - the world is separated in meshes called WGFs which are shared between sectors for rendering and collision) rendering and bringing back entity rendering (i just need to make sure they're assigned to proper sectors).

I've also fixed a bug with Runtime World's exported portals. Some portals were missing (i had to do extra checks for this in the Java walker demo, but that was a workaround which i didn't want to replicate in the C engine) when "saving with extras". Now the portals are explicitly recalculated when the "Save with extras" option is used to make sure all of them are being found and saved.
Logged

~bs~
lava89
Level 0
**



View Profile
« Reply #11 on: August 08, 2012, 08:19:42 PM »

I tried it again. It seems like that all of your links related to runtimelegend keep timing out for me.
Logged

Bad Sector
Level 3
***


View Profile WWW
« Reply #12 on: August 08, 2012, 10:38:51 PM »

That is very weird, from here (Poland) the access is instant and it was also when i was in Greece. AFAIK the servers are located somewhere in Europe so if you are from US and there is a very high traffic it might happen. But then again, i do not have such traffic myself and even if i had, it shouldn't timeout (just take longer). Maybe some proxy settings, browser addon or some Internet connection problem?

My webhosting plan ends in a couple of months so i might change provider...

In any case, here is an alternative link for the game download (XNA version) :-)
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #13 on: August 11, 2012, 05:22:52 PM »



Finally wrote the code to load user entities from the world files (i still need to write the code that assigns custom properties to them - they're loaded but not accessible yet). Additionally i optimized the rendering a bit (it still is somewhat primitive, but at least now it doesn't render stuff twice and uses display lists for the static geometry parts which are supposed to be very fast, at least on nvidia hardware :-P).

Entity creation is done in a very simple and flexible way: first the entity is allocated on the engine side (placed in the world, added on relevant lists, etc) and then it is "constructed" by calling the script function call-entity-constructor with the entity's handle.

This script function checks if there is another script function named entitytype:constructor (where entitytype is the name used in Runtime World when defining the user entity, f.e. for Key the function name would be Key:constructor) and if so it calls it to construct the entity (basically set up the model, animation, events/callbacks, etc).

If the function doesn't exist it tries to simply set a static model on the entity named entitytype.rtm ("rtm" is the engine's custom model format). This is needed to avoid having to specify dummy constructors for each and every single mesh in the game.

Of course if both fail, the entity is still created since it can be accessed by scripts (f.e. a Dummy entity has no model nor need one, but it is used by the Pad entity to specify the path that it will follow by linking together one or more Dummy entities in the editor).

Currently scripts can set the model, position, rotation and animation frames for an entity and they can obtain the type, name (as set in Runtime Editor's "name" field at the sidebar), links, model, position and animation frames.

More stuff will be added later (like, for example, setting an alternative texture for the model, setting up effects, shadows, lighting, collisions, etc) but having them being *there* was an important step that it took a bit too long to make :-P
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #14 on: August 12, 2012, 03:01:21 PM »

Added some basic lighting and shadows to the entities:



The shadows are currently simple blobs. I'll add Source-style "projected to the floor" shadows at some point later.

Lighting comes from the lightmap color at the "feet" of the entity. The color is smoothed out over time as the entity moves to avoid sharp changes in colors when the entity goes in/out of shadows. Currently the color is applied uniformly, but later i'll add some orientation.

Most of the time making the above lighting stuff was spent adding raycasting in the engine and sampling the textures. Or more precisely, fixing bugs :-P
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #15 on: August 15, 2012, 10:48:40 PM »

Added some initial collision detection and motion code. Now you can control the robot a bit (although the controls are mostly hacked in - you control it with the left and right mouse buttons and the camera outside of the world all the time :-P - in order to test the motion):



It needs a bit more work but it is a start.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #16 on: August 18, 2012, 05:25:07 PM »

Here is a quick (and crappy, thanks to youtube) video i uploaded of me controlling the robot around:





Currently the camera is locked to a fixed position. This won't be the final setting, i just use it for debugging. In the video i just implemented some form of basic physics and was running around throwing stuff. Sadly most of them are not visible because of YouTube's awful compression :-/.
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #17 on: August 19, 2012, 01:00:09 PM »

Here is a new video:





I added different camera configurations and the ability to switch between them (just for testing for now, but it'll be possible for scripts to do that). Also this is a much better (even if still low quality) video. I gave in and bought FRAPS to record videos which is much smoother than using CamStudio :-P
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #18 on: August 20, 2012, 02:16:25 PM »



I uploaded a new alpha version:

http://www.runtimelegend.com/games/robgetout/

This is the first C alpha that has a fully controllable robot. The keys are:

W/Up, S/Down => Move forward/backward
A, D => Strafe left, right
Left, Right => Turn left, right (no mouselook yet)
Space => Toggle between first person and third person perspective

Also i made (almost) everything to be script driven now. There is no "special" player entity or special handling for it: when the world is loaded and the scripts get word of a "Player" entity, they set the camera to chase it and register functions for moving it around. Another script binds the keys above to these functions.

Although the code will look somewhat alien, here is the script that defines the Player entity (the "Player:constructor" function is called by another script when the world file is loaded - the Player part is defined in the .rtw file and set via a Runtime World script). The "foreach" part at the middle is what defines a bunch of functions which are called by the input configuration script (this should look more familiar :-P). The scripts directory has some other scripts, like the defines.lil script which contains some of the core parts (the functions that the engine call, like key and call-entity-constructor are defined there).
Logged

~bs~
Bad Sector
Level 3
***


View Profile WWW
« Reply #19 on: August 21, 2012, 02:38:28 PM »

Here is a new video:





It shows the robot moving around (and changing perspective). Also it shows the wrenches disappearing when the robot collides with them. They are defined by these two scripts:

Code:
#
# Common code for pickup item entities
#

func pickup-construct {ent type} {
    entity-cspheres $ent {{0 0 16}}
    entity-handler $ent entity-collision {
        entity-call $this $source pickup
        entity-remove $this
    }
}

and

Code:
#
# Key entity
#

func Key:constructor {ent type} {
    pickup-construct $ent $type
    entity-model $ent [get-model key.rtm]
}

The first script is what does the majority of the job (which isn't much, just removes the entity from the world) in this part:

Code:
entity-handler $ent entity-collision {
    entity-call $this $source pickup
    entity-remove $this
}

The entity-handler function registers handling code for the entity-collision event in the ent entity. When the entity receives the entity-collision event the code inside the brackets is executed. The this variable contains the current entity (that is the same as what was stored in the ent variable) and the source variable contains the other entity (the entity with which the collision happened - the event is actually sent to both sides and each one has the other as the "source" of the event). The entity-call function sends the pickup event (it actually calls the event handler of the pickup event) to the entity that received the collision event (the "this" entity) using the collision source as the event source for the pickup event. Finally the handler removes the entity from the world using entity-remove (which actually puts the entity in a list of invalid entities which are removed at the end of the world update cycle so that no dangling references are kept around).
Logged

~bs~
Pages: [1] 2 3
Print
Jump to:  

Theme orange-lt created by panic