LE Community Project

[BES]

I decided to try this on my laptop ..since my system specs in my opinion are a bit much..keep in mind that my laptop resolution is 1366x768...but I could only use 1280x720 in the demo...

 

I only tested it at 1280x720 ..this is with all the settings maxed except vsync:

Frames, Time (ms), Min, Max, Avg
5471, 287681, 10, 26, 19.018

 

1280x720 normal with no settings

Frames, Time (ms), Min, Max, Avg
6091, 236217, 12, 52, 25.786

 

Sorry about the results ..I have an old version of FRAPS installed on this laptop ..it seems to have a different min,max,avg output..

 

Laptop specs:

CPU: AMD quad-core A6-3400M @ 1.4ghz/2.3ghz Turbo(AMD APU ..has graphics on the CPU)

RAM: 8gigs DDR3 1333

Graphics: HD6520G (512 shared ram, catalyst 12.8 drivers, normal screen resolution 1366x768)

[Pixel Perfect]

Store player and monster data on the entities (health,ammo, etc..) It's hell to figure out the classes and where to access all data which slows down development (or maybe I'm just too stupid for hardcore oop c++ :-) )

You should only need to store a pointer to the instance of the class and the class type in the entity itself (this isn't even necessary as you could just have a unique Id and use a lookup table for the pointers). Then, if the classes are designed well, you should have functions to easily access and update data for the NPC.

 

OOP should make it easier not harder

[Rick]

Store player and monster data on the entities (health,ammo, etc..) It's hell to figure out the classes and where to access all data which slows down development (or maybe I'm just too stupid for hardcore oop c++ :-) )

 

Shadmar how familiar are you with OOP? If you don't really know it, then it'll seem complicated. Especially when you get into virtual functions and if you don't know how they work. The idea with most of the games with C++ is that you load your scene and any object/model that needs functionality is assigned to a class object and then most everything is done via that class objects. All variables and methods for that object can be done by that class.

 

I think MidnightSalsa got a little more complicated when we started mixing Lua and C++ myself. Now you have to look in 2 places to see the functionality instead of just 1 even for the same object possibly. I think this happened because of what the people we had were more comfortable with. When we first started the coders were more comfortable with C++. Later some of the programmers we got were more comfortable with Lua so things started to shift. We were in a situation where beggars couldn't be choosers though so we took what we could to keep things moving forward.

[shadmar]

I was educated as a cpp programmer back in the days (1995) and learned oop, but however I haven't maintaned much since then, doing most scriptbased.

My remark was at the personal level (maybe not wisly wrote, so for that I'm sorry) no criticism intended to the original work done.

I'm sure OOP makes it easier if you're well familiar with the classes and code from the start.

For a community game I'd think that maybe a lua game would be simpler for all (and maybe not) I don't really know what most people in here use for creating games. I like lua, I can use CPP, not very good at OOP but I'd like to think I can get around.

[Rick]

From what I can tell most people use C++ or BMax around here. Lua is becoming more popular but (I think) because of LE2's poor Lua IDE/debugger, larger Lua projects are harder to manage. I have a few fairly large Lua projects I was working on and it can get hard to follow fast. One little typo error could mean hours of finding out what's wrong because LE2 doesn't give you any real meaningful error message.

 

Without the nice features of IDE's like Visual Studio (proper debugging being a big one) large Lua projects in LE2 are just too painful. LE3 looks to really help Lua with LE development though, so really excited for that!

 

Again, a lot of this is all about preference though.

[Rick]

Trying to compile, and can't find batHit01.ogg - batHit03.ogg. I assume these were never added to SVN? I agree with Shadmar, everything on SVN is the ideal way to go.

[AggrorJorn]

I agree to that using SVN for everythin would be the ideal way. However when we reach 1 GB of space then we need to use a different storage system. Since the game remains small we can upload everything to svn if we want to.

[flachdrache]

There could be much said about "lua and the c++ paradoxon" ... all i currently can add is, by being used to work with C gamecode in an complete gameDev environment - the whole process of building a game becomes much clearer. Its not for the programmer to have entitys scriptable or for the artist to have 16 classes of enemy types. The result seams to be working quit well as far as i can read - so, its just about making the right decisions while getting the flow right. Looking forward to a "even fast and better looking gameplay experience".

 

In a team i would prefer to work with something like mantisbt.

[Pixel Perfect]

I think this happened because of what the people we had were more comfortable with. When we first started the coders were more comfortable with C++. Later some of the programmers we got were more comfortable with Lua so things started to shift. We were in a situation where beggars couldn't be choosers though so we took what we could to keep things moving forward.

Although far from ideal team work usually involves some compromise and it's important that team members are kept 'in the loop' and involved. It's team work that gets games completed in the end so if it works that's fine, it's all smoke and mirrors anyway. The end gamer cares not what coding methodology underlies the game, just that it works and it's fun to play

[Marleys Ghost]

From what I can tell most people use C++ or BMax around here. Lua is becoming more popular but (I think) because of LE2's poor Lua IDE/debugger

 

I use predominantly Blitzmax and Lua but also c++ and Lua, I don't recall having any major issues relating to LE2.x's Lua IDE/debugger or with how Bmax and c++ interact with lua in LE.

[Josh]

Regardless of the miscellaneous bugs and things that could be improved, I call this a victory. The community set out to create a playable zombie shooter, and they succeeded in doing so.

[macklebee]

playable? is there a working release version yet?

[Josh]

I played it.

[ChrisV]

Besides the die cam that needs a fix, and a few other minor problems, it worked on my machine.

Sure, it can be improved and made better, but I'm very proud that we got this far, and I'd like to thank all involved for doing their best. It has been a great experience for me as well, being Lead Artist, and it was great to work with such nice people whom have proved to be capable of getting a playable game done on time. Thumbs up, guys!

 

As for svn alternative, I'm not sure, but could THIS be a solution?

 

Cheers

[Josh]

SourceForge and Google Code offer free project hosting.

[Guest Red Ocktober]

c'mon now, lets get real... and don't take this the wrong way... but there's a ways to go before the victory flag can fly on this... the release afterthought version was unplayable...

 

sorry guys...

 

--Mike

[Rick]

I agree it's unplayable right now. I've been away from the project for a month or so preparing and then having our second child so I've missed some of the later development of the game. I'm working on the errors that were found but my time is still limited. I've found the crash on exit bug, the first one I looked at, and will find the others. We will keep the thread updated. Thanks for your patience.

[macklebee]

I agree it's unplayable right now. I've been away from the project for a month or so preparing and then having our second child so I've missed some of the later development of the game. I'm working on the errors that were found but my time is still limited. I've found the crash on exit bug, the first one I looked at, and will find the others. We will keep the thread updated. Thanks for your patience.

 

thanks for the honest reply... i look forward to actually being able to try it out.

[BES]

Maybe you guys could try this? ..for the release version? ..maybe it will work..unless there is more to it than that to get a release version going..

 

Its called Cmake: http://www.cmake.org/

 

Description:

CMake is a cross-platform, open-source build system. CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.

[Josh]

What I mean is the devs stopped getting sidetracked on all the little excuses people come up with, dived headfirst into game mechanics, and actually delivered something with playable game mechanics. That's the important thing I wasn't sure I would see, and I'm really proud that they came through with that.

 

I haven't looked at the source yet. There was a site to register on, or something, and I never followed up beyond that step. Most open-source projects have open access to download from the repository, and you just need special permission to be able to commit code.

[Naughty Alien]

..is it possible to get whole project media/docs and form maybe another Bmax crew to do same project ? Have you guys think about that ?

[shadmar]

I added 10 lines to fspcontroller.lua, now I can play the entire lecp level killing zombies in the editor.

However no menu,pickups etc., it's just the plain slaughter. Selfcontained lua objects are awesome to work with. :-)

[AggrorJorn]

@Naughty Alien: I am all for open source so it will be released to the community once we have the major problems gotten rid off. This was one of the requirements when we started the project. As for the assets: there is an ongoing discussion for this is the lecp forum.

 

@Macklebee: I agree with you that the tech demo is by far from perfect and does not earn the tag 'Playable' yet. We hope to achieve this very soon, for now it has the highest priority before anything else is created or added.

 

@Josh: Thanks for the kind words. I agree on the part were this is certainly a victory on the communities part. We all knew from the beginning it was risky and that it would require a lot of 'pushing' to get even to the point were we are now.

 

SVN , source control etc

SVN in combination with Google drive was a huge mistake. Files got lost or weren´t correctly updated. Sometimes a commit occured without updating first.... I know that I made that mistake a couple of times. Also something that was a pain, was the sbx file deleting reference to models. This occurred when someone had edited the map, and then when someone else starting editing without having all the models from the asset drive, you would loose the reference from that object. With the newly edited map, all models placed would be gone. We did restrict level designing to the level designer, but in the last few weeks we all starting working on the level because of lack of time, team members no longer having time to work on their tasks etc.

As for assembla and SVN. That worked quite well actually. I made the mistake to keep models separated because I thought we would reach the 1 GB limit of our Assembla storage. Yet we haven't even reached 400 MB. Google Code is a nice alternative. The only thing I disliked was having a project that was very far from even its pre-pre-pre-pre-pre-alpha for the first tech demo.

 

Setbacks

There have been a lot of setbacks (forum and bugzilla got hacked, members having no time work on it) and some of those were to be expected. Many of us heave their own projects or just simply don't have the spare time because of personal matters that are far more important.

 

Keeping the flow

I still think that the most dangerous part of the entire project (or any other project) is keeping things flowing. There are times when you get demotivated due to lack of progress or problems with communications. Task planning, keeping track of what people are doing, staying organised, project management issues are a big challenge. Using Internal planning at the programming part could have been better, but that is so easy to say afterwards. I had no idea how simple it is to get lost, even when the project seems 'simple'. Still I am very proud on the team and their involvement. No matter what the task was and how much hours they spend on.

 

To be continued?

This is an ongoing discussion at the lecp forum. There are many things that we learned about how to manage the project and how to set things up for a next time or when we continue. This goes for programming, planning as designing.

 

Feedback

It is good to have feedback about the game. So I would like to thank everyone for trying out the game and leaving a comment.

[Pixel Perfect]

Congratulations guys, you came together as a team and actually delivered and that counts for a lot. Just keeping a community project going to the point where you have something playable is a feat in itself! I'm sure, as Aggror's summing up is testament to, that you have all learnt a lot from this experience which will stand you in good stead for any future project/team work. Well done

[Naughty Alien]

@Aggor

 

Open source i was thinking is more related to building up things (same) from scratch using Bmax, with use of same media and documentation (design) provided. Fixing bugs in C++ doesnt impact Bmax code eventually and therefore, postponing it may be wrong idea ? Im just saying that, maybe wider audience, regarding community capacity should be included, in order to get better results, because there are capable guys on both side of the pool (C++/Bmax) so, why not utilize all ? Also, if this community project is about to be a 'tech demo' as i saw it exposed in few threads, then I believe it should to be much more than current presentation I have seen..just a constructive suggestion/opinion..

 

Side question..during media creation, is there freedom to ask animator/modeller for certain 'features/additions' in their respective fields (animation/level building) ?