Slick Forums

cool!
Send me patch on github, I'll integrate as soon it's possible
When can we see your game ?

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Ok, will send it in a few hours.

Well, the game needs to be finished around March/April, so that's the latest date you'll see something

I think I'll open up a thread in the next few days, when we start to actually have something

if you need some assistance, please send me a pm.

I will integrate your code intro MarteEngine as example, just give me readme.txt for credits and license for license code for your work ! (Marte is MIT, as Slick)

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Thanks to tommy for great code, I've added a little tank game example on GitHub, see here:

https://github.com/Gornova/MarteEngine/ ... /test/tank

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

I've added a little build.xml to build and configure your jnpl and jar to work as webstart All you need is to configure your build.xml

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

I've added a new example about entity rotation and a basic platform (see first post), and a big news (at least for me)
Again thanks to Tommy for his job!!

Thanks to proguardfinal size of game's jar will be redouced I've already redouced first example's jar, here an example:

HelloWorld example:
- before proguard: 101kb
- after: 64kb

Not bad, right? Try it all jnpl on first post and let me know!

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Hi all,
in my devtommy branch there's now scaling entities too (images and animations). Also you can change the transparency of an entity (using the alpha value of the color the entity is drawn with).

Furthermore I added some stupid TextEntity to place some text on screen

And finally I just improved the Marte ResourceManager where you can now specify a base directory where all other resources are searched for.
The StarCleaner example is modified appropriately.

But for now that's only in my developer branch so use at your own risk

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

Don't worry, I'll test it soon and merge into master.. for future MarteEngine 0.2 release

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Version 0.2 in now near!

I've just added into dev branch Tweens, here (and first post), example:

Tweens: test Tween capabilities of Marte Engine, moving around an entity and change Easing function like in Flashpunk

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Been going through the code.

First impressions:

- No components? Promoting inheritance hierarchy? I'm a bit surprised. This might quickly devolve into a inheritance nightmare soup (as it seems to have already done with those StaticActor, TopDownActor, PhysicsEntity, etc.).

- Little separation of concern. You have tons of stuff inside the Entity class, it's nearly 1000 lines! You have rendering data inside it, and logic data such as speed, animation, etc. It doesn't make sense to me, what if you wish to make an Entity that doesn't make use of any of that data?

- I can't imaging the Entity class being memory efficient, as it allocates memory for stuff you won't need in many cases, such as color, hashtables, hashset and other primitives. What if you need to continuously spawn new Entities of the type Bullet? Have you tried to see how fast it creates 1000 bullets per second?


Overall, I think it promotes bad design and is inefficient with regards of performance and memory usage. Although, it might be fine for very simple games.

I wouldn't take this criticism very seriously, as I've not tested this properly, just glimpsed through the code. And I'm not attempting to bad mouth this in an attempt to favor my own system, because my own system has many flaws as well which I am trying to iron out in subsequent games. Ok, peace and love

@appel: thanks for your feedback, peace and love is great

You are right, we decided against a component model and just use inheritance.
Simply because we target a library to easily create simple games.
Imagine tools like Game Maker, Construct or Klik'n'play.

You just subclass entity and you're good to go.
The decision to have a complex Entity class was made by us on purpose. Our intention is to make many things just work automagically. We are aware of the struggles we might run into if we extend the functionality. But it should still stay simple for the user. As you can see we even made instance variables public instead of using getter and setter methods! Gasp!

And yes, we also decided to waste a few bytes for each entity for instance variables that are not used.

I don't think that spawning a Marte bullet is much more expensive than spawing a bullet in your component system. At least we don't need to create a render component, a movement component and some gravity component and connect them with each other for a simple bullet sprite to move

If you look at my sample game "Star Cleaner" in the repository all the classes there are dead simple. And still it's a fully working platformer which was done in 6 evenings including gfx and (terrible) sound.

My impression is that we target a different audience. We want to give people some help to code simple games in Java and get them deployed in many ways (webstart, applet, stand alone) as easy as possible.
We don't want to preach clean design but get people code games in Java without having a diploma in computer science.

I'm definitely having a look at your approach, appel. Just to learn how a game is done using a component model.

Again, thanks for your feedback and love and peace to you, too

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

peace and love to you



thanks for your time, seriously



MarteEngine is not a component based system. It start from opposite idea: give to developer some feature without force him to use something big and difficult to understand (at start). So yes, we promote inheritance even if is not the best approach. Why ? Because in many video games you don't need to optimize or go in deep of good programming and.. hey, it's free it's up to you use it or not.
For soup-Entity you see experimental entity, not final ones For example with just Entity (that is abstract), you can extend it and have all you need to move around something on-screen It's a starting point



You start from a component-based approach: all optimized, all done in few lines, but with many classes. in MarteEngine we have one big generic classes (I agree that is big, we need to write it better and optmize it!) that you can use for everything. I believe that for many developer this approach can help to make things on screen moving, that is the key point: don't waste time in programming.. so create games. I know that many developer will not agree with me, but is only a point of view



No, I will This is a good test, thanks!



IMHO, bad design is a point of view (don't misunderstand me, my english is terrible and I don't want to offend anyone!), sometimes you need to make choices and MarteEngine try to follow this choices.



If I can challenge you, can you try MarteEngine and try to make a game? Like a top-down shooter or platformer or something simple like that? So can provide feedback to us !


@tommy: we need to do some stress test and see how to optimize the core classes, for MarteEngine 0.3 I will make a todo on github

_________________
Blog | Last game Gravity Duck tribute | In progress Gravity Duck tribute

Few points regarding the datastructure and z-index strategy you're using:

1. Removing an entity in ArrayList could be as bad as O(n), if you remove entity at index 0, it requires shifting all the entities towards 0.

2. Sorting might be alright though, especially in an already sorted array. Although I think using list of collections (or bag of bags) might be better and faster, and just have limited number of layers.

3. If you have an entity that displays a health bar, how do you ensure that the healthbar is always rendered OVER all entities? E.g., if you have two entities that have a healthbar, one will overlap the healthbar of the other. My system solves this by allowing developer to specify layer of each component, so that healthbar is always rendered over e.g. sprite image.

Hi appel,
thanks for looking at our code and giving improvement tips! Greatly appreciated!

1. It's not as bad as you guessed. ArrayList.remove() uses System.arraycopy() which is pretty fast and does some kind of memorycopy (in the end it's just pointers to objects). There are special treatments for removing first and last element to avoid shifting (because ArrayList stores firstIndex and lastIndex!). So it should still be pretty fast, even for those old C code worst cases.

2. Might be worth to investigate.

I think 1. and 2. become critical depending on the number of entities. In simple games you won't have more than a few hundred entities at all. And I doubt that this will cause huge performance issues with today's computers. But I think Gornova and I will do some testing based on your input.

3. Not having a component system does not mean that we can't have entities (like a tank) that use other entities (like a healthbar) in their instance vars and move their position according to their own
And each entity has it's own z layer. So although we don't have a neat component system we can always implement one with our given design. So no problemo here


Cheers,
Tommy

_________________
Right Angle Games | Marte Engine
Back to the past | Star Cleaner | SpiderTrap

I used arraylist in a similar manner as you're doing, and it was a big performance bottleneck. I swapped it out in favor of bags. It might not be a problem with a few hundred entities though.




Problem with linked entities like this is that you need to make sure all linked entities are deleted if the tank is destroyed.