Vapourware Codexian Game Development Thread

[OuterSpace]

I decided to go back to regular squares as opposed to the more isometric looking diamonds because I don't want to waste time building a level editor with everything I need when I can just use Tiled

Tiled supports Isometric "diamond shaped" tilesets.

 

[20 Eyes]

I decided to go back to regular squares as opposed to the more isometric looking diamonds because I don't want to waste time building a level editor with everything I need when I can just use Tiled

Tiled supports Isometric "diamond shaped" tilesets.

Doh, I meant Tiledlib but thanks for pointing this out. This was the library I was using to load maps from Tiled. And actually, I found out someone did do an isometric version of it.

But my game, if it ever was a game, is on hold while I work on my programming skills. I kinda knew I was going in over my head going from extremely simple games to the most complex 2D game-genre I can imagine (JA2/X-COMish). I managed to get pathfinding half-working, but in doing so I watched an XNA tutorial video of someone that actually knew what they were doing and it kinda put it into perspective how much time I was wasting on trial-and-error stuff and thinking about things that I should already know. Things click more and more for me every week, but I still have a ways to go. So for me:

Step 1: Work on C# and object-oriented programming fundamentals
Step 2: Make a much simpler game, I'm thinking either a very primitive non-randomly generated roguelike/dungeon crawly-thing or something like the earlier Zeldas (but not as good). I'm going to use this as practice for programming and pixel art. It will probably be pretty crappy, but I want it to be playable. I'll release it for free if it ever comes to fruition, even if it sucks so I can get feedback.
Step 3: Review criticism of last efforts, where my skills are vs where they need to be, ect

After that I'm going to revisit what I really want to do. I'll post some pics of the next project when I have something somewhat presentable.

 

[OuterSpace]

Step 2: Make a much simpler game

Good call. That's what I'm trying to do right now. Here are some tile based game development resources I've been using:

http://www-cs-students.stanford.edu/~amitp/gameprog.html
http://archive.gamedev.net/archive/reference/list6240.html?categoryid=44

 

[20 Eyes]

Workshop seems slow, so I'll post some progress of what I'm working on. Here is a screenshot (which unfortunately pretty much shows everything in the game, at this point):

I learned a lot the last two weeks as far as coding in C# and general OOP. There isn't much here, but I definitely wouldn't have been able to do so much so fast a month ago. The grey phallic-looking thing in the middle is the player and is supposed to be a space-capable fighter of some sort (definitely placeholder art, like everything else). Right now it shoots projectiles (top left corner) and controls similar to a game like Bastion. The HUD is fully functioning, the green bar is the player's shield.

Right now I'm enemies, a title/game over screen, and a score keeper away from having a complete (though very ugly and simple) game, but I think I'm going to take it a little bit further than that. The next big step will be adding enemies. Some point after that, I'm going to expand on the HUD to include things like the ship's power, armor, an EXP bar, ect. The game has several potentially RPG-like stats right now, but they're all under the hood. I'd like to try adding action-RPG elements to the game, so I can play with some RPG formulas.

This game is being made solely for programming practice, but I'm having fun with it and I'm very pleased with my progress right now.

 

[Surf Solar]

Since all of the other people working on What Remains (2 :> ) are busy with real life and other more important stuff at the moment, I didn't want to just wait it out and waste time and created some new art assets, plenty of it actually. Now, just tonight I had a brainstorm with some of my friends over IRC and came to the idea to make a very small game in the meantime the others are busy, with all the basic stuff and experience that I can do without any help. So I decided to use art assets I created for fun, like these here ( an entire city with lots of stuff is ready to use and rendered), and make some small (1-2 hours long) adventure game set in a sci-fi setting. I am just about to start with the design doc and fiddled around with the FOnline engine to see if it would make sense in there (since I know already how to use the engine). Pretty pumped up, my goal is to finish this in a very short period of time, so I can then work again on WR when the others are back.

Oh, and what I almost forgot - if someone of the bros here making games is in need for some graphic guy (2d/3d, it doesn't matter) - PM me , I would be glad to help out some people on such things.

 

[shihonage]

Surf Solar, I might hit you up later for um... making one-directional gory death animations out of sprites

________________

I've been seriously arguing with myself as to whether Shelter should go back to post-apocalyptic. Especially after Tim Cain's "dinosaurs" thing... as my setting takes place on a different planet mostly for the sake of not getting sued by Bethesda.

I like the name "Shelter", it's atmospheric, and it doesn't fit with being on another planet. It does fit with ... someone coming out of a, I don't know, underground shelter of some sort. Possibly after, you know, some kind of a nuclear war...

 

[eric__s]

Hey, I'm working on some music for a game but I've lost hearing in one of my ears and I need some advice. I can sort of hear out of it, but it's really distorted and everything is a different note than in my other ear. I need you to tell me first which version of these songs you like more and if you think they're out of tune or distorted or anything. They're both works in progress but I can't really work on them anymore until my ear gets better and I just need some opinions!!

http://dl.dropbox.com/u/2957395/crap_2.mp3

or

http://dl.dropbox.com/u/2957395/crap_2_2.mp3

The only difference is pitch. Does one sound more distorted than the other? Do you like one more than the other?

http://dl.dropbox.com/u/2957395/ultimate sludge_2.mp3

or

http://dl.dropbox.com/u/2957395/ultimate sludge_2_2.mp3

This one doesn't sound distorted to me, I just want to know which one you like better. It's for a character select screen.

Both of these songs were made with the YM2151 sound chip, which was used in a bunch of old Japanese computers and arcade machines. Almost identical to the Sega Genesis sound chip.

 

[20 Eyes]

Hey, I'm working on some music for a game but I've lost hearing in one of my ears and I need some advice. I can sort of hear out of it, but it's really distorted and everything is a different note than in my other ear. I need you to tell me first which version of these songs you like more and if you think they're out of tune or distorted or anything. They're both works in progress but I can't really work on them anymore until my ear gets better and I just need some opinions!!

I don't know much about music/sound so I can't explain why, but I think the first version you posted of both songs sounds noticeably better. Nice work on the songs, by the way. Neither one would sound out of place in a old/retro game.

 

[eric__s]

Thanks man. To me, the first version of the first song has a lot of distortion, but it might just be my ear. I appreciate the compliment too, we've been working on the game for about a year and a half. Hopefully it'll be out in a few months.

 

[Weierstraß]

The second song I definetely prefer the second version of. The first version seems a bit cleaner and a bit blander, though which one is the best might depend on the game. if it's a colorful platformed go with the first version.

 

[20 Eyes]

Added collision detection, a zooming camera that moves with the player's position, enemies, enemy/player damage and death, buggy as fuck pathfinding, and a game over screen (seen below).

Pathfinding needs a lot of debugging/rewriting, but everything else is working surprisingly well. The only enemy so far is a poorly drawn giant dragonfly that rams your ship (slowly and awkwardly until pathfinding gets fixed), and it's easily dealt with by firepower. Next I'm going to add a title screen and redo the HUD and rewrite things to make the enemy movement smoother. After that it's stats, perks, experience points, and the framework of the level system. I'm thinking about changing the game from air/spaceships to land vehicles, something like Death Rally but more focused on fighting than racing. I'm considering setting my game on a vast and empty planet where fuel is very plentiful, so highwaymen load into huge war truck/tanks and go blow shit up and attack supply convoys and such. I'm still too early into this to get too worried over the setting, but it's fun to think about.

 

[chewie]

Me and the team of Zero-Projekt are working in our free time on a cRPG in a post acopalyptic setting since a very long time now (about 6 years). Development is speeding up again, and we are in a phase where things finally begin to snap together (as most of the people are posting in this thread already might no - cRPG development is mainly about connecting a lot of stuff together :D)

I myself am working on the (python) code, and ATM I'm porting our game entity handling to a component based system. Did so with the ruleset a few months ago and it worked out quite well

For those non-programmers out there: we can now "describe" game objects a lot more flexible, and the game designer can combine entity attributes without needing a programmer to write special code. E.g. a lamp can not only have a light source, but also have an inventory, a combat ai (no joke :D), a daily routine etc. etc... just by setting some flags, providing some data. Awesome stuff - and fun to work with

Here is my latest implementation - making non-animated objects benefit from the whole range of the available entity properties, which results in... ehr.. destroyable lights
(click on the screenshot to watch the screencapture; *.ogg theora codec ~5 MB)

 

[Zed]

Wow, that's awesome chewie.

 

[curry]

Looks good.

 

[Davaris]

I myself am working on the (python) code, and ATM I'm porting our game entity handling to a component based system. Did so with the ruleset a few months ago and it worked out quite well

Is that part of your code open source? If so, I'd be interested in seeing that. Component based systems are something I am interested in, but I've never found an article that explains it very well. They only ever give simple examples and game engines and rules can be very complex.

 

[chewie]

Heh - yeah, I hear you. This topic is a complex one - I read some articles at gamedev.net and various other sources before even getting an idea on how this could work for us. That is to say, the most articles are about component systems which handle everything, from rendering to physics implementations and all that other stuff which happens behind the scences. I was lucky that a good part of that stuff is taken care by FIFE, our game engine.

So in our case, we just have to munge game data with FIFE instances (those pesky little things that move around the map :D), which saves us quite some complexity.

I'll try to give you a before-after description - maybe that helps a bit:

Before, the implementation was like this:
- Agent class (basic connection between FIFE & Zero)
- Hero class (player character 'controller')
- NPC class (npc 'controller')
- Container class (non-living objects which have an inventory)
- Light class (a light surprise! :D)

So there were major classes which could do anything, like Hero & NPC, and both of them (!) had a slightly different implementation for basically the same stuff. An NPC has attack() - and the Hero has attack() too - code duplication at it's best. :/ If I wanted to add a new feature like e.g. sneaking, I had to implement that in both classes.

Now if you want to make a container have a Light - or the NPC or every other interactive Instance - it basically meant to copy the Light implementation and adjust it. Teh horror.

Now the implementation looks like this:
- ZeroInstance (component controller)
- ZeroAction (transition layer between FSM states and FIFE actions)
- FSM (finite state machine)
- LightSource
- DoorProperty
- LockProperty
- AI (controller, switches between 'Agenda AI' and 'Combat AI')
- Ruleset (controller)

Now there is only one implementation, which makes sure to always behave the same. If I tell a 'light' to join a combat, the CombatManager can control it because it has the same interface a "npc" has, without writing extra code.

So the main idea about the concept "component based game entities" is - forget about NPC class - or Raider class - or Ship class. The implementation details heavily depend on your code / type of game / engine. I still have not crasped the idea in a whole - because I have a hard time right now to redesign the Hero class to make it fit into the system as well. The player has a lot more interfacing going on with the rest of the game code then any other game entitiy ever will have.

My approach is rather basic - as I 'only' cover game entities which have a direct representation on the map. Unknown Horizons (a project using FIFE, too) for example extends this design even to their gui and various other areas to make the complete game extendable for non-programmer contributors.

Davaris
About looking at our code: we are open source, but not yet (no release yet - which makes us closed source for some people out there) - but PM me and I'll give you a sneak peek if you want.

 

[Ion Prothon II]

That's the way to do things right. Every object in game world should be an entity consisting of independent parts grouped together, like GFX data, AI, mechanics data set, collision info, and so on. Function pointers/ delegates are the best friends of programmer too, since those things are often a better solution than polymorphism (for gamedev).
If you want even more abstraction and script/ plugin friendliness (with little performance loss), get rid of specific class references in "entity" class, and implement it like a map of <string, anytype>, where anytype is void*/object pointing to an object of specific entity part class.

BTW chewie Im' interested what approach with scripts you took: embediing external scripts into rigid engine API functions to do some low level stuff (like checking if hit/miss in combat), or rather exposing engine API to scripts? I got my own project and I wonder which one would be more efficient (I found both unsatisfying though).

 

[chewie]

BTW chewie Im' interested what approach with scripts you took: embediing external scripts into rigid engine API functions to do some low level stuff (like checking if hit/miss in combat), or rather exposing engine API to scripts? I got my own project and I wonder which one would be more efficient (I found both unsatisfying though).

FIFE is written in c++, and by using SWIG, it is compiled into a python library. Python then is used to write a FIFE client. Extreme low level stuff is hidden from the client, but most of the 'necessary' stuff is available.

On a side note: in Zero, getting hit or miss in combat is completely based on numbers - so no bounding boxes and the like. But FIFE can do that, too - we have e.g. the Shooter-demo showing that nicely. Zero basically only uses FIFE to "show the results" - if an game entity is destroyed or damaged, the appropriate fife actions are triggerd (= calls to the animations of an object, if they are defined).

I'm curious - which project are you working on?

 

[Radech]

Is that part of your code open source? If so, I'd be interested in seeing that. Component based systems are something I am interested in, but I've never found an article that explains it very well. They only ever give simple examples and game engines and rules can be very complex.

I'd recommend Flexible, Reliable Software by Henrik Bærbak http://www.baerbak.com/ - I took his course last year, where we built a civilization clone, incrementally by using compositional design, and constantly swapping out components while trying to imagine the amount of shit we would be in had we chosen an inheritance-based way - we bought a first edition of his book, so up-to-date scans might be hard to find, but before he got his book printed he handed out pdf's of it so they might be available somewhere.

chewie considered using github or something similar? I'd also be interested in seeing how you did it(my only experience with compositional design was that example, which was naturally tailored to show it's strengths), and maybe you'll recruit some random strangers along the way

 

[Ion Prothon II]

I'm curious - which project are you working on?

None. Just few working things with thousands of codelines written for a drawer, rather to get some skill than to try creating a forever-alphaversion nobody will give shit about.

 

[chewie]

I'm curious - which project are you working on?

None. Just few working things with thousands of codelines written for a drawer, rather to get some skill than to try creating a forever-alphaversion nobody will give shit about.

You also get skills by working on 'forever alphaversion' stuff. I'd also say you get a lot more skills by doing so - as you also get a good overview on what works and what not

And: getting stuck with alphaversions is mostly caused by several factors (think team dynamic!), not by a single one ("we don't have an AI, that's why we can't go any further").

Besides, we are doing this for fun, right? Otherwise we'd go for the industry and look for jobs there.

chewie: considered using github or something similar? I'd also be interested in seeing how you did it(my only experience with compositional design was that example, which was naturally tailored to show it's strengths), and maybe you'll recruit some random strangers along the way

We are using an own SVN server. There are some plans to partially open it once a release was done. GitHub is nice, maybe I'll set up a repo there for tagged releases or something like that.

That recruiting-topic (strangers come along and magically make feature X working) didn't work so well - even for projects which emphasized that point (e.g. look at parpg - they were open as hell, but no one sticked long enough around to push the project :/). Personally I think you are better off with some dedicated people who know the project well - at least if you're still in a phase where a huge amount of work has to be done. Patching & minor improvements is a completely different scenario IMO. Once your project has enough supporters, this can work very well (think FireFox and the like =) )

Bottom line is - I'd like to add something that works instead of throwing yet another pre-alpha of OSS into world :D

 

[Davaris]

With component based systems, I understand game entities are composed of separate components, all stored in a list. I also understand that one component can send messages to all of its fellow components, through a common interface and each component decides what kinds of messages it responds to.

The problem that arises for me, is when one component needs to read data from another component. Then I get components that rely on other components, and so the component system becomes a tangled mess, where if you add one component, you must add all the other components it relies on.

Does your system have a way to solve this problem?

Davaris
About looking at our code: we are open source, but not yet (no release yet - which makes us closed source for some people out there) - but PM me and I'll give you a sneak peek if you want.

Thanks.

I'd recommend Flexible, Reliable Software by Henrik Bærbak http://www.baerbak.com/ -

Thanks Radech. I'll take a look.

 

[Ion Prothon II]

That recruiting-topic (strangers come along and magically make feature X working) didn't work so well - even for projects which emphasized that point (e.g. look at parpg - they were open as hell, but no one sticked long enough around to push the project :/). Personally I think you are better off with some dedicated people who know the project well - at least if you're still in a phase where a huge amount of work has to be done. Patching & minor improvements is a completely different scenario IMO. Once your project has enough supporters, this can work very well (think FireFox and the like =) )

Bottom line is - I'd like to add something that works instead of throwing yet another pre-alpha of OSS into world :D

Correct. The invisible army of helpful opensource depth dwellers is a myth.
http://tmrepository.com/trademarks/basementdeveloperarmy/

 

[chewie]

About the communication chain: I'd say the entity which makes the request has to be able to deal with a request failure, and not only rely that there is actually data. And each part of the chain has to to the same. If you e.g. request the name of an entity and get an empty string, your game shouldn't crash.

In Zero, if e.g. the AI wants a certain action to be executed, but the FSM can't translate the state to a fife action, it relies on a fallback value, which is auto-generated on the game entity creation. That way I don't have to limit the AI, keep it generic and only handle the results different. On the other hand, if the AI requests data from e.g. the ruleset (let's say get current actionpoints) and the game entity has none, then it should skip all the parts which rely on actionpoints. At the end, a game entity without action points can be considered a "static object" in combat, so it e.g. would make sense that the AI just skips the round instead of going into a full calculation cycle.

That's the trick I'd say which one has to understand with this component-stuff. Everything should work, but only if the needed data is given - hence those system are heavily data driven by design.

 

[Davaris]

Everything should work, but only if the needed data is given - hence those system are heavily data driven by design.

That makes sense. I've seen comments in articles where people argued a component should never refer to any other component and that confused me, because I couldn't see how you could not do that in an RPG.